From kbarrett at openjdk.org  Tue Oct  1 01:30:37 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 01:30:37 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <PcfEO_LHkIlj3oFG1BjI5AgWhUzbRkFUxYDXhmFa1jU=.8059fe1e-c120-4d0f-96ba-27438aa2217a@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
 <lzbKsjK3JtjBSgMhnNnb_IMEHd86sJV0sPtRbWk5BN8=.60cc23a8-e846-481b-979f-8cd3ba4e18e7@github.com>
 <PcfEO_LHkIlj3oFG1BjI5AgWhUzbRkFUxYDXhmFa1jU=.8059fe1e-c120-4d0f-96ba-27438aa2217a@github.com>
Message-ID: <R_pNXcc-cSdtuj4YiVfriLUbcqo6YRYH3Jyk5E379Zs=.b4afb481-17e9-435d-8a4b-34dbe65b1221@github.com>

On Mon, 30 Sep 2024 16:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 420:
>> 
>>> 418:     /* Implementation of clear(), also used by enqueue().  A simple
>>> 419:      * assignment of the referent field won't do for some garbage
>>> 420:      * collectors.
>> 
>> Description of clear0 is rendered stale by this change.  The first sentence is no longer true, since it's now
>> clearImpl that has that role.  The second sentence probably ought to also be moved into the description of
>> clearImpl.
>
> Thanks! I tightened up comments a bit, take another look?

Yes, that's better.  Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1782006243

From kbarrett at openjdk.org  Tue Oct  1 01:37:45 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 1 Oct 2024 01:37:45 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
Message-ID: <sHjJaanZFXYvLplEw2LSPX1rI4TbBxjB-QF2IQox1L8=.2bc659e3-2acc-4ff2-907e-83f0763529ae@github.com>

On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 server fastdebug, `all`
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also dispatch to slow-path on other arches

Removing my "Request changes" as request has been satisfied.

I've only really looked at the changes in java.base, which look fine.  I've skimmed some
of the compiler code, but don't feel qualified to properly review it.  So don't count or
wait for me as a reviewer.

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

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2338962626

From liach at openjdk.org  Tue Oct  1 02:00:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Oct 2024 02:00:34 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications [v3]
In-Reply-To: <6PltJ5oj9C3FSBM4-pdQJJgrk11xiJS_SI8aQvn-1Do=.bd5af85b-7015-4b09-8c52-6d492bc19a4b@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
 <6PltJ5oj9C3FSBM4-pdQJJgrk11xiJS_SI8aQvn-1Do=.bd5af85b-7015-4b09-8c52-6d492bc19a4b@github.com>
Message-ID: <g9UAwRJht7OI0kIOPjFVwbX2swywMiKAVVIJWJfC8JQ=.dae3711b-1a7d-4f87-bf51-cafe9c5cc301@github.com>

On Mon, 30 Sep 2024 14:59:12 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20796#pullrequestreview-2338979444

From smarks at openjdk.org  Tue Oct  1 03:24:37 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 03:24:37 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <R3tbKvlqEZPyVviu_MJChobfGwN0vmBZv29VHpe5a5I=.c93013da-1458-4724-874b-16cabc97acae@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
 <R3tbKvlqEZPyVviu_MJChobfGwN0vmBZv29VHpe5a5I=.c93013da-1458-4724-874b-16cabc97acae@github.com>
Message-ID: <v4Y0DbXoTqVtmwuZzfj6NIF5-wLRiF3nENMdWIHJEmU=.7a67e8b8-84f4-4752-93f8-26d98d845d4a@github.com>

On Tue, 1 Oct 2024 03:18:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
>> 
>> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.
>
> I agree with just reverting the behaviour as discussed in JBS, but will leave the actual review for the libs folk. The more general question of when to trigger CME is a very thorny one.

Right, @dholmes-ora, you might recall that we argued about this several years ago. :-) Even though I'm on the losing end of that argument, I am ok with eventually removing the modCount increments from sort and replaceAll. This is covered by JDK-8203704 which should include a spec clarification to support the change in behavior. Meanwhile, this PR should simply revert to the behavior previous to the JDK-8325679 change. (Even though that behavior is arguably wrong.)

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

PR Comment: https://git.openjdk.org/jdk/pull/21250#issuecomment-2384701569

From dholmes at openjdk.org  Tue Oct  1 03:24:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Oct 2024 03:24:37 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
Message-ID: <R3tbKvlqEZPyVviu_MJChobfGwN0vmBZv29VHpe5a5I=.c93013da-1458-4724-874b-16cabc97acae@github.com>

On Sun, 29 Sep 2024 17:44:30 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
> 
> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.

I agree with just reverting the behaviour as discussed in JBS, but will leave the actual review for the libs folk. The more general question of when to trigger CME is a very thorny one.

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

PR Comment: https://git.openjdk.org/jdk/pull/21250#issuecomment-2384699577

From smarks at openjdk.org  Tue Oct  1 03:28:34 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 03:28:34 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <B56h2M-9ARx7sZZvfRdJ3Luu5hNCt-U2_DKMmisTcuk=.0d40b2f2-cb84-43f2-af41-1446e3b0b594@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
 <aIxX6fMnCtQ9eQqUU1Ou32J1J_MgQ5gZUyej0PcRP5M=.fbbeab52-4033-405f-851b-13b0431cdbcc@github.com>
 <B56h2M-9ARx7sZZvfRdJ3Luu5hNCt-U2_DKMmisTcuk=.0d40b2f2-cb84-43f2-af41-1446e3b0b594@github.com>
Message-ID: <kczPwsVuWWURWOHDrWmwjiqYamMp2X3iUgNnap7AKyk=.57641c1b-5a39-43ab-8d50-8b273e4a5b91@github.com>

On Mon, 30 Sep 2024 19:44:05 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Just an observation, but sorting is not defined as a "structural modification" but obviously would interfere with an active iterator. So the docs may need updating to include this aspect.
>
> @dholmes-ora and @dfuch both your observations are quite valid and I agree with them. If you look at the [JBS issue](https://bugs.openjdk.org/browse/JDK-8340572), we discussed this topic there. 
> 
> Clarifying the collections' behavior with regard to when to throw a CME, and hopefully making that behavior be consistent would be a welcome enhancement. As things stand, the scope of this fix is just ensuring that the behavior of ArrayList reverts back to what it was prior to my optimization, since the change triggered a test failure in some Google test suite. All the while recognizing that the behavior was not particularly consistent to begin with.

@szegedi Thanks for starting this. Just a couple comments on the test.

1. It would be good to have a test case that verifies that sorting the entire list **does** increment modcount, in addition to the existing test case that tests that sorting a sublist **does not** increment modcount. (As before, this is arguably not the correct behavior, but it's the behavior that the system exhibited prior to JDK-8325679.)
2. It would be good for the test to have a more descriptive name than just the bug ID. Something like SortingModCount or similar would be fine.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21250#issuecomment-2384705769

From smarks at openjdk.org  Tue Oct  1 03:41:40 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 03:41:40 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
In-Reply-To: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
Message-ID: <FSQo0wE_ft_5QY4KHwT33YsCesczxRpY5K4aidj9wbU=.49ffec61-952b-42fe-9b97-c73851190a97@github.com>

On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
> 
> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
> 
> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
> 
> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
> 
> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
> 
> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
> 
> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
> 
> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

test/jdk/java/lang/StringBuffer/HugeCapacity.java line 51:

> 49:             // Maximum array length supported by the JVM implementation
> 50:             int maxArrayLength = ArraysSupport.SOFT_MAX_ARRAY_LENGTH;
> 51:             String str = "Z".repeat(maxArrayLength);

Same comment as in the corresponding code in the StringBuilder test.

test/jdk/java/lang/StringBuilder/HugeCapacity.java line 83:

> 81:             // Maximum array length supported by the JVM implementation
> 82:             int maxArrayLength = ArraysSupport.SOFT_MAX_ARRAY_LENGTH;
> 83:             String str = "Z".repeat(maxArrayLength);

The comment is a bit misleading. I'm not sure any comment is warranted, as you had observed, there's a big description next to SOFT_MAX_ARRAY_LENGTH. I'm also not sure a new local variable maxArrayLength adds anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21268#discussion_r1782068899
PR Review Comment: https://git.openjdk.org/jdk/pull/21268#discussion_r1782068601

From smarks at openjdk.org  Tue Oct  1 04:03:34 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 04:03:34 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
In-Reply-To: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
Message-ID: <P5DvIyvR3brhe9FlhK-UDwJ36Xbwh4dkacg8GGVjq-k=.757482fa-4e24-4749-a10b-43b3cad80191@github.com>

On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
> 
> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
> 
> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
> 
> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
> 
> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
> 
> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
> 
> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
> 
> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

As this stands (modulo my other comments) this change is mostly OK. Using the SOFT_MAX value within java.base is fine. Using SOFT_MAX within java.base-related tests is a little suspicious, because it requires the addition of directives that export an internal package from java.base ... but these tests are generally expected to be closely coupled with java.base internals, so they're probably ok too.

I agree with the decision not to expand usage of SOFT_MAX further, as it's really just a guess at a VM implementation limit that's not defined anywhere. (There have been requests to make this public; see [JDK-8246725](https://bugs.openjdk.org/browse/JDK-8246725), which I'm opposed to.) The *real* fix here is to fix the JVM so that it can allocate arrays of Integer.MAX_VALUE. From time to time I hear rumors that this might happen at some point. Meanwhile, let's not expose something with ill-defined semantics like SOFT_MAX beyond java.base.

As an aside, for your own edification, you might want to verify that compile-time constants are indeed inlined, by inspecting the before-and-after bytecode. This is well documented; see JLS 13.1, item 3 of the first numbered list in that section. I'm sure this is well tested, so there's no need for a test for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2384736938

From jbhateja at openjdk.org  Tue Oct  1 05:09:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Oct 2024 05:09:25 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v19]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <Rgx6r8xrA1DNQm-uuRrGmNnpWlvXWxMsBrvaYsWjQjE=.4bd7bd2b-aa3f-49e0-8d7b-0fd0b17577aa@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Merge stashing and re-commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/28b29bc6..952920ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=17-18

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

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

From eirbjo at openjdk.org  Tue Oct  1 05:39:09 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 05:39:09 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
Message-ID: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>

> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
> 
> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
> 
> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
> 
> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
> 
> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
> 
> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
> 
> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
> 
> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Remove comment and variable from HugeCapacity tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21268/files
  - new: https://git.openjdk.org/jdk/pull/21268/files/eb1c6551..67ed8e47

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

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

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

From eirbjo at openjdk.org  Tue Oct  1 05:39:09 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 05:39:09 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <FSQo0wE_ft_5QY4KHwT33YsCesczxRpY5K4aidj9wbU=.49ffec61-952b-42fe-9b97-c73851190a97@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <FSQo0wE_ft_5QY4KHwT33YsCesczxRpY5K4aidj9wbU=.49ffec61-952b-42fe-9b97-c73851190a97@github.com>
Message-ID: <YSUHxKQYrKRQQGNXkh-Yslp0kM15Yz_di6HB54JQiG0=.1873ba60-2654-4f54-a90d-f7e2e9b60ae1@github.com>

On Tue, 1 Oct 2024 03:38:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> The comment is a bit misleading. I'm not sure any comment is warranted, as you had observed, there's a big description next to SOFT_MAX_ARRAY_LENGTH. I'm also not sure a new local variable maxArrayLength adds anything.

Thanks, I have removed the comment and variable for these two tests.

I guess I felt SOFT_MAX_ARRAY_LENGTH looked a bit lonely here, given that it was just used as an argument and had no constant or comment like in most other instances. But I agree that the comment and the variable does not add much value here, the name of the test makes it clear that this is about capacity and the documentation on SOFT_MAX_ARRAY_LENGTH is just a click away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21268#discussion_r1782140912

From eirbjo at openjdk.org  Tue Oct  1 05:54:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 05:54:35 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
In-Reply-To: <P5DvIyvR3brhe9FlhK-UDwJ36Xbwh4dkacg8GGVjq-k=.757482fa-4e24-4749-a10b-43b3cad80191@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <P5DvIyvR3brhe9FlhK-UDwJ36Xbwh4dkacg8GGVjq-k=.757482fa-4e24-4749-a10b-43b3cad80191@github.com>
Message-ID: <BJQGK40yRqnFkWP4jmyXhzJNEOTugvOL_UZ3OWiurUE=.11fdba8e-18ba-4228-85df-a00c622f32fc@github.com>

On Tue, 1 Oct 2024 04:01:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> As this stands (modulo my other comments) this change is mostly OK. Using the SOFT_MAX value within java.base is fine. Using SOFT_MAX within java.base-related tests is a little suspicious, because it requires the addition of directives that export an internal package from java.base ... but these tests are generally expected to be closely coupled with java.base internals, so they're probably ok too.

I was pondering a bit whether to include tests. The use of the constant perhaps aids understanding even more here, because the value might seem "more magic" , being  further removed from where actual allocation takes place. Tests are a useful tool for understanding APIs and their implementation, so less magic feels like an improvement. Also, we want to update tests as well if the implementation limit is lifted, this makes that update easier.  

> I agree with the decision not to expand usage of SOFT_MAX further, as it's really just a guess at a VM implementation limit that's not defined anywhere. (There have been requests to make this public; see [JDK-8246725](https://bugs.openjdk.org/browse/JDK-8246725), which I'm opposed to.) The _real_ fix here is to fix the JVM so that it can allocate arrays of Integer.MAX_VALUE. From time to time I hear rumors that this might happen at some point. Meanwhile, let's not expose something with ill-defined semantics like SOFT_MAX beyond java.base.

Good, I initially included code outside `java.base`, but that quicly got messy.

> As an aside, for your own edification, you might want to verify that compile-time constants are indeed inlined, by inspecting the before-and-after bytecode. This is well documented; see JLS 13.1, item 3 of the first numbered list in that section. I'm sure this is well tested, so there's no need for a test for this.

Thanks for the JLS pointer, good that this is not just a javac implementation detail.
 
Confirmed this using:

% javap -c -p -constants java.io.InputStream | grep MAX_BUFFER_SIZE`
private static final int MAX_BUFFER_SIZE = 2147483639;
% javap -c -p -constants java.io.InputStream  | grep ArraySupport

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2384860067

From dholmes at openjdk.org  Tue Oct  1 06:30:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Oct 2024 06:30:46 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <8FTxHRmKPQ35BTBG8Kvq9Tn_2J6acpi9zdnt89U94-4=.750c3348-19de-460e-96c6-9b8f8f00d0f4@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <c2OPb3rALMYVdgwQFtkTZCmrCRQxDo8Xkb2cq8afpmA=.f37ae57b-700d-4b64-9be1-a7c201a56bc0@github.com>
 <BPXpziMnJ5abo68eNo6ClJH2c-eTDmJbT0ul71h_ysk=.0397a5ca-505e-469c-a6de-0574e6d58fe4@github.com>
 <3EiusEynJophkZit60FyWA03NXWVjgAoCwNlJfeTh7o=.17f73dc6-3ed9-4b9e-8748-265cd25d5ac5@github.com>
 <8FTxHRmKPQ35BTBG8Kvq9Tn_2J6acpi9zdnt89U94-4=.750c3348-19de-460e-96c6-9b8f8f00d0f4@github.com>
Message-ID: <YxrEJKPfq4G4xlFj3vuFCE4CUipcxCS1xrzt9lx7j0w=.fd2a7a7a-c544-424c-b799-6b70604816cb@github.com>

On Mon, 30 Sep 2024 17:03:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> In this case there is no classic release/acquire. Instead, we rely on other properties:

Relying on data-dependency is making assumptions about what the underlying hardware memory models actually do, and is something we should generally avoid in shared code. In the abstract/general sense without a matching explicit acquire action, nothing guarantees you will see writes prior to a release-store. If we are going to rely on data-dependency then it should be clearly documented. See discussion/definitions in src/hotspot/share/runtime/orderAccess.hpp

> FWIW, a full fence is just a release+acquire on the executing thread. It has no effect on other threads. 

A full fence is more than just release+acquire as it also implies a storeLoad barrier. A full fence should ensure consistent ordering/visibility across all threads (store barriers on sparc, mfence (or equivalent) on x86, DMB on ARM,  sync on PPC). At least that is the expected semantics for hotspot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1782182531

From djelinski at openjdk.org  Tue Oct  1 06:48:42 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 1 Oct 2024 06:48:42 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v3]
In-Reply-To: <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>
Message-ID: <VdRuEeR9e354K70lJ19v4OMeWsVBRpgG9qcbFgR3FcM=.c1b63eed-ac24-41f1-996d-0373a0a59a24@github.com>

On Mon, 30 Sep 2024 16:11:14 GMT, sbgoog <duke at openjdk.org> wrote:

>> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.
>
> sbgoog has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright year

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20938#pullrequestreview-2339259547

From eirbjo at openjdk.org  Tue Oct  1 07:01:47 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 07:01:47 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <wWNKTPCK1YSqVEVn8a-RQZlIM0Jrv6Yrf7PJ-y4OAvY=.d8ae5ebd-43f0-4248-9a47-310c072271b9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <04mDTpAYPyJc_PVg2TQq1Fmvf1p7PgfVJkHDcGETuhA=.723673dc-390e-4c1b-aebb-e9867fd9d665@github.com>
 <RdZoRGPTtamByMOyg8p4Entv_jfHMnIURYQ73aHT8ks=.ea442115-c578-40f9-8517-2f58672aaa18@github.com>
 <wWNKTPCK1YSqVEVn8a-RQZlIM0Jrv6Yrf7PJ-y4OAvY=.d8ae5ebd-43f0-4248-9a47-310c072271b9@github.com>
Message-ID: <mGAEy1VlxUhE0NYzGAmIywJclUmDpXEUgiEfqeGpFkg=.6cb7d673-8ee0-4837-891d-8d16835f72b4@github.com>

On Wed, 28 Aug 2024 15:12:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>>> I think linking to the CSR would be fine, but there is no prerequisite for API specs to link to CSRs. Need @jddarcy to double check here. I was emulating `Thread.stop`:
>>> 
>>> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/Thread.java#L1637
>> 
>> I am not suggesting link to the CSR, what I was indicating the CSR provides more details  because of the proposed removal.
>> 
>> Comparing to `Thread::stop` is not quite the same, and  the verbiage you are pointing to above was added when the method was [degraded to throw a UOE](https://bugs.openjdk.org/browse/JDK-8277861), not  when it was [deprecated for removal](https://bugs.openjdk.org/browse/JDK-8277861)
>> 
>> The overall usage of ZipError is extremely minimal in the wild at best, from what I can tell was in a catch statement and was not documented to be thrown by any public  API, though was thrown by ZipFile's internal ZipEntryIterator::next
>> 
>> If this was a more heavily used Exception, it would probably warrant further consideration for additional documentation, I am not convinced it is needed here
>
> Thanks @LanceAndersen and @liach for your patient reviews.
> 
> I have updated the Specification section of the CSR and moved it to the Proposed state for an initial round of reviews:
> 
> https://bugs.openjdk.org/browse/JDK-8338663

> @eirbjo Can you answer CSR review question about whether to just deprecate the constructor of `ZipError` for removal at the CSR?

Thanks for prodding! I have provided an answer to this question in the CSR: https://bugs.openjdk.org/browse/JDK-8338663#comment-14709333

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

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2384950202

From eirbjo at openjdk.org  Tue Oct  1 07:17:36 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 07:17:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
Message-ID: <0Ld1ZT7y9YOa5JdmwZeg4eFGrpvho6eL0r_j1WODFrI=.dffe658f-cc4e-4b2a-a09b-3d881bbda7c3@github.com>

On Fri, 27 Sep 2024 01:41:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

Is `compiler` label needed? The `jar` tool belongs in `core-libs`, right? This PR does not seem to touch anything in the compiler area?

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

PR Comment: https://git.openjdk.org/jdk/pull/21141#issuecomment-2384977590

From eirbjo at openjdk.org  Tue Oct  1 07:27:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 07:27:40 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v2]
In-Reply-To: <OVD2D6d2_bPSKfSCaJUCkfiL6z0n6IGl24iED1xymWo=.d72afea5-ce00-46c0-80db-afd90b753cd5@github.com>
References: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
 <1LCpq5BdI6RVtoUAlgMVLondc1nudCguI_x_xq1m-c8=.7c2a12ba-3475-4482-b5c7-03c972be2bfb@github.com>
 <A4ZmtGpvSviFQcMwIBOr-aimR5MyvqG0n17-qsFNJdE=.e70cbf70-4f08-472b-b1ea-91c3a85a1392@github.com>
 <Znzg_hiGuEknVnkryA-zfEgPubYv4zBNf4Y1mRGQNvM=.52fe4e6f-217b-4d46-9e0a-3ebc991e9219@github.com>
 <5TIVJ2h7GO_nP_oiO2YbuDe_EG4NdzmaQQzA84vQRPE=.745c2d4f-a31f-45b3-b4c0-fb88e6791a34@github.com>
 <OVD2D6d2_bPSKfSCaJUCkfiL6z0n6IGl24iED1xymWo=.d72afea5-ce00-46c0-80db-afd90b753cd5@github.com>
Message-ID: <f9nOFIyke0n_meOIHhN-F4op8fRxduphh_2mgy7GMAc=.35185539-6f5b-42b9-9c30-1d5914926e23@github.com>

On Fri, 30 Aug 2024 13:02:21 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > If we are retrofitting the APIs docs then I think treat "GZIP" as a file format. It may require adding overrides so there is a place to document the behavior when reading an entry roll over into the next stream.
> 
> Perhaps, an additional blurb(or APINote) in the existing GZIPInputStream::read, but I think the verbiage that is being proposed with a couple tweaks covers the behavior.

Not entirely sure how to proceed here.. Did we reach consensus on the concern raised by @AlanBateman about "treating GZIP as a file format"? 

Alan, are you ok with supporting concatenated GZIP stream into a single stream, or were you suggesting that we add APIs to parse the individual compressed streams?

I'm not convinced there is any demand for this, also nothing in this proposed change prevents us from adding something like that in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/20787#issuecomment-2384993515

From mbaesken at openjdk.org  Tue Oct  1 07:28:05 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Oct 2024 07:28:05 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475
Message-ID: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>

This fixes a format string issue.

In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?

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

Commit messages:
 - JDK-8341135

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

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

From mbaesken at openjdk.org  Tue Oct  1 08:23:40 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Oct 2024 08:23:40 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <O7XW4a3YxSJeLCtbLUJ73xeINN5P0m2MQMEPtbkhuNU=.05a00a08-6a49-42be-917c-4df8702f3f9b@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <O7XW4a3YxSJeLCtbLUJ73xeINN5P0m2MQMEPtbkhuNU=.05a00a08-6a49-42be-917c-4df8702f3f9b@github.com>
Message-ID: <Lju2Q06vASMUTddIzoJX4NuaXBzbj_6_Q5KWJ72IYec=.3ef1b9b0-1da1-4622-8528-744d0a23b6e6@github.com>

On Sun, 29 Sep 2024 22:16:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> `jni_md.h` is shipped as part of every JDK distribution - this change does NOT belong in that file.

Hi David, should I introduce a separate ub.hpp  (similar to what we have in Hotspot) ?

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

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2385106189

From clanger at openjdk.org  Tue Oct  1 08:40:35 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Oct 2024 08:40:35 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475
In-Reply-To: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
Message-ID: <ezF2lAMEwqli-u9xp3SkMnXDo-gXWypqEPV0UE56ss0=.5b1855dd-5727-420f-b8ec-327354371433@github.com>

On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This fixes a format string issue.
> 
> In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
> Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21278#pullrequestreview-2339496280

From jpai at openjdk.org  Tue Oct  1 08:52:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Oct 2024 08:52:39 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
Message-ID: <eRCLAhbToWcqRDN6OVHm3R4jaJlNvLFsEVfbuV68cTQ=.6d1fecc4-69a0-42d0-8543-6208cb2dc5f4@github.com>

On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
>> 
>> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
>> 
>> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
>> 
>> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
>> 
>> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
>> 
>> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
>> 
>> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
>> 
>> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and variable from HugeCapacity tests

Hello Eirik, these changes look OK to me. Referring to this constant instead of the `Integer.MAX_VALUE - 8` is useful for the context of that value, especially in some places like the usage in `Pattern` class.
As for the test changes, I think it's OK to refer this there too, given that several of these tests are actually wanting to use a value which implies the maximum limit on the array length.
>From what I remember, adding a `@modules` in test definition makes the test run as "othervm" (even if othervm isn't explicitly specified). But I think that shouldn't matter much, at least not in this PR, because all the test definitions that are changed in this PR are already othervm (explicitly).

I am going to run tier tests against this PR in our CI. Please wait for that run to complete, before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21268#pullrequestreview-2339549362

From alanb at openjdk.org  Tue Oct  1 08:54:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Oct 2024 08:54:38 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475
In-Reply-To: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
Message-ID: <FqzD1k8B9TnMIHZTB2Ix5juulbtzQ73tEIyhT37iF4Y=.0ce085e7-639f-4ca0-b899-700161c1d780@github.com>

On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This fixes a format string issue.
> 
> In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
> Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21278#pullrequestreview-2339557955

From rgiulietti at openjdk.org  Tue Oct  1 09:07:40 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 1 Oct 2024 09:07:40 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v14]
In-Reply-To: <aa8JkQApakZQtCKIZV6zZNoYbDZWwj_hMk0I8fdjHK4=.27f12c47-6931-4222-b8dd-c6728b8b888c@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <aa8JkQApakZQtCKIZV6zZNoYbDZWwj_hMk0I8fdjHK4=.27f12c47-6931-4222-b8dd-c6728b8b888c@github.com>
Message-ID: <Py90sXGIBtDDehGuN7eq0T3X-ByjM2U-ZP4NId_6z6o=.0495f757-4c8e-4930-bf14-7c9b4c84c122@github.com>

On Sat, 28 Sep 2024 07:30:18 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small correction to ensure n > leadingZeros && nBits > leadingZeros

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 115:

> 113:             leftShiftAssertions(x, n);
> 114:         }
> 115:     }

I think this can be made `@ParameterizedTest` by refactoring `cases` into a method?

Otherwise looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1782407656

From jbhateja at openjdk.org  Tue Oct  1 09:51:27 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Oct 2024 09:51:27 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v14]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <gr0t8AMHsNLOiUnl1NiEaICixmENi5Geo1igGaQ2zPs=.fa783172-eaee-48c1-8c7d-4cc337184369@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/42ca80c5..7327736f

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

  Stats: 126 lines in 4 files changed: 60 ins; 65 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

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

From jbhateja at openjdk.org  Tue Oct  1 09:55:39 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 1 Oct 2024 09:55:39 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
Message-ID: <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>

On Mon, 30 Sep 2024 22:39:09 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I think you have to do the masking before conversion - `vec.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle()` is not the same as `vec.toShuffle()` for all inputs.
>> 
>> 
>> jshell> IntVector indexes = IntVector.fromArray(IntVector.SPECIES_256, new int[] {0, 1, 8, 9, 16, 17, 24, 25}, 0);
>> indexes ==> [0, 1, 8, 9, 16, 17, 24, 25]
>> 
>> jshell> indexes.lanewise(VectorOperators.AND, indexes.length() * 2 - 1)
>> $19 ==> [0, 1, 8, 9, 0, 1, 8, 9]
>> 
>> jshell> indexes.lanewise(VectorOperators.AND, indexes.length() * 2 - 1).toShuffle()
>> $20 ==> Shuffle[0, 1, -8, -7, 0, 1, -8, -7]
>> 
>> jshell> indexes.toShuffle()
>> $21 ==> Shuffle[0, 1, -8, -7, -8, -7, -8, -7]
>
> Thanks for the example. Yes, you have a point there.  So we would need to do:
>    src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2);

> This could instead be: src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2); Or even simplified to: src1.rearrange(this.toShuffle(), src2);

Yes, this may save additional allocation penalty of result array allocation which may slightly improve fall back performance, but logical operation cannot be directly applied over floating point vectors. so, we will need an explicit conversion to integral vector, which is why I opted for current fallback implementation which is in line with rest of the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1782480053

From mcimadamore at openjdk.org  Tue Oct  1 10:14:09 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 10:14:09 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory segment
 var handles fails to inline
Message-ID: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>

The fix for JDK-8331865 introduced an accidental performance regression.
The main issue is that now *all* memory segment var handles go through some round of adaptation.
Adapting a var handle results in a so called *indirect* var handle.
When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.

The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.

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

Commit messages:
 - DontInline slow path in MethodHandle::asType
 - Fix bench
 - Use different classloaders
 - Disable tiered compilation
 - Add benchmark

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

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

From mcimadamore at openjdk.org  Tue Oct  1 10:14:09 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 10:14:09 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline
In-Reply-To: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
Message-ID: <8o80AnU4Wqs8Z_L_qSDng9lTxOCIZILCJl-QPWEYqKo=.60c9e12d-eb3f-483a-9e21-94b19bd94627@github.com>

On Tue, 1 Oct 2024 10:08:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
> 
> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java line 57:

> 55: @State(org.openjdk.jmh.annotations.Scope.Thread)
> 56: @OutputTimeUnit(TimeUnit.MILLISECONDS)
> 57: @Fork(value = 3, jvmArgsAppend = { "-XX:-TieredCompilation" })

The benchmark only reproduces if tiered compilation is disabled. This is due to the fact that some threshold are updated accordingly, and set to a smaller value, which is enough to exhibit the issue.

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java line 96:

> 94:     static {
> 95:         types = new Class<?>[TYPE_SIZE];
> 96:         ClassLoader customLoader = new URLClassLoader(new URL[0], LoopOverNonConstantAsType.class.getClassLoader());

Technically, using a different class loadrer is not required - but using classes with different class loaders can end up taking even longer code paths when calling `MethodHandle::asType`, so I've added that here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1782505769
PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1782504664

From mcimadamore at openjdk.org  Tue Oct  1 10:18:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 10:18:15 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
Message-ID: <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>

> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
> 
> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
> 
> This problem was originally reported here:
> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
> 
> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
> 
> 
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
> 
> 
> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21283/files
  - new: https://git.openjdk.org/jdk/pull/21283/files/8c2f9789..f644d52d

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

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

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

From mcimadamore at openjdk.org  Tue Oct  1 10:26:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 10:26:36 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
Message-ID: <h-RsU2uKl1RjeESlmqyX2Z2qlxj5fDLU6vjADnpIG1g=.e57438ce-f0d7-496b-95e8-06528053ce10@github.com>

On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some round of adaptation.
>> Adapting a var handle results in a so called *indirect* var handle.
>> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
>> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
>> 
>> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
>> 
>> This problem was originally reported here:
>> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
>> 
>> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
>> 
>> 
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
>> 
>> 
>> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Benchmark results

Before:


Benchmark                               (asTypeCompiled)  Mode  Cnt  Score   Error  Units
LoopOverNonConstantAsType.segment_loop             false  avgt   30  0.232 ? 0.003  ms/op
LoopOverNonConstantAsType.segment_loop              true  avgt   30  6.943 ? 0.100  ms/op
LoopOverNonConstantAsType.unsafe_loop              false  avgt   30  0.223 ? 0.002  ms/op
LoopOverNonConstantAsType.unsafe_loop               true  avgt   30  0.227 ? 0.002  ms/op


After:


Benchmark                               (asTypeCompiled)  Mode  Cnt  Score   Error  Units
LoopOverNonConstantAsType.segment_loop             false  avgt   30  0.237 ? 0.002  ms/op
LoopOverNonConstantAsType.segment_loop              true  avgt   30  0.233 ? 0.003  ms/op
LoopOverNonConstantAsType.unsafe_loop              false  avgt   30  0.233 ? 0.002  ms/op
LoopOverNonConstantAsType.unsafe_loop               true  avgt   30  0.234 ? 0.002  ms/op

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

PR Comment: https://git.openjdk.org/jdk/pull/21283#issuecomment-2385406811

From mcimadamore at openjdk.org  Tue Oct  1 10:29:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 10:29:36 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
Message-ID: <lYHTpBprDKOn0lYR21Orf9HgDGI5FoICLG8U2_tY6OQ=.687df1be-4f12-40a9-ac34-449d96286b36@github.com>

On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some round of adaptation.
>> Adapting a var handle results in a so called *indirect* var handle.
>> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
>> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
>> 
>> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
>> 
>> This problem was originally reported here:
>> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
>> 
>> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
>> 
>> 
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
>> 
>> 
>> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Alternatives considered:
1. don't inline slow path (implemented in this PR)
2. add `@ForceInline` to `MethodHandle::asType`
3. add extra check on var handle guards to skip redundant `asType` calls

Of these, (1) was preferred as it fixes the underlying issue (and not just for memory segment var handles), while at the same time avoiding unwanted side-effects (e.g. adding `@ForceInline` can often result in too much code getting compiled, which can then create issues with other callee-side thresholds).

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

PR Comment: https://git.openjdk.org/jdk/pull/21283#issuecomment-2385412168

From redestad at openjdk.org  Tue Oct  1 10:38:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 1 Oct 2024 10:38:41 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
Message-ID: <J016KTZfdlId80PYl-KOyatiCnaj88s3EAZP-yTLXlQ=.dbce530a-549e-44b6-9f7d-9db1ed9f0a4e@github.com>

On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some round of adaptation.
>> Adapting a var handle results in a so called *indirect* var handle.
>> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
>> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
>> 
>> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
>> 
>> This problem was originally reported here:
>> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
>> 
>> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
>> 
>> 
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
>> 
>> 
>> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

LGTM

In the micro perhaps the `unsafe_loop` variant is superfluous for this special case test? At least it's distinct from the test in `LoopOverNonConstant` by summing longs rather than ints.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21283#pullrequestreview-2339816894

From duke at openjdk.org  Tue Oct  1 10:38:52 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 1 Oct 2024 10:38:52 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v15]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <rMsx0-w5SkgednjCn-miWCv8Aak7g3HWVXW9NDZv-to=.b89d9188-691e-4add-bd73-7839d0c50313@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

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

  Path-targeted tests made parameterized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/8ace0757..8e657455

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

  Stats: 20 lines in 1 file changed: 7 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

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

From mcimadamore at openjdk.org  Tue Oct  1 11:04:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 11:04:45 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <J016KTZfdlId80PYl-KOyatiCnaj88s3EAZP-yTLXlQ=.dbce530a-549e-44b6-9f7d-9db1ed9f0a4e@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
 <J016KTZfdlId80PYl-KOyatiCnaj88s3EAZP-yTLXlQ=.dbce530a-549e-44b6-9f7d-9db1ed9f0a4e@github.com>
Message-ID: <K0xtJrTeVVefz__KzeUo3ezsKa8iCWxP82xsdVZVLj0=.a5c8871c-fc08-4609-832a-e9fc1ceb2913@github.com>

On Tue, 1 Oct 2024 10:36:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> LGTM
> 
> In the micro perhaps the `unsafe_loop` variant is superfluous for this special case test? At least it's distinct from the test in `LoopOverNonConstant` by summing longs rather than ints.

Yeah - that is a bit redundant - however could be useful to have some sort of baseline, so I left it in there.

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

PR Comment: https://git.openjdk.org/jdk/pull/21283#issuecomment-2385476878

From jpai at openjdk.org  Tue Oct  1 11:06:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Oct 2024 11:06:36 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification
In-Reply-To: <TgwXDwGagCMDMxxqFMnXKxBjT8-N-oFy3KTDyXg39eU=.d0880863-ed68-493e-b048-0b4d35952b7e@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <aMa0jLHDyQVZhm5y4IqD12P4200CkPhnTk_EDmsp1X8=.a65ad4df-6599-4bf3-aa8a-a8683d75c128@github.com>
 <TgwXDwGagCMDMxxqFMnXKxBjT8-N-oFy3KTDyXg39eU=.d0880863-ed68-493e-b048-0b4d35952b7e@github.com>
Message-ID: <rpoR1rD4qRk-Lybq3CzO63ZkqB3Uvz3VSqXCbMEYdvg=.e4f8d782-265c-4fc1-93a3-5abda669539c@github.com>

On Mon, 30 Sep 2024 23:16:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Do you think, as part of this PR, we should also revisit some of the javadoc in the `java.io.FileOutputStream` class which too has several mentions of "connection"?
> 
> Are you thinking of this sentence
> 
> `A new FileDescriptor object is created to represent this file connection.`
> 
> which appears for the four constructors which do not have a `FileDescriptor` parameter? Those four sentences could probably be deleted.

Yes those were the occurences that I was curious about. Having said that, I now see that we use similar sentence even in the 2 constructors of FileInputStream and we aren't proposing to update those in this PR. So I think it should be OK to leave it in its current form in FileOutputStream.

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

PR Comment: https://git.openjdk.org/jdk/pull/21223#issuecomment-2385481581

From jpai at openjdk.org  Tue Oct  1 11:22:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Oct 2024 11:22:39 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <FhtT353ZdudsqkGwzoRXDz2rM6IdhmrCMY3N68TGsZ0=.237c203f-1d83-4211-a559-152b51ee8ff7@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <aQ7koj0VQiY7yRjBKFuTZ-ya97B8PV7V0DAvB9PQSfY=.236cb88d-da1b-4098-a334-18e854cc699a@github.com>
 <FhtT353ZdudsqkGwzoRXDz2rM6IdhmrCMY3N68TGsZ0=.237c203f-1d83-4211-a559-152b51ee8ff7@github.com>
Message-ID: <--UgqtJxOsLPF4wUxjlkXpnztA8ywLGbExhbV2BWVTo=.a0814e89-f328-43c5-88ce-0fe8406af420@github.com>

On Mon, 30 Sep 2024 15:21:31 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Some other comments also related to copied code, I can do a round of clean up.

Thank you Henry, that sounds fine to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1782590139

From asotona at openjdk.org  Tue Oct  1 11:57:34 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 1 Oct 2024 11:57:34 GMT
Subject: RFR: 8341277: Validate slot argument for instruction factories
In-Reply-To: <lODCQNzWsyYv_d8I0tu24rPWDDVTOW75rsjlV07XX4Q=.256e6f3c-b05b-470b-852d-2c1aa4d67def@github.com>
References: <lODCQNzWsyYv_d8I0tu24rPWDDVTOW75rsjlV07XX4Q=.256e6f3c-b05b-470b-852d-2c1aa4d67def@github.com>
Message-ID: <PUdLTX9enwsuXm1_YbhAuJE1SVoxs7NyHhE4AAlEAes=.c8ecf259-269f-424b-a3cd-e9e8a72c0fc5@github.com>

On Mon, 30 Sep 2024 23:36:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> Perform validation of local variable slots, multinewarray dimension, iinc value and specify these validations are performed. Specify these exception behaviors for sipush and bipush as well.
> 
> This validation avoids using invalid values that will be lost once class files are written, and avoids invalid value pollution from upstream in chained transformations.
> 
> This changes the exception specs of Class-File API, but does not block the JEP as it does not change the intended functionality of these APIs.
> 
> Unfortunately, I cannot test the DirectCodeBuilder overloads due to it failing to generate stack maps, so the tests are restricted to instruction factories.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21275#pullrequestreview-2339982638

From dholmes at openjdk.org  Tue Oct  1 12:17:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Oct 2024 12:17:35 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Lju2Q06vASMUTddIzoJX4NuaXBzbj_6_Q5KWJ72IYec=.3ef1b9b0-1da1-4622-8528-744d0a23b6e6@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <O7XW4a3YxSJeLCtbLUJ73xeINN5P0m2MQMEPtbkhuNU=.05a00a08-6a49-42be-917c-4df8702f3f9b@github.com>
 <Lju2Q06vASMUTddIzoJX4NuaXBzbj_6_Q5KWJ72IYec=.3ef1b9b0-1da1-4622-8528-744d0a23b6e6@github.com>
Message-ID: <lBxAov7ABSFECQOiP-Ie5ZWKQANY3npogpa0UY76EMo=.282139e4-a1d1-429a-bcd2-689541143f81@github.com>

On Tue, 1 Oct 2024 08:20:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi David, should I introduce a separate ub.hpp (similar to what we have in Hotspot) ?

As previously discussed above a separate header would be best, though I'm not sure where it would be placed if you are using this across code in different modules.

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

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2385620062

From shade at openjdk.org  Tue Oct  1 12:25:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Oct 2024 12:25:36 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475
In-Reply-To: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
Message-ID: <bYmLGcBBvfwH9DPvpwLK5mXrk0jS7BIIwprtre2VwNo=.03edf1ad-9b1d-472a-a54a-29d31aeec364@github.com>

On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This fixes a format string issue.
> 
> In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
> Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?

Marked as reviewed by shade (Reviewer).

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

> 313:     rc = pthread_create(&main_thr, NULL, &apple_main, &args);
> 314:     if (rc != 0) {
> 315:         JLI_ReportErrorMessageSys("Could not create main thread, return code:%d\n", rc);

Shouldn't there be a space in between, `return code: %d`?

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

PR Review: https://git.openjdk.org/jdk/pull/21278#pullrequestreview-2340041653
PR Review Comment: https://git.openjdk.org/jdk/pull/21278#discussion_r1782670820

From mbaesken at openjdk.org  Tue Oct  1 12:43:39 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Oct 2024 12:43:39 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475
In-Reply-To: <bYmLGcBBvfwH9DPvpwLK5mXrk0jS7BIIwprtre2VwNo=.03edf1ad-9b1d-472a-a54a-29d31aeec364@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
 <bYmLGcBBvfwH9DPvpwLK5mXrk0jS7BIIwprtre2VwNo=.03edf1ad-9b1d-472a-a54a-29d31aeec364@github.com>
Message-ID: <Ix8U_Ii2MdxlAuWLoqDVJoRUBTF5CBoYeUN2CbiEIrM=.06141d02-1373-4caa-aeee-b8762dca9b78@github.com>

On Tue, 1 Oct 2024 12:22:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This fixes a format string issue.
>> 
>> In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
>> Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?
>
> src/java.base/macosx/native/libjli/java_md_macosx.m line 315:
> 
>> 313:     rc = pthread_create(&main_thr, NULL, &apple_main, &args);
>> 314:     if (rc != 0) {
>> 315:         JLI_ReportErrorMessageSys("Could not create main thread, return code:%d\n", rc);
> 
> Shouldn't there be a space in between, `return code: %d`?

I can live with both, not sure what is preferred.  In the corresponding fprintf output of 8339475 there is no space.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21278#discussion_r1782698968

From clanger at openjdk.org  Tue Oct  1 13:01:35 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Oct 2024 13:01:35 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475
In-Reply-To: <Ix8U_Ii2MdxlAuWLoqDVJoRUBTF5CBoYeUN2CbiEIrM=.06141d02-1373-4caa-aeee-b8762dca9b78@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
 <bYmLGcBBvfwH9DPvpwLK5mXrk0jS7BIIwprtre2VwNo=.03edf1ad-9b1d-472a-a54a-29d31aeec364@github.com>
 <Ix8U_Ii2MdxlAuWLoqDVJoRUBTF5CBoYeUN2CbiEIrM=.06141d02-1373-4caa-aeee-b8762dca9b78@github.com>
Message-ID: <F2ibOw-ZhMqvbCce0ofIQmQmEhISXwSpgKBefo0YX8U=.9577c3a0-70db-4b67-a0a6-bf940ac85604@github.com>

On Tue, 1 Oct 2024 12:40:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.base/macosx/native/libjli/java_md_macosx.m line 315:
>> 
>>> 313:     rc = pthread_create(&main_thr, NULL, &apple_main, &args);
>>> 314:     if (rc != 0) {
>>> 315:         JLI_ReportErrorMessageSys("Could not create main thread, return code:%d\n", rc);
>> 
>> Shouldn't there be a space in between, `return code: %d`?
>
> I can live with both, not sure what is preferred.  In the corresponding fprintf output of 8339475 there is no space.

I think a space would be nicer. ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21278#discussion_r1782726535

From rgiulietti at openjdk.org  Tue Oct  1 13:14:38 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 1 Oct 2024 13:14:38 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v14]
In-Reply-To: <Py90sXGIBtDDehGuN7eq0T3X-ByjM2U-ZP4NId_6z6o=.0495f757-4c8e-4930-bf14-7c9b4c84c122@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <aa8JkQApakZQtCKIZV6zZNoYbDZWwj_hMk0I8fdjHK4=.27f12c47-6931-4222-b8dd-c6728b8b888c@github.com>
 <Py90sXGIBtDDehGuN7eq0T3X-ByjM2U-ZP4NId_6z6o=.0495f757-4c8e-4930-bf14-7c9b4c84c122@github.com>
Message-ID: <xMB0gyCiGbn02_DDJfLpv08ZuYez9UpC-BZVXhFeFhY=.5524956e-879c-4b05-a582-8f87b9c7dea5@github.com>

On Tue, 1 Oct 2024 09:02:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Small correction to ensure n > leadingZeros && nBits > leadingZeros
>
> test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 115:
> 
>> 113:             leftShiftAssertions(x, n);
>> 114:         }
>> 115:     }
> 
> I think this can be made `@ParameterizedTest` by refactoring `cases` into a method?
> 
> Otherwise looks good.

This doesn't run.

You should use JUnit's `Arguments` type and `arguments` method to build the test cases with [multiple parameters](https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests-sources-MethodSource), and change the header of the parameterized test to reflect them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1782757196

From mbaesken at openjdk.org  Tue Oct  1 13:15:51 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Oct 2024 13:15:51 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475 [v2]
In-Reply-To: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
Message-ID: <uSYUXwwCfYtKuWOr1kPbObfUxwG1CcSiSRGyVYptfv4=.9676e607-d0c8-4217-a683-b89e2a7a3561@github.com>

> This fixes a format string issue.
> 
> In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
> Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  use blank in output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21278/files
  - new: https://git.openjdk.org/jdk/pull/21278/files/1d649c89..9db76777

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

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

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

From shade at openjdk.org  Tue Oct  1 13:21:38 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 1 Oct 2024 13:21:38 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475 [v2]
In-Reply-To: <uSYUXwwCfYtKuWOr1kPbObfUxwG1CcSiSRGyVYptfv4=.9676e607-d0c8-4217-a683-b89e2a7a3561@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
 <uSYUXwwCfYtKuWOr1kPbObfUxwG1CcSiSRGyVYptfv4=.9676e607-d0c8-4217-a683-b89e2a7a3561@github.com>
Message-ID: <ElDu8ugPmQ1j8l6LpPVfAOJ6-TG_YGPU-WiXPNCDmxQ=.38aa87e2-e4ca-421e-b973-e126e54d5d36@github.com>

On Tue, 1 Oct 2024 13:15:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This fixes a format string issue.
>> 
>> In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
>> Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use blank in output

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21278#pullrequestreview-2340225048

From mbaesken at openjdk.org  Tue Oct  1 13:26:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Oct 2024 13:26:37 GMT
Subject: RFR: 8341135: Incorrect format string after JDK-8339475 [v2]
In-Reply-To: <uSYUXwwCfYtKuWOr1kPbObfUxwG1CcSiSRGyVYptfv4=.9676e607-d0c8-4217-a683-b89e2a7a3561@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
 <uSYUXwwCfYtKuWOr1kPbObfUxwG1CcSiSRGyVYptfv4=.9676e607-d0c8-4217-a683-b89e2a7a3561@github.com>
Message-ID: <IEE46cSRn2AW4cD08-9ipUez_o4a-BaoG58rl5qxDaU=.d9b6777b-3d71-4d97-b27a-47d9ac6389bf@github.com>

On Tue, 1 Oct 2024 13:15:51 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This fixes a format string issue.
>> 
>> In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
>> Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use blank in output

Btw. in hotspot we have ATTRIBUTE_PRINTF  (from compilerWarnings_gcc.hpp); should we use something similar too in non-hotspot C  coding?

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

PR Comment: https://git.openjdk.org/jdk/pull/21278#issuecomment-2385840267

From zzambers at openjdk.org  Tue Oct  1 13:28:44 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 1 Oct 2024 13:28:44 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v9]
In-Reply-To: <NHU4AA8r7Ws8FYvfLDQ1XPxYBqGJS_PPG_dLmsEw0Eo=.e4d3e2d2-0d07-4593-a8bc-7602fbd0ff59@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <NHU4AA8r7Ws8FYvfLDQ1XPxYBqGJS_PPG_dLmsEw0Eo=.e4d3e2d2-0d07-4593-a8bc-7602fbd0ff59@github.com>
Message-ID: <ZffKwrV_XFwTxMs3BPue_-_jGbR1kDUJE_QmwXK44ks=.ce5a72fb-2452-426c-aa98-00bd84526e06@github.com>

On Mon, 30 Sep 2024 12:03:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> 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 34 commits:
> 
>  - 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
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/475b8943...92426dbf

I can confirm that `jdk/internal/platform` tests now pass for me on RHEL-9 (cgroup v2)

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2385851987

From mbaesken at openjdk.org  Tue Oct  1 13:45:56 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Oct 2024 13:45:56 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove ubsan changes from jni_md.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21184/files
  - new: https://git.openjdk.org/jdk/pull/21184/files/a2f89ecf..fb17d1bc

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

  Stats: 57 lines in 4 files changed: 44 ins; 13 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21184/head:pull/21184

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

From jlahoda at openjdk.org  Tue Oct  1 13:51:41 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 1 Oct 2024 13:51:41 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v15]
In-Reply-To: <jrUNyuO71nVf9r_jcX9Mgl-XZuSi8jiCsbo2VvDG024=.a46d6da5-e82d-4b4c-8a91-980045f88704@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <jrUNyuO71nVf9r_jcX9Mgl-XZuSi8jiCsbo2VvDG024=.a46d6da5-e82d-4b4c-8a91-980045f88704@github.com>
Message-ID: <3Iag-0d8k1GrB3E-q_qTCHvOUhHIjlp_OtHcxfkJV74=.9bfb71ae-4d84-4bb3-8c33-b44a8a26f82b@github.com>

On Fri, 20 Sep 2024 14:02:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - exclude list is now module specific
>  - remove empty if statement, debugging showed the condition is never true
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/3c22d83c...62a34064

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18934#pullrequestreview-2340402628

From jlahoda at openjdk.org  Tue Oct  1 13:51:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 1 Oct 2024 13:51:43 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v14]
In-Reply-To: <tr3sE4c2DTU7iMbdn6cC6Z6TbCvaPwE9_MBIHPaYhWc=.5c95ef32-7c71-441a-85a6-a369911475a7@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <6UtodC3cmN3mn6FhftLXBq1fGkxEegEFsdKtWymeY0Q=.3065f8d4-afb2-4c22-b617-7617ec81a645@github.com>
 <tr3sE4c2DTU7iMbdn6cC6Z6TbCvaPwE9_MBIHPaYhWc=.5c95ef32-7c71-441a-85a6-a369911475a7@github.com>
Message-ID: <DG2kU5Ekl98z8hFwunG2XY5I0VytZBJTVQNhoDpvjTI=.22cee590-58a1-4066-93f8-0d1f1e69cf17@github.com>

On Thu, 19 Sep 2024 22:12:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
>> 
>>  - Change "found" to "should be" in the error messages
>>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>>  - avoid using `continue`, fix mistake in last commit
>>  - extend SinceChecker to now skip some packages
>>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>>  - Skip over files and packages that aren't found
>>  - Move the tests to module/module_name directory for clearer naming
>>  - (C)
>>  - ... and 18 more: https://git.openjdk.org/jdk/compare/bc36ace7...d355222e
>
> test/jdk/tools/sincechecker/SinceChecker.java line 152:
> 
>> 150:             String version = String.valueOf(i);
>> 151:             Elements elements = ct.getElements();
>> 152:             elements.getModuleElement("java.base"); // forces module graph to be instantiated
> 
> @lahodaj I've always considered this kind of line to be a workaround; it would be nice if we could have an RFE so this kind of line was unnecessary in code that wants to introspect the elements

Thanks. I've filled:
https://bugs.openjdk.org/browse/JDK-8341342

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18934#discussion_r1782887236

From jvernee at openjdk.org  Tue Oct  1 14:02:48 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 1 Oct 2024 14:02:48 GMT
Subject: RFR: 8340812: LambdaForm customization via
 MethodHandle::updateForm is not thread safe
In-Reply-To: <YxrEJKPfq4G4xlFj3vuFCE4CUipcxCS1xrzt9lx7j0w=.fd2a7a7a-c544-424c-b799-6b70604816cb@github.com>
References: <iHho__XUEtV7Yx7mNtJ3fE8k4rxvoEXZ0VVJ9z-Lc0g=.f7e50d8e-3f2a-430a-a4ee-bda5eab8c10b@github.com>
 <c2OPb3rALMYVdgwQFtkTZCmrCRQxDo8Xkb2cq8afpmA=.f37ae57b-700d-4b64-9be1-a7c201a56bc0@github.com>
 <BPXpziMnJ5abo68eNo6ClJH2c-eTDmJbT0ul71h_ysk=.0397a5ca-505e-469c-a6de-0574e6d58fe4@github.com>
 <3EiusEynJophkZit60FyWA03NXWVjgAoCwNlJfeTh7o=.17f73dc6-3ed9-4b9e-8748-265cd25d5ac5@github.com>
 <8FTxHRmKPQ35BTBG8Kvq9Tn_2J6acpi9zdnt89U94-4=.750c3348-19de-460e-96c6-9b8f8f00d0f4@github.com>
 <YxrEJKPfq4G4xlFj3vuFCE4CUipcxCS1xrzt9lx7j0w=.fd2a7a7a-c544-424c-b799-6b70604816cb@github.com>
Message-ID: <K1uS6GNAUWWoyHdqnPblWI8lHaUUIgqiuyXSIwS61Aw=.2f9aac9a-1aaa-4b7e-838a-ea1e5eef16f1@github.com>

On Tue, 1 Oct 2024 06:28:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In this case there is no classic release/acquire. Instead, we rely on other properties: The `vmentry` field is loaded in `MethodHandles::jump_to_lambda_form`, using a plain load. I believe a load-acquire is not needed here because we have a data dependency: we load the `vmentry` field from `form`, and the initialization of the `vmentry` field takes place before the new value of `form` is published. This, combined with the guarantee that a newly allocated object will always have to be freshly loaded after its publication, means that if a thread sees the new `form` field value, it will also see the new `vmentry` field in the subsequent load. (This is also why safe publication works AFAIK)
>> 
>>> A full-fence is a one-sided global synchronization action.
>> 
>> FWIW, a full fence is just a release+acquire on the executing thread. It has no effect on other threads. All the fences in `Unsafe` are like that. (The only exception I know of is what is done by `SystemMemoryBarrier` in hotspot)
>
>> In this case there is no classic release/acquire. Instead, we rely on other properties:
> 
> Relying on data-dependency is making assumptions about what the underlying hardware memory models actually do, and is something we should generally avoid in shared code. In the abstract/general sense without a matching explicit acquire action, nothing guarantees you will see writes prior to a release-store. If we are going to rely on data-dependency then it should be clearly documented. See discussion/definitions in src/hotspot/share/runtime/orderAccess.hpp
> 
>> FWIW, a full fence is just a release+acquire on the executing thread. It has no effect on other threads. 
> 
> A full fence is more than just release+acquire as it also implies a storeLoad barrier. A full fence should ensure consistent ordering/visibility across all threads (store barriers on sparc, mfence (or equivalent) on x86, DMB on ARM,  sync on PPC). At least that is the expected semantics for hotspot.

Ok, I was under the, apparently false, impression that synchronization _always_ required some kind of action by both threads (I'm more likely to be misremembering though). But from reading the section on cache coherency in orderAccess.hpp, it sounds like these fences are at least semantically expected to affect other threads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1782921510

From duke at openjdk.org  Tue Oct  1 14:06:16 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 1 Oct 2024 14:06:16 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v16]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <hN1mMlGZ0DGUo3jfoj2dv-RusbtnV47CAQD_ffargKY=.10bded66-dcbb-402e-8e22-6e3b117535cc@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

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

  Test cases' arguments correction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/8e657455..6d228a3a

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

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

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

From jvernee at openjdk.org  Tue Oct  1 14:18:40 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 1 Oct 2024 14:18:40 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
Message-ID: <oMO3VuFNTJg70ijTJVbefBPVSqaSvVKkTwhWxjB6KDk=.4345cca5-716a-469b-abb7-fec07d16adf8@github.com>

On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some round of adaptation.
>> Adapting a var handle results in a so called *indirect* var handle.
>> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
>> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
>> 
>> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
>> 
>> This problem was originally reported here:
>> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
>> 
>> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
>> 
>> 
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
>> 
>> 
>> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 889:

> 887:     }
> 888: 
> 889:     @DontInline

Could you leave a comment explaining why we put `DontInline` here?

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java line 103:

> 101:     }
> 102: 
> 103:     @CompilerControl(CompilerControl.Mode.DONT_INLINE)

I think the intent was to block inlining of `asType`, so it gets compiled in isolation? That should be done with a `CompileCommand` though. This annotation just blocks inlining of `compileAsType` AFAIK.

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java line 136:

> 134:         for (int i = 0; i < ELEM_SIZE; i++) {
> 135:             sum += segment.get(JAVA_LONG, i * CARRIER_SIZE);
> 136: 

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1782937040
PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1782940655
PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1782944436

From duke at openjdk.org  Tue Oct  1 14:21:19 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 1 Oct 2024 14:21:19 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

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/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/6d228a3a..d324f495

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

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

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

From iklam at openjdk.org  Tue Oct  1 15:28:34 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 1 Oct 2024 15:28:34 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v6]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <HFE-SPbjBDxLvME6gEbH8kL6GruM3wTa2c5jrKTFlBk=.d3eb6ace-bc40-42e0-9ab9-4cbedd2a72c6@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request incrementally with 93 additional commits since the last revision:

 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - Merge branch 'jep-483-step-03-8329706-implement-xx-aot-class-linking' of /jdk3/yak/open into jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap
 - Merge branch 'jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver' into jep-483-step-03-8329706-implement-xx-aot-class-linking
 - Merge branch 'jep-483-step-01-8338017-add-aot-command-line-aliases' into jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver
 - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
 - 8340864: Remove unused lines related to vmClasses
   
   Reviewed-by: shade, kvn
 - 8340831: Simplify simple validation for class definition in MethodHandles.Lookup
   
   Reviewed-by: redestad
 - 8340838: Clean up MutableCallSite to use explicit release fence instead of AtomicInteger
   
   Reviewed-by: jrose, redestad, shade
 - 8340956: ProblemList 4 java/nio/channels/DatagramChannel tests on macosx-all
   
   Reviewed-by: liach, alanb, darcy, dfuchs
 - ... and 83 more: https://git.openjdk.org/jdk/compare/b383d24b...b8187149

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/b383d24b..b8187149

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

  Stats: 12294 lines in 294 files changed: 9757 ins; 1520 del; 1017 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

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

From rgiulietti at openjdk.org  Tue Oct  1 15:36:41 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 1 Oct 2024 15:36:41 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]
In-Reply-To: <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
Message-ID: <SdOGRcmvH0vrSFBMkIJS3-3WLuAV-SWqvfWIs6s_GjM=.f4fa428f-3713-44f7-aaa9-04ed66053759@github.com>

On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 69:

> 67:     @MethodSource("pathTargetedCases")
> 68:     public void test(MutableBigIntegerBox x, int n) {
> 69:         leftShiftAssertions(x, n);

One last thing... It would make sense to inline `leftShiftAssertions()` and remove it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1783090677

From smarks at openjdk.org  Tue Oct  1 15:45:39 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 15:45:39 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
Message-ID: <SxL_WkU_G5sjVYLrZwhKyDBm_B5I1ryrQYp8wzV1Xek=.880c20d0-5245-47e5-8186-c37f5cc688f2@github.com>

On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
>> 
>> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
>> 
>> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
>> 
>> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
>> 
>> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
>> 
>> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
>> 
>> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
>> 
>> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and variable from HugeCapacity tests

Marked as reviewed by smarks (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21268#pullrequestreview-2340765971

From smarks at openjdk.org  Tue Oct  1 15:45:40 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 1 Oct 2024 15:45:40 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
In-Reply-To: <BJQGK40yRqnFkWP4jmyXhzJNEOTugvOL_UZ3OWiurUE=.11fdba8e-18ba-4228-85df-a00c622f32fc@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <P5DvIyvR3brhe9FlhK-UDwJ36Xbwh4dkacg8GGVjq-k=.757482fa-4e24-4749-a10b-43b3cad80191@github.com>
 <BJQGK40yRqnFkWP4jmyXhzJNEOTugvOL_UZ3OWiurUE=.11fdba8e-18ba-4228-85df-a00c622f32fc@github.com>
Message-ID: <kuxkbvZxpTC3Ealo9oEte922TsySKqIa8kotJeiXs_I=.aab96cbc-5041-4724-bde1-1b5b79e4e2f6@github.com>

On Tue, 1 Oct 2024 05:52:23 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> As this stands (modulo my other comments) this change is mostly OK. Using the SOFT_MAX value within java.base is fine. Using SOFT_MAX within java.base-related tests is a little suspicious, because it requires the addition of directives that export an internal package from java.base ... but these tests are generally expected to be closely coupled with java.base internals, so they're probably ok too.
>> 
>> I agree with the decision not to expand usage of SOFT_MAX further, as it's really just a guess at a VM implementation limit that's not defined anywhere. (There have been requests to make this public; see [JDK-8246725](https://bugs.openjdk.org/browse/JDK-8246725), which I'm opposed to.) The *real* fix here is to fix the JVM so that it can allocate arrays of Integer.MAX_VALUE. From time to time I hear rumors that this might happen at some point. Meanwhile, let's not expose something with ill-defined semantics like SOFT_MAX beyond java.base.
>> 
>> As an aside, for your own edification, you might want to verify that compile-time constants are indeed inlined, by inspecting the before-and-after bytecode. This is well documented; see JLS 13.1, item 3 of the first numbered list in that section. I'm sure this is well tested, so there's no need for a test for this.
>
>> As this stands (modulo my other comments) this change is mostly OK. Using the SOFT_MAX value within java.base is fine. Using SOFT_MAX within java.base-related tests is a little suspicious, because it requires the addition of directives that export an internal package from java.base ... but these tests are generally expected to be closely coupled with java.base internals, so they're probably ok too.
> 
> I was pondering a bit whether to include tests. The use of the constant perhaps aids understanding even more here, because the value might seem "more magic" , being  further removed from where actual allocation takes place. Tests are a useful tool for understanding APIs and their implementation, so less magic feels like an improvement. Also, we want to update tests as well if the implementation limit is lifted, this makes that update easier.  
> 
>> I agree with the decision not to expand usage of SOFT_MAX further, as it's really just a guess at a VM implementation limit that's not defined anywhere. (There have been requests to make this public; see [JDK-8246725](https://bugs.openjdk.org/browse/JDK-8246725), which I'm opposed to.) The _real_ fix here is to fix the JVM so that it can allocate arrays of Integer.MAX_VALUE. From time to time I hear rumors that this might happen at some point. Meanwhile, let's not expose something with ill-defined semantics like SOFT_MAX beyond java.base.
> 
> Good, I initially included code outside `java.base`, but that quicly got messy.
> 
>> As an aside, for your own edification, you might want to verify that compile-time constants are indeed inlined, by inspecting the before-and-after bytecode. This is well documented; see JLS 13.1, item 3 of the first numbered list in that section. I'm sure this is well tested, so there's no need for a test for this.
> 
> Thanks for the JLS pointer, good that this is not just a javac implementation detail.
>  
> Confirmed this using:
> 
> % javap -c -p -constants java.io.InputStream | grep MAX_BUFFER_SIZE`
> private static final int MAX_BUFFER_SIZE = 2147483639;
> % javap -c -p -constants java.io.InputStream  | grep ArraySupport

@eirbjo Thanks for your thoughts on using the constant in the tests. It all makes good sense.

@jaikiran Thanks for handling testing for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2386362465

From alanb at openjdk.org  Tue Oct  1 15:49:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Oct 2024 15:49:40 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification
In-Reply-To: <yAKIIJjTwQsnnhzKTcA08FpCKvLp3tRP8mMvc1sYQ3I=.37d57641-760c-4ea7-95a0-3c7447d721a7@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <aMa0jLHDyQVZhm5y4IqD12P4200CkPhnTk_EDmsp1X8=.a65ad4df-6599-4bf3-aa8a-a8683d75c128@github.com>
 <yAKIIJjTwQsnnhzKTcA08FpCKvLp3tRP8mMvc1sYQ3I=.37d57641-760c-4ea7-95a0-3c7447d721a7@github.com>
Message-ID: <OuGkM5CvXMMqpzdXLYybtabk_QFYZw-2lzy28DCjr4s=.9a90cb6a-09f7-4fa4-904c-8d0cac2ae84f@github.com>

On Mon, 30 Sep 2024 23:13:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileInputStream.java line 118:
>> 
>>> 116:     /**
>>> 117:      * Creates a {@code FileInputStream} to read from an existing file
>>> 118:      * named by the {@code File} object {@code file}.
>> 
>> Hello Brian, should be perhaps reword this as "... to read from an existing file represented by the {@code file}." This would almost match what we state for the constructor which takes the `FileDescriptor` instance.
>
> Updated for the next commit.

Did you push that commit? I don't see the update, the PR only has 1 commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1783108409

From duke at openjdk.org  Tue Oct  1 15:53:38 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 1 Oct 2024 15:53:38 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
Message-ID: <PSqAOOMP-b0w8KjfuVMf_ghQbN6WO6T0Ysm-S6_XEzg=.d42deb2a-7415-47f4-911c-f981d1c803d9@github.com>

On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s 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 ziperror-deprecation
>  - Simplify the deprecation note by focusing on behavior in the current release
>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>  - Update copyright year
>  - Deprecate java.util.zip.ZipError for removal

The?issue with?removing `ZipError` (or?any?other exception?class, such?as?`SecurityException`), is?that existing?classes which?reference?it in?the?`exception_table` of?a?`Code`?attribute will?fail?verification.

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

This?is?different from?referencing removed?classes in?method or?field?descriptors, those?get?treated as?if?they?had the?following?declaration for?the?purposes of?verification when?determining whether?`checkcast`s are?necessary:

public abstract final class <name> extends Object {
}

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

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2386382509

From mcimadamore at openjdk.org  Tue Oct  1 15:54:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 15:54:19 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v3]
In-Reply-To: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
Message-ID: <eClVQ4pZ5T3MgA8ET2U96GtcVrWgXAX3e52w2_88sZ4=.ab9fe5e6-8448-40d1-88e4-c1dd056ed7d1@github.com>

> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
> 
> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
> 
> This problem was originally reported here:
> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
> 
> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
> 
> 
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
> 
> 
> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21283/files
  - new: https://git.openjdk.org/jdk/pull/21283/files/f644d52d..4fee4d28

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

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

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

From mcimadamore at openjdk.org  Tue Oct  1 15:54:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 15:54:20 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <oMO3VuFNTJg70ijTJVbefBPVSqaSvVKkTwhWxjB6KDk=.4345cca5-716a-469b-abb7-fec07d16adf8@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
 <oMO3VuFNTJg70ijTJVbefBPVSqaSvVKkTwhWxjB6KDk=.4345cca5-716a-469b-abb7-fec07d16adf8@github.com>
Message-ID: <Q2meopQvf8afdzX18yA6TauJRvIrcFpO7OnD5_1dTlY=.f144da28-8a1b-4bd1-8399-ea6ca95ac5c6@github.com>

On Tue, 1 Oct 2024 14:10:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright
>
> test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java line 103:
> 
>> 101:     }
>> 102: 
>> 103:     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
> 
> I think the intent was to block inlining of `asType`, so it gets compiled in isolation? That should be done with a `CompileCommand` though. This annotation just blocks inlining of `compileAsType` AFAIK.

I see what you mean... I'll do some experiments and see how the current annotation affects the benchmark - if at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1783112144

From duke at openjdk.org  Tue Oct  1 16:06:38 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 1 Oct 2024 16:06:38 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]
In-Reply-To: <SdOGRcmvH0vrSFBMkIJS3-3WLuAV-SWqvfWIs6s_GjM=.f4fa428f-3713-44f7-aaa9-04ed66053759@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
 <SdOGRcmvH0vrSFBMkIJS3-3WLuAV-SWqvfWIs6s_GjM=.f4fa428f-3713-44f7-aaa9-04ed66053759@github.com>
Message-ID: <vx2cpoZ-kbs-jJ5CErx7Y6K3T_R-I30AoWhn3xrFGLg=.a3b246e3-a8c5-4de5-a71b-dc27fb2855db@github.com>

On Tue, 1 Oct 2024 15:34:12 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
>
> test/jdk/java/math/BigInteger/MutableBigIntegerShiftTests.java line 69:
> 
>> 67:     @MethodSource("pathTargetedCases")
>> 68:     public void test(MutableBigIntegerBox x, int n) {
>> 69:         leftShiftAssertions(x, n);
> 
> One last thing... It would make sense to inline `leftShiftAssertions()` and remove it?

I preferred to put the assertions in a different method, in case that tests for `MBI.rightShift()` would be added in future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20008#discussion_r1783136391

From bpb at openjdk.org  Tue Oct  1 16:08:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 16:08:56 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification [v2]
In-Reply-To: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
Message-ID: <UetM6IVXP1D5fn9NGjJALDixrGPO51YjgW2bSEnvOF8=.c56af6e1-9ab7-4d85-9d20-53f6cf9abea8@github.com>

> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8340229: Revert FIS(fdObj) change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21223/files
  - new: https://git.openjdk.org/jdk/pull/21223/files/9dd615a3..d345bce5

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

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

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

From bpb at openjdk.org  Tue Oct  1 16:08:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 16:08:57 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification [v2]
In-Reply-To: <OuGkM5CvXMMqpzdXLYybtabk_QFYZw-2lzy28DCjr4s=.9a90cb6a-09f7-4fa4-904c-8d0cac2ae84f@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <aMa0jLHDyQVZhm5y4IqD12P4200CkPhnTk_EDmsp1X8=.a65ad4df-6599-4bf3-aa8a-a8683d75c128@github.com>
 <yAKIIJjTwQsnnhzKTcA08FpCKvLp3tRP8mMvc1sYQ3I=.37d57641-760c-4ea7-95a0-3c7447d721a7@github.com>
 <OuGkM5CvXMMqpzdXLYybtabk_QFYZw-2lzy28DCjr4s=.9a90cb6a-09f7-4fa4-904c-8d0cac2ae84f@github.com>
Message-ID: <UboCkDS36OXOJAqt_9_dzscI1XSlR0Cu4wXyQug4tCU=.62ea56a0-d00d-437d-b6fa-071933b3fec2@github.com>

On Tue, 1 Oct 2024 15:46:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updated for the next commit.
>
> Did you push that commit? I don't see the update, the PR only has 1 commit.

I did just now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1783138693

From mcimadamore at openjdk.org  Tue Oct  1 16:11:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 16:11:38 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <Q2meopQvf8afdzX18yA6TauJRvIrcFpO7OnD5_1dTlY=.f144da28-8a1b-4bd1-8399-ea6ca95ac5c6@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
 <oMO3VuFNTJg70ijTJVbefBPVSqaSvVKkTwhWxjB6KDk=.4345cca5-716a-469b-abb7-fec07d16adf8@github.com>
 <Q2meopQvf8afdzX18yA6TauJRvIrcFpO7OnD5_1dTlY=.f144da28-8a1b-4bd1-8399-ea6ca95ac5c6@github.com>
Message-ID: <RISMgNKDps8ZGdE8raS-gfBxbd7fU7PKSFnHucyBrpY=.ed4d006c-dd6c-4a13-aca9-16f35832684c@github.com>

On Tue, 1 Oct 2024 15:49:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/foreign/LoopOverNonConstantAsType.java line 103:
>> 
>>> 101:     }
>>> 102: 
>>> 103:     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>> 
>> I think the intent was to block inlining of `asType`, so it gets compiled in isolation? That should be done with a `CompileCommand` though. This annotation just blocks inlining of `compileAsType` AFAIK.
>
> I see what you mean... I'll do some experiments and see how the current annotation affects the benchmark - if at all.

The issue with using a compile command is that it will then work globally. So the benchmark would not really test much - besides checking that var handle access is slow when `asType` cannot inline. What I was trying to do here was to avoid `asType` being inlined into that `compileAsType` method - but I agree that the annotation I added isn't it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1783141389

From alanb at openjdk.org  Tue Oct  1 16:15:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Oct 2024 16:15:42 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
Message-ID: <LNf1m1HJWfuZRvdxMQmXGFZtqS5e2RpFhkggoMfyPUc=.bcdb38ad-3e51-409d-a5e2-95259bc1eed8@github.com>

On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s 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 ziperror-deprecation
>  - Simplify the deprecation note by focusing on behavior in the current release
>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>  - Update copyright year
>  - Deprecate java.util.zip.ZipError for removal

src/java.base/share/classes/java/util/zip/ZipError.java line 31:

> 29:  * Signals that an unrecoverable error has occurred.
> 30:  *
> 31:  * @deprecated ZipError is no longer used and is obsolete.

I agree ZipError should be deprecated. Can the JBS issue and PR title be updated as they still have "for removal".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1783148525

From eirbjo at openjdk.org  Tue Oct  1 16:17:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 16:17:35 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
Message-ID: <v_UyMOjDYMVKU2v7tqxOJfOeoHX0e3JdHaEkPi-tPo4=.2390255b-1ddb-42f9-b81a-017490936d30@github.com>

On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
>> 
>> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
>> 
>> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
>> 
>> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
>> 
>> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
>> 
>> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
>> 
>> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
>> 
>> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and variable from HugeCapacity tests

Thanks for taking time to review this Stuart. 

I'm delegating the integration of this PR such that @jaikiran can take care of that once his test run is complete.

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2386435858

From liach at openjdk.org  Tue Oct  1 16:23:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Oct 2024 16:23:41 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <PSqAOOMP-b0w8KjfuVMf_ghQbN6WO6T0Ysm-S6_XEzg=.d42deb2a-7415-47f4-911c-f981d1c803d9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
 <PSqAOOMP-b0w8KjfuVMf_ghQbN6WO6T0Ysm-S6_XEzg=.d42deb2a-7415-47f4-911c-f981d1c803d9@github.com>
Message-ID: <zRuJCX04neHd04Bg_l2XcdR1tbUCXiUOi74o6XGfRio=.1ba88af0-b773-49a4-89fe-1b6a3cf34590@github.com>

On Tue, 1 Oct 2024 15:50:59 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Eirik Bj?rsn?s 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 ziperror-deprecation
>>  - Simplify the deprecation note by focusing on behavior in the current release
>>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>>  - Update copyright year
>>  - Deprecate java.util.zip.ZipError for removal
>
> The?issue with?removing `ZipError` (or?any?other exception?class, such?as?`SecurityException`), is?that existing?classes which?reference?it in?the?`exception_table` of?a?`Code`?attribute will?fail?verification.
> 
> --------------------------------------------------------------------------------
> 
> This?is?different from?referencing removed?classes in?method or?field?descriptors, those?get?treated as?if?they?had the?following?declaration for?the?purposes of?verification when?determining whether?`checkcast`s are?necessary:
> 
> public abstract final class <name> extends Object {
> }

@ExE-Boss Indeed, the removal is intended to be binary incompatible. Just like the example in [the fucntional removal of SecurityManager(https://openjdk.org/jeps/486), users can instrument or statically preprocess their `java/util/zip/ZipError` class entries to `java/lang/InternalError` similar to the preprocessing of `System::exit` calls.

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

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2386449193

From liach at openjdk.org  Tue Oct  1 16:23:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Oct 2024 16:23:42 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <LNf1m1HJWfuZRvdxMQmXGFZtqS5e2RpFhkggoMfyPUc=.bcdb38ad-3e51-409d-a5e2-95259bc1eed8@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
 <LNf1m1HJWfuZRvdxMQmXGFZtqS5e2RpFhkggoMfyPUc=.bcdb38ad-3e51-409d-a5e2-95259bc1eed8@github.com>
Message-ID: <GrXOtf6dKGOrlVbLUkaxKL-zotXzz_1BbnZXDcgr-Fs=.f1e564b1-41fa-4c35-bba6-e2941c8a3865@github.com>

On Tue, 1 Oct 2024 16:12:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bj?rsn?s 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 ziperror-deprecation
>>  - Simplify the deprecation note by focusing on behavior in the current release
>>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>>  - Update copyright year
>>  - Deprecate java.util.zip.ZipError for removal
>
> src/java.base/share/classes/java/util/zip/ZipError.java line 31:
> 
>> 29:  * Signals that an unrecoverable error has occurred.
>> 30:  *
>> 31:  * @deprecated ZipError is no longer used and is obsolete.
> 
> I agree ZipError should be deprecated. Can the JBS issue and PR title be updated as they still have "for removal".

Isn't this deprecation intended for removal? Or do you mean this `@deprecated` tag should note that this class will be removed in a future release?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1783157380

From mcimadamore at openjdk.org  Tue Oct  1 16:25:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 16:25:37 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <RISMgNKDps8ZGdE8raS-gfBxbd7fU7PKSFnHucyBrpY=.ed4d006c-dd6c-4a13-aca9-16f35832684c@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
 <oMO3VuFNTJg70ijTJVbefBPVSqaSvVKkTwhWxjB6KDk=.4345cca5-716a-469b-abb7-fec07d16adf8@github.com>
 <Q2meopQvf8afdzX18yA6TauJRvIrcFpO7OnD5_1dTlY=.f144da28-8a1b-4bd1-8399-ea6ca95ac5c6@github.com>
 <RISMgNKDps8ZGdE8raS-gfBxbd7fU7PKSFnHucyBrpY=.ed4d006c-dd6c-4a13-aca9-16f35832684c@github.com>
Message-ID: <MBFPSh3DK7xgau09be-TlUmAOTtXLNXLxIlnw_bJJFY=.cde5ce09-db74-490e-af8d-82fc17cc8f10@github.com>

On Tue, 1 Oct 2024 16:07:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I see what you mean... I'll do some experiments and see how the current annotation affects the benchmark - if at all.
>
> The issue with using a compile command is that it will then work globally. So the benchmark would not really test much - besides checking that var handle access is slow when `asType` cannot inline. What I was trying to do here was to avoid `asType` being inlined into that `compileAsType` method - but I agree that the annotation I added isn't it.

I believe `EXCLUDE` is what I was reaching out for

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1783160583

From mchung at openjdk.org  Tue Oct  1 16:26:42 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 1 Oct 2024 16:26:42 GMT
Subject: RFR: 8340831: Simplify simple validation for class definition in
 MethodHandles.Lookup [v2]
In-Reply-To: <zI5uArM0kOuxbzbK3sQNm2SS7tXx793KgN7B3xR9Yts=.71631cc2-ee4a-4f21-8149-c87e56596850@github.com>
References: <wSXKMgpyzB8BvhvhjqZbVBVnIpaFhwKyRArdEUgIcVM=.933dee7d-8a93-439d-8253-f425e2e6ac66@github.com>
 <zI5uArM0kOuxbzbK3sQNm2SS7tXx793KgN7B3xR9Yts=.71631cc2-ee4a-4f21-8149-c87e56596850@github.com>
Message-ID: <4lzYyrpiF1OFKbDktBG-G288FJV2KSK08k45VD_gNoE=.14d86206-50f3-4671-bd87-3afd4eb5bb9d@github.com>

On Wed, 25 Sep 2024 14:50:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is unnecessary and can be scalarized manually. The removal of `ClassFile` class is also slightly helpful for bootstrap by reducing class loading. Also improved class file version checking in `VM` class.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to internalName where possible

This change looks okay (belated review).

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

PR Comment: https://git.openjdk.org/jdk/pull/21170#issuecomment-2386454746

From rgiulietti at openjdk.org  Tue Oct  1 16:27:39 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 1 Oct 2024 16:27:39 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]
In-Reply-To: <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
Message-ID: <p-T69zcOko4su-Yfha77M8_-YPyap8dBM2QX0PSat0k=.028e4731-e8dc-40d5-824b-3ed4a3914e1c@github.com>

On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

Looks good.
Thanks.

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20008#pullrequestreview-2340865137

From bpb at openjdk.org  Tue Oct  1 16:28:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Oct 2024 16:28:37 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v3]
In-Reply-To: <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>
Message-ID: <A-TZ1WKfxiGQesPueqHFaPnEn7Pto7GTnPZb_vdktms=.40b8a3b4-011e-4510-ad57-3f010cde0397@github.com>

On Mon, 30 Sep 2024 16:11:14 GMT, sbgoog <duke at openjdk.org> wrote:

>> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.
>
> sbgoog has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright year

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20938#pullrequestreview-2340866970

From eirbjo at openjdk.org  Tue Oct  1 16:32:38 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 1 Oct 2024 16:32:38 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <GrXOtf6dKGOrlVbLUkaxKL-zotXzz_1BbnZXDcgr-Fs=.f1e564b1-41fa-4c35-bba6-e2941c8a3865@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
 <LNf1m1HJWfuZRvdxMQmXGFZtqS5e2RpFhkggoMfyPUc=.bcdb38ad-3e51-409d-a5e2-95259bc1eed8@github.com>
 <GrXOtf6dKGOrlVbLUkaxKL-zotXzz_1BbnZXDcgr-Fs=.f1e564b1-41fa-4c35-bba6-e2941c8a3865@github.com>
Message-ID: <IkEsr3ucHMmiy1tIflo-cTO5oRjzm0zZm8J9raP2cr8=.d8a4740e-c14a-4d69-a820-4c8cd9db8a89@github.com>

On Tue, 1 Oct 2024 16:20:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipError.java line 31:
>> 
>>> 29:  * Signals that an unrecoverable error has occurred.
>>> 30:  *
>>> 31:  * @deprecated ZipError is no longer used and is obsolete.
>> 
>> I agree ZipError should be deprecated. Can the JBS issue and PR title be updated as they still have "for removal".
>
> Isn't this deprecation intended for removal? Or do you mean this `@deprecated` tag should note that this class will be removed in a future release?

Alan,

This is probably better discussed in the CSR. Please see the latest comments there.

I think we're still waiting for concensus/conclusion in the CSR on whether the deprecation of the class itself should be for removal or not.

Joe suggested that the class be marked deprecated, not for removal, and that the constructor be marked deprecated, for removal. He asked for input on this suggestion, which unfortunately took me a while. 

The latest comment from me and @liach made a case for deprecating the class for removal. We are waiting for input from Joe on this.

Once the CSR concludes on a solution, I'll of course update the CSR and PR accordingly.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1783169355

From duke at openjdk.org  Tue Oct  1 17:06:40 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 1 Oct 2024 17:06:40 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]
In-Reply-To: <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
Message-ID: <2uik49cv5C3aRDYbuEYQmhe2aGGh6sElyAnIA3bKOVg=.fad6d5de-f8c4-49c0-ae83-36804411db94@github.com>

On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

`/integrate`

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2386530634

From swen at openjdk.org  Tue Oct  1 17:15:11 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Oct 2024 17:15:11 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v15]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <r2VUGyQXgLxKqePZjMHZSsxas2vNa4Y6Df20VOKguqs=.e12414e6-e9b3-4e68-b6eb-3e18833fbd78@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - label write clean
 - optimizer for codeSize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/77174a2b..36c81ec1

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

  Stats: 138 lines in 3 files changed: 66 ins; 25 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

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

From ccheung at openjdk.org  Tue Oct  1 17:17:53 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Oct 2024 17:17:53 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v8]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <7Hxl8pLddrlwTdc5Zhyjx46upjT6m17HQuI6SogSwNU=.6d2f0c7a-97f9-4480-a455-35ed4e00439b@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/a3eef6cd..4b6ca617

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

  Stats: 109 lines in 5 files changed: 83 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21048/head:pull/21048

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

From henryjen at openjdk.org  Tue Oct  1 17:23:36 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 1 Oct 2024 17:23:36 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <6Rd1WefoiRuHZeJOA6PJj7NfUc-xw5J2pzFAOE-YmnQ=.7cafe564-5dbb-440c-9707-1b4887586567@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <MHjKScehUA-_iKO4I6mNAIj0J-L4ztDvSUvucn1tFAQ=.30a4f66d-03fc-452c-8641-14091d42e085@github.com>
 <JC0mGm5IYQRGNuvR57ASD7POlwGz9PILbS7mVj_X3fM=.6b421dfb-0187-453e-b32b-694fbc728f6e@github.com>
 <6Rd1WefoiRuHZeJOA6PJj7NfUc-xw5J2pzFAOE-YmnQ=.7cafe564-5dbb-440c-9707-1b4887586567@github.com>
Message-ID: <gYIDXh7P-jHAuCQbpSjo9v2m7avPxNsCWJty9nfnb9I=.d3cadb75-943b-463e-8e1e-09ccb2f2d1e2@github.com>

On Mon, 30 Sep 2024 15:51:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I considered that, but didn't implement it after confirmed other similar options didn't display any warning.
>> I do think it make sense to show a warning when using an option not valid in specific mode.
>
>> I considered that, but didn't implement it after confirmed other similar options didn't display any warning. I do think it make sense to show a warning when using an option not valid in specific mode.
> 
> We do display a warning/error is some cases:  For example when we specify 'c' and 'x' we get the following message
> 
> 
> jar cxvf foo.jar
> You may not specify more than one '-cuxtid' options
> Try `jar --help' for more information.
> 
> 
> given '-k' is only relevant when used with the  '-x' option, we could specify a warning (or indicate it is ignored...

OK, I will add a message. The other option I am talking about is specific mode options, like compression or manifest instead of main options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1783229550

From ccheung at openjdk.org  Tue Oct  1 17:24:39 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Oct 2024 17:24:39 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <2TjFLEwheCeUXfKrmZW_wJ_oCB7BNoknhhecGaMC2g0=.6469d724-cd72-42df-a89d-5ffb7ab995b9@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
 <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
 <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
 <2TjFLEwheCeUXfKrmZW_wJ_oCB7BNoknhhecGaMC2g0=.6469d724-cd72-42df-a89d-5ffb7ab995b9@github.com>
Message-ID: <nm7PWI7__xHyFAuwixRh3ZtlcxHXz6P1EyJlZcE222k=.907bbf57-3bf7-40dd-85fe-a2abdfd90764@github.com>

On Sun, 29 Sep 2024 04:11:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> It should work because the jmod file won't be added to the `module_paths`.
>
> In my scenario, will the FMG be used? If so, the program won't be able to load the code in mod2.jmod, so the behavior will be wrong. Could you add a test case for this?

It turns out that jmod cannot be used during runtime.
>From `jdk.intenal.module.ModulePath`:

            // not recognized
            String msg;
            if (!isLinkPhase && entry.toString().endsWith(".jmod")) {
                msg = "JMOD format not supported at execution time";
            } else {
                msg = "Module format not recognized";
            }

I added some tests with jmod.

>> I'm not sure. Is your suggest equivalent to:
>>   `return (strcmp(key, "jdk.module.path"));`
>
> Yes, the C++ compiler will automatically concatenate `MODULE_PROPERTY_PREFIX PATH` into a single string.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783230047
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783230247

From ccheung at openjdk.org  Tue Oct  1 17:24:40 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Oct 2024 17:24:40 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v4]
In-Reply-To: <JgKjpc7KozfFkpYHl8YpG3vp6GvVZKTP8ibD-9lkFrI=.864de45a-e859-42f2-9073-13d0043ade3d@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <tqAv6jz7es5t3f3b5UoK4fZQQMHAd3ZWFGcScQo3OLI=.6ffe04f6-8df0-423a-8883-903f5ea1fe18@github.com>
 <Q_b78g3mh9_vXEGDmnmn94EQKFQUSSmP-6z-ElP6SGU=.7edbf83f-7eed-47c9-aa4b-093c691526f7@github.com>
 <q1vbBBxCGWw-y_vKFPiXUvowZsLQX0h3RqMgVQZIV88=.b42f7246-61ad-4c8d-87f7-d2243bd0f446@github.com>
 <8zmMK9osKaE2aA051AjovRF3ilTWLZhsSQKTgans7QQ=.87813411-03bb-4b52-af61-8e7595c794e2@github.com>
 <JgKjpc7KozfFkpYHl8YpG3vp6GvVZKTP8ibD-9lkFrI=.864de45a-e859-42f2-9073-13d0043ade3d@github.com>
Message-ID: <PLbswO66Hg0pjOyaC4Bi7_qiNlNCWhuq7-iKvNaWrkI=.f9bde854-3d73-45e3-aa7a-d136e15e5cb2@github.com>

On Sun, 29 Sep 2024 06:43:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Why does it need to clear `moduleToReader` only for app loader and not for platform loader? Is it because the `moduleToReader` for the app loader may contain reference to jar files that indirectly references some file system objects?
>> 
>> Since moduleToReader is just a cache, I think it's better to always clear it for both loaders. Also, the logic can be moved into BuiltinClassLoader: 
>> 
>> 
>> class BuiltinClassLoader {
>>         ....
>>         private void resetArchivedStates() {
>>             ucp = null;
>>             resourceCache = null;
>>             setClassPath(null);  // AppClassLoader will initialize this again at runtime.
>>             moduleToReader.clear();
>>         }
>
> setClassPath(null) is the same as `ucp = null` but yes, keep it simple as otherwise there will be question each time there are changes. BuiltinClassPath should not include any code that is specific to the app class loader or the platform class loader as there are specific subclasses for that.

Ok. I've simplified the fix as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783230382

From henryjen at openjdk.org  Tue Oct  1 17:26:34 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 1 Oct 2024 17:26:34 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v4]
In-Reply-To: <0Ld1ZT7y9YOa5JdmwZeg4eFGrpvho6eL0r_j1WODFrI=.dffe658f-cc4e-4b2a-a09b-3d881bbda7c3@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <QIMmjrmSD1_a-_FRW59OtzRb2G-OKh2PHXO31FY74Ng=.f899bc94-47d4-4203-9422-f81523f58e8e@github.com>
 <0Ld1ZT7y9YOa5JdmwZeg4eFGrpvho6eL0r_j1WODFrI=.dffe658f-cc4e-4b2a-a09b-3d881bbda7c3@github.com>
Message-ID: <Wpckkpi9RMqW5XxAamp_8lyAlm84uGp5wuQWrnpjxbs=.dcdbbb38-b081-4200-a03a-632d0fab2ced@github.com>

On Tue, 1 Oct 2024 07:15:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Is `compiler` label needed? The `jar` tool belongs in `core-libs`, right? This PR does not seem to touch anything in the compiler area?

Automatically added by the bot. I agree it's not related to compiler at all. I'll manually remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21141#issuecomment-2386565199

From ccheung at openjdk.org  Tue Oct  1 17:30:10 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Oct 2024 17:30:10 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v9]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/4b6ca617..b9a9b75a

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

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

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

From jlu at openjdk.org  Tue Oct  1 17:34:46 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 1 Oct 2024 17:34:46 GMT
Subject: RFR: 8341285: Clarify LocaleServiceProvider deployment on application
 module path
Message-ID: <8_f0tTi0mlYkIlVcvmQdnvp2W8S_tgcV-ZC5sodPC1U=.b8dff2ab-b8a6-457f-901d-0bea567a65fb@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8341285) which clarifies that a Locale sensitive service provider can be deployed as a module.

This mainly follows the same format as the work done for [JDK-8340404](https://bugs.openjdk.org/browse/JDK-8340404), by providing a brief example, and pointing to the Deploying Service Providers section under ServiceLoader.

There is no test added, since there already exists java.text tests that deploy SPIs as a module.

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

Commit messages:
 - init

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

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

From mcimadamore at openjdk.org  Tue Oct  1 17:49:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 17:49:12 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v4]
In-Reply-To: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
Message-ID: <8vSM8Uy5IXsnlurOK1fEC6kIahVGeERepIyG8RWsef0=.8cd004e6-890a-45c5-b021-be46bfd8c1dc@github.com>

> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
> 
> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
> 
> This problem was originally reported here:
> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
> 
> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
> 
> 
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
> 
> 
> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.

Maurizio Cimadamore 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/21283/files
  - new: https://git.openjdk.org/jdk/pull/21283/files/4fee4d28..964a273f

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

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

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

From jvernee at openjdk.org  Tue Oct  1 17:49:13 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 1 Oct 2024 17:49:13 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <MBFPSh3DK7xgau09be-TlUmAOTtXLNXLxIlnw_bJJFY=.cde5ce09-db74-490e-af8d-82fc17cc8f10@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
 <oMO3VuFNTJg70ijTJVbefBPVSqaSvVKkTwhWxjB6KDk=.4345cca5-716a-469b-abb7-fec07d16adf8@github.com>
 <Q2meopQvf8afdzX18yA6TauJRvIrcFpO7OnD5_1dTlY=.f144da28-8a1b-4bd1-8399-ea6ca95ac5c6@github.com>
 <RISMgNKDps8ZGdE8raS-gfBxbd7fU7PKSFnHucyBrpY=.ed4d006c-dd6c-4a13-aca9-16f35832684c@github.com>
 <MBFPSh3DK7xgau09be-TlUmAOTtXLNXLxIlnw_bJJFY=.cde5ce09-db74-490e-af8d-82fc17cc8f10@github.com>
Message-ID: <gplfAJzOCg2kEURVPIqn6xReXt-KmaqMRzQkKkNBlyo=.28f21b06-d651-47a7-acb8-c77db207a9bb@github.com>

On Tue, 1 Oct 2024 16:22:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The issue with using a compile command is that it will then work globally. So the benchmark would not really test much - besides checking that var handle access is slow when `asType` cannot inline. What I was trying to do here was to avoid `asType` being inlined into that `compileAsType` method - but I agree that the annotation I added isn't it.
>
> I believe `EXCLUDE` is what I was reaching out for

I think EXCLUDE would work, yes. True about CompileCommand having a global effect, so that won't work. (With a CompilerDirective file we could be more precise, not sure if it's worth it though).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1783255680

From mcimadamore at openjdk.org  Tue Oct  1 17:52:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Oct 2024 17:52:34 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v2]
In-Reply-To: <gplfAJzOCg2kEURVPIqn6xReXt-KmaqMRzQkKkNBlyo=.28f21b06-d651-47a7-acb8-c77db207a9bb@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <i08C5PqxM5FBKs08LD6kc2eCjqrD97kmwOB6TUTI2v0=.c3b82a32-10e5-42cc-8841-9cbc65cb2213@github.com>
 <oMO3VuFNTJg70ijTJVbefBPVSqaSvVKkTwhWxjB6KDk=.4345cca5-716a-469b-abb7-fec07d16adf8@github.com>
 <Q2meopQvf8afdzX18yA6TauJRvIrcFpO7OnD5_1dTlY=.f144da28-8a1b-4bd1-8399-ea6ca95ac5c6@github.com>
 <RISMgNKDps8ZGdE8raS-gfBxbd7fU7PKSFnHucyBrpY=.ed4d006c-dd6c-4a13-aca9-16f35832684c@github.com>
 <MBFPSh3DK7xgau09be-TlUmAOTtXLNXLxIlnw_bJJFY=.cde5ce09-db74-490e-af8d-82fc17cc8f10@github.com>
 <gplfAJzOCg2kEURVPIqn6xReXt-KmaqMRzQkKkNBlyo=.28f21b06-d651-47a7-acb8-c77db207a9bb@github.com>
Message-ID: <WA27DEDly1RtMEyhbp-77efBTfB9T65t3J8YbdSVGC0=.2bc230bc-a6d5-4c6f-baa0-0f9255c09ecf@github.com>

On Tue, 1 Oct 2024 17:44:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I believe `EXCLUDE` is what I was reaching out for
>
> I think EXCLUDE would work, yes. True about CompileCommand having a global effect, so that won't work. (With a CompilerDirective file we could be more precise, not sure if it's worth it though).

In the latest iteration, I removed the annotation. Doesn't seem to be making any difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21283#discussion_r1783261399

From jvernee at openjdk.org  Tue Oct  1 18:04:37 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 1 Oct 2024 18:04:37 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v4]
In-Reply-To: <8vSM8Uy5IXsnlurOK1fEC6kIahVGeERepIyG8RWsef0=.8cd004e6-890a-45c5-b021-be46bfd8c1dc@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <8vSM8Uy5IXsnlurOK1fEC6kIahVGeERepIyG8RWsef0=.8cd004e6-890a-45c5-b021-be46bfd8c1dc@github.com>
Message-ID: <MlsFpWXjzD6AEozZ3m5hsPM7SuQ7FBSOT1uok5A1X7Q=.46c1c71e-acd5-4d73-888f-e79ba949c44b@github.com>

On Tue, 1 Oct 2024 17:49:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some round of adaptation.
>> Adapting a var handle results in a so called *indirect* var handle.
>> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
>> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
>> 
>> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
>> 
>> This problem was originally reported here:
>> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
>> 
>> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
>> 
>> 
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
>> 
>> 
>> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21283#pullrequestreview-2341047812

From sviswanathan at openjdk.org  Tue Oct  1 18:05:44 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Oct 2024 18:05:44 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
 <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
Message-ID: <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>

On Tue, 1 Oct 2024 09:53:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Thanks for the example. Yes, you have a point there.  So we would need to do:
>>    src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2);
>
>> This could instead be: src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2); Or even simplified to: src1.rearrange(this.toShuffle(), src2);
> 
> Yes, this may save additional allocation penalty of result array allocation which may slightly improve fall back performance, but logical operation cannot be directly applied over floating point vectors. so, we will need an explicit conversion to integral vector, which is why I opted for current fallback implementation which is in line with rest of the code.

I see the problem with float/double vectors. Let us do the rearrange form only for Integral (byte, short, int, long) vectors then. For float/double vector we could keep the code that you have currently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1783278063

From dfuchs at openjdk.org  Tue Oct  1 18:05:42 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 1 Oct 2024 18:05:42 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v7]
In-Reply-To: <Xd9CmvY6XmRJCcRuj-sb_TaVOIIpljceDPpMPVAjZy0=.142b8e70-5132-4d64-8823-1c48e3539dac@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <Xd9CmvY6XmRJCcRuj-sb_TaVOIIpljceDPpMPVAjZy0=.142b8e70-5132-4d64-8823-1c48e3539dac@github.com>
Message-ID: <_g5ZiUhiIh1RiXr2ELooKU0OIbIiIq0BVos9IFssV_g=.0b056eff-9c96-4776-8710-0e5ff4097fd0@github.com>

On Fri, 27 Sep 2024 18:08:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert bugID update to tests

Since Naoto previously approved before the simple `@bug` updates I am going to approve now. @prrace no objection?

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21096#pullrequestreview-2341048410

From sviswanathan at openjdk.org  Tue Oct  1 18:12:39 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Oct 2024 18:12:39 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v14]
In-Reply-To: <gr0t8AMHsNLOiUnl1NiEaICixmENi5Geo1igGaQ2zPs=.fa783172-eaee-48c1-8c7d-4cc337184369@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <gr0t8AMHsNLOiUnl1NiEaICixmENi5Geo1igGaQ2zPs=.fa783172-eaee-48c1-8c7d-4cc337184369@github.com>
Message-ID: <5wF2qLX9Z_tquvURMW0HVnrmMla1awxtz6C0UYI0lh4=.94df7340-1a27-4d93-80fa-d4c561641a97@github.com>

On Tue, 1 Oct 2024 09:51:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2797:

> 2795: 
> 2796:   Node* operation = lowerSelectFromOp ?
> 2797:                       LowerSelectFromTwoVectorOperation(gvn(), opd1, opd2, opd3, vt) :

Thanks for bringing the lowering right here. It opens up an optimization opportunity: currently for float/double we have two casts for index (e.g. from float -> int at line 2786 and from int -> byte at line 2661 as part of LowerSelectFromTwoVectorOperation. Could this be done by one cast?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1783296741

From jlu at openjdk.org  Tue Oct  1 18:19:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 1 Oct 2024 18:19:37 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b
In-Reply-To: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
Message-ID: <FiTyMuhCLrFwNYA48M_t15wfLm1x3NWVar6Doeopd7Q=.09e84944-bb27-475d-94eb-84bf6bb5a9fc@github.com>

On Mon, 30 Sep 2024 14:03:15 GMT, Johny Jose <duke at openjdk.org> wrote:

> Timezone data 2024b changes

src/java.base/share/classes/java/time/ZoneId.java line 191:

> 189:      * This map contains a mapping of the IDs that is in line with TZDB 2024b and
> 190:      * later, where 'EST', 'MST' and 'HST' map to IDs which do not include daylight
> 191:      * savings since 1970.

Hi Johny, the future flexibility clause seems to be missing in the spec update of ZoneId.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21265#discussion_r1783303975

From jlu at openjdk.org  Tue Oct  1 18:52:38 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 1 Oct 2024 18:52:38 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b
In-Reply-To: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
Message-ID: <bTYv37ev9W1rMPjxrmzDuIJxz8f53id5GzfpTDeEFC0=.af504bb0-6f48-4e6d-8fc9-c341e6e7a06f@github.com>

On Mon, 30 Sep 2024 14:03:15 GMT, Johny Jose <duke at openjdk.org> wrote:

> Timezone data 2024b changes

src/java.base/share/classes/java/time/ZoneId.java line 189:

> 187:      * {@link #of(String, Map)} factory method.
> 188:      * <p>
> 189:      * This map contains a mapping of the IDs that is in line with TZDB 2005r and

I believe this file needs a copyright year bump.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 288:

> 286:             aliases.put("MST", "America/Phoenix");
> 287:         }
> 288:         aliases.put("HST", "Pacific/Honolulu");

Looks correct to me, since "HST" to "Pacific/Honolulu" link is same for `USE_OLDMAPPING` as well as 2024b update.

test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 290:

> 288: 
> 289:         if (l1.equals(l2)) {
> 290:             System.out.println("no diff");

Is this needed? IIUC `diff` is only called if the array contents are not equal.

test/jdk/sun/util/resources/TimeZone/Bug4848242.java line 35:

> 33: import java.text.DateFormatSymbols;
> 34: 
> 35: public class Bug4848242 {

This test needs a copyright year bump. (Applies to any other tests as well).

We also might want to update the summary, since it should no longer display MET and MEST, but rather CET and CEST.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21265#discussion_r1783319052
PR Review Comment: https://git.openjdk.org/jdk/pull/21265#discussion_r1783317888
PR Review Comment: https://git.openjdk.org/jdk/pull/21265#discussion_r1783330388
PR Review Comment: https://git.openjdk.org/jdk/pull/21265#discussion_r1783320110

From swen at openjdk.org  Tue Oct  1 18:55:09 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Oct 2024 18:55:09 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v16]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <16yjWbAjNLDXNnJemTNLq3W0qutR3VzYLawn4EKe6kw=.33f3e5da-23de-42b1-b84c-8e34b20619d6@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimization for powerOctal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/36c81ec1..e7b32d43

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

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

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

From duke at openjdk.org  Tue Oct  1 20:45:38 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 1 Oct 2024 20:45:38 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]
In-Reply-To: <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
Message-ID: <rR809jlAUr76JxVjmp0geb9K6vuqsLTTBh5HLPmD2VM=.063ae524-8db1-421f-82f2-647fdb19aae4@github.com>

On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

`/integrate`

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2387038260

From swen at openjdk.org  Tue Oct  1 21:09:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Oct 2024 21:09:10 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v17]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <aTJ3EtPENhw2mo4K0bvwkRj8OoALf8kkweUnqLUDco0=.cd4b21e6-b03a-40af-8dd7-4ce59fc8c90a@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - optimize DirectClassBuilder::build
 - writeU2U2U2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/e7b32d43..7029dfe7

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

  Stats: 59 lines in 5 files changed: 37 ins; 8 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

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

From henryjen at openjdk.org  Tue Oct  1 21:53:37 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 1 Oct 2024 21:53:37 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <DyVLK1xTDwn9QJ3yWozmK0pGrSgQCr15FSM3zZdKDC4=.77bec2de-aa4d-48ad-bfb2-202d63876d2d@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
 <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
 <DyVLK1xTDwn9QJ3yWozmK0pGrSgQCr15FSM3zZdKDC4=.77bec2de-aa4d-48ad-bfb2-202d63876d2d@github.com>
Message-ID: <nKUnsOX9SrvXR87U606fQEVtZeBDIDcXDQByscRY5rw=.e3a3d1a2-1a54-427e-a1d5-105473d9f60b@github.com>

On Mon, 30 Sep 2024 11:38:20 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I follow existing pattern with short status update. Open to suggestions.
>
> Perhaps something like:
> 
> ` \ \  file: {0}  exists, skipped`

Use this for now to be more close to current style,
`        \ \ skipped: {0} exists`
Was thinking perhaps a different line for detail message, but this should do, as we only skip with file exists.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1783569666

From jlu at openjdk.org  Tue Oct  1 22:07:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 1 Oct 2024 22:07:48 GMT
Subject: RFR: 8341366: Suspicious check in Locale.getDisplayName(Locale
 inLocale)
Message-ID: <mV3B1kRYE7kcvVEsIHe_4DcvT99kxlx0m7ELKGxZAfc=.166246cd-5fc2-4c0a-83e5-9e30a399ec1b@github.com>

Please review this PR which modifies a suspicious check in the fallback of `Locale.getDisplayName(Locale inLocale)`.

As a fallback, a hard coded pattern is used. The previous code outputted the qualifiers if the `displayNames` array had length greater than 2. Just a few lines above, the array is initialized with a length of 3 and so the check is pointless.

It would be better, if replaced with a null check for the last element of the `displayNames` array, as that element may be null if there are no qualifiers. See L2317 ,

`qualifierNames.length != 0 ? formatList(qualifierNames, listCompositionPattern) : null`

For example, now a fallback (with no qualifiers) might look like: `German` instead of `German (null)`.
But will remain the same (with qualifiers): `German (Germany)`.

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

Commit messages:
 - init

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

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

From sviswanathan at openjdk.org  Tue Oct  1 22:51:43 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 1 Oct 2024 22:51:43 GMT
Subject: Integrated: 8340079: Modify rearrange/selectFrom Vector API methods to
 perform wrapIndexes instead of checkIndexes
In-Reply-To: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
References: <09YQJC5E6ehZag2rrgrdadFNfn59U341FD1QNs_-7L8=.b6f60b2b-150b-442d-b568-3929c2405250@github.com>
Message-ID: <WcsGRuRKJidE0YutSqONyhmZ210_m6ee45RbzswJIeM=.9f23cb68-57fd-40db-8222-62999a8e7928@github.com>

On Mon, 19 Aug 2024 21:47:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
> 
> Summary of changes is as follows:
>  1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
>  2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
> 
> For the following source:
> 
> 
>     public void test() {
>         var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
>         for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
>             var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
>             index.selectFrom(inpvect).intoArray(byteres, j);
>         }
>     }
> 
> 
> The code generated for inner main now looks as follows:
> ;; B24: #      out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
>   0x00007f40d02274d0:   movslq %ebx,%r13
>   0x00007f40d02274d3:   vmovdqu 0x10(%rsi,%r13,1),%xmm1
>   0x00007f40d02274da:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274df:   vmovdqu %xmm1,0x10(%rax,%r13,1)
>   0x00007f40d02274e6:   vmovdqu 0x20(%rsi,%r13,1),%xmm1
>   0x00007f40d02274ed:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d02274f2:   vmovdqu %xmm1,0x20(%rax,%r13,1)
>   0x00007f40d02274f9:   vmovdqu 0x30(%rsi,%r13,1),%xmm1
>   0x00007f40d0227500:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227505:   vmovdqu %xmm1,0x30(%rax,%r13,1)
>   0x00007f40d022750c:   vmovdqu 0x40(%rsi,%r13,1),%xmm1
>   0x00007f40d0227513:   vpshufb %xmm2,%xmm1,%xmm1
>   0x00007f40d0227518:   vmovdqu %xmm1,0x40(%rax,%r13,1)
>   0x00007f40d022751f:   add    $0x40,%ebx
>   0x00007f40d0227522:   cmp    %r8d,%ebx
>   0x00007f40d0227525:   jl     0x00007f40d02274d0
> 
> Best Regards,
> Sandhya

This pull request has now been integrated.

Changeset: 83dcb02d
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83dcb02d776448aa04f3f41df489bd4355443a4d
Stats:     697 lines in 47 files changed: 549 ins; 34 del; 114 mod

8340079: Modify rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes

Reviewed-by: jbhateja, psandoz

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

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

From vlivanov at openjdk.org  Tue Oct  1 22:53:36 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 1 Oct 2024 22:53:36 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v4]
In-Reply-To: <8vSM8Uy5IXsnlurOK1fEC6kIahVGeERepIyG8RWsef0=.8cd004e6-890a-45c5-b021-be46bfd8c1dc@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <8vSM8Uy5IXsnlurOK1fEC6kIahVGeERepIyG8RWsef0=.8cd004e6-890a-45c5-b021-be46bfd8c1dc@github.com>
Message-ID: <SRLEZW4ALgLREa2qssaBQhTGoRKL6PKnrjki8tF93h4=.b9f41d57-bf55-455f-aeb3-6a508764eef9@github.com>

On Tue, 1 Oct 2024 17:49:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some round of adaptation.
>> Adapting a var handle results in a so called *indirect* var handle.
>> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
>> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
>> 
>> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
>> 
>> This problem was originally reported here:
>> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
>> 
>> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
>> 
>> 
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
>> 
>> 
>> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I don't have a clear understanding how `VarHandleGuards` is used, but I assume that `MethodHandle::asType` calls there are no-ops in scenarios you care about.

It does make sense to annotate`setAsTypeCache` with `@DontInline`, but I'd also add `@ForceInline` on `asType`.

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

PR Comment: https://git.openjdk.org/jdk/pull/21283#issuecomment-2387220756

From dholmes at openjdk.org  Tue Oct  1 23:54:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Oct 2024 23:54:34 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Lju2Q06vASMUTddIzoJX4NuaXBzbj_6_Q5KWJ72IYec=.3ef1b9b0-1da1-4622-8528-744d0a23b6e6@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <O7XW4a3YxSJeLCtbLUJ73xeINN5P0m2MQMEPtbkhuNU=.05a00a08-6a49-42be-917c-4df8702f3f9b@github.com>
 <Lju2Q06vASMUTddIzoJX4NuaXBzbj_6_Q5KWJ72IYec=.3ef1b9b0-1da1-4622-8528-744d0a23b6e6@github.com>
Message-ID: <6sl2TJ4rddNWtR39okuGZ-bEZELVUjel3WMJU7Rxf9E=.82102f65-c4c0-40e6-bf3b-4ba7dcad5b41@github.com>

On Tue, 1 Oct 2024 08:20:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> `jni_md.h` is shipped as part of every JDK distribution - this change does NOT belong in that file.
>
>> `jni_md.h` is shipped as part of every JDK distribution - this change does NOT belong in that file.
> 
> Hi David, should I introduce a separate ub.hpp  (similar to what we have in Hotspot) ?

@MBaesken my understanding is that src/java.base/share/native/include is for exported header files, it is not a general location to put this new header.

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

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2387279143

From henryjen at openjdk.org  Wed Oct  2 00:25:00 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 2 Oct 2024 00:25:00 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v5]
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <iEKvdtRISrEjyZa876Ak4QuxRUKJFIV7xWMrQLKzwvo=.9068deb1-6062-44e7-969f-c82ec8f4d528@github.com>

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  More review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21141/files
  - new: https://git.openjdk.org/jdk/pull/21141/files/6192de61..1b7a1f99

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

  Stats: 68 lines in 4 files changed: 28 ins; 12 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21141/head:pull/21141

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

From iklam at openjdk.org  Wed Oct  2 01:06:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Oct 2024 01:06:20 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v7]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @liach and @cl4es comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @dholmes-ora review comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Do not use system property to limit usage to only CDS static dumps
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - ... and 3 more: https://git.openjdk.org/jdk/compare/e7d85ed2...1b067b7b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/b8187149..1b067b7b

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

  Stats: 232 lines in 7 files changed: 141 ins; 17 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

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

From jpai at openjdk.org  Wed Oct  2 01:29:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Oct 2024 01:29:40 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base [v2]
In-Reply-To: <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
 <REyyoSAdFIphPN64N-KN5O5qo5I5Xp9bpPRMNeohCAU=.b2510983-1fcd-430a-86ee-55a97d1b6ce1@github.com>
Message-ID: <un4GBh68csaCCY2QIHBD5R8jkMOhLDEpiZyBCdvNy5A=.bd295084-a190-4c14-b7e9-7d63d1e021e1@github.com>

On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
>> 
>> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
>> 
>> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
>> 
>> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
>> 
>> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
>> 
>> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
>> 
>> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
>> 
>> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comment and variable from HugeCapacity tests

tier1, tier2 and tier3 testing in our CI completed without any issues. I'll now go ahead with integrating this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21268#issuecomment-2387457683

From eirbjo at openjdk.org  Wed Oct  2 01:29:41 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 2 Oct 2024 01:29:41 GMT
Subject: Integrated: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max
 array size in java.base
In-Reply-To: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
References: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>
Message-ID: <Yv0AQvnND_IRghP2dgMt-7H_U5nLeWq23KNh5y40U4s=.20f3be08-1637-460c-a883-f91c4cc2651d@github.com>

On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.
> 
> This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.
> 
> My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 
> 
> Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).
> 
> I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.
> 
> Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.
> 
> Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.
> 
> Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

This pull request has now been integrated.

Changeset: 0f381137
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f381137cb9338453a7d77a7ebdfaa9b34b5028b
Stats:     60 lines in 15 files changed: 19 ins; 9 del; 32 mod

8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array size in java.base

Reviewed-by: jpai, smarks

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

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

From dholmes at openjdk.org  Wed Oct  2 01:53:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 01:53:37 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v6]
In-Reply-To: <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
Message-ID: <GwZmYWMst4ldNT7IwnSNKHRJhnK7nfiMgqNnGPOr-D4=.3965a0ce-2910-45c6-ab42-0af6f3845f0d@github.com>

On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix paths to links

<sigh> These comments never got "pushed"

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

PR Review: https://git.openjdk.org/jdk/pull/21067#pullrequestreview-2324156020

From dholmes at openjdk.org  Wed Oct  2 01:53:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 01:53:39 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v5]
In-Reply-To: <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
Message-ID: <mndQ4ndkU2PEb19Tr5ruTIAFuGsQlDNWvYZHzwEO03I=.1127bcad-3e33-49f9-9d7c-03f5ffab9108@github.com>

On Mon, 23 Sep 2024 21:06:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix javadoc test failure

src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line 40:

> 38:     be disabled by granting access to restricted methods to selected modules. This can be
> 39:     done either via implementation-specific command line options or programmatically, e.g.
> 40:     by calling <a href="../../ModuleLayer.Controller.html#enableNativeAccess(java.lang.Module)"><code>ModuleLayer.Controller.enableNativeAccess(java.lang.Module)</code></a>.</p>

Given the very generic preceding description of "restricted methods" with no actual example, the fact this method is called `enableNativeAccess` really stands out as odd. One would expect it to be `enableRestrictedAccess`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1772686695

From dholmes at openjdk.org  Wed Oct  2 01:53:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 01:53:39 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <yNZ1tynuIB6KbFUxltn99a_KxNpRa0LdiHCZgtB9T1I=.41b5b994-5e45-4404-9d75-4f3cae119898@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
 <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
 <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>
 <MA1g4ugxGpNjN_5vYMPLNwzkJmzS6T1vynbRlkP7ujE=.cdc817ba-ff29-49e6-97e5-264b0e948176@github.com>
 <1AGpdcS7qbxSFsJ4iaowWjffrOKpxKsRywWLnD_1h-A=.3356bec0-1c3f-457d-a2eb-daa50589bbdf@github.com>
 <yNZ1tynuIB6KbFUxltn99a_KxNpRa0LdiHCZgtB9T1I=.41b5b994-5e45-4404-9d75-4f3cae119898@github.com>
Message-ID: <dkglQ9y-2AFWKfV87Br6BO9CR-dGSyK9SSIP8T1wcag=.af09dbcb-d876-4583-aff8-dcec55175eb1@github.com>

On Mon, 23 Sep 2024 12:06:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> I think "can not be determined" just begs questions. Is this a JDK limitation, something I'm doing wrong, or something else, ... if you see what I mean.
>> 
>> I think saying 'no caller class on the stack' has the same effect though, unless someone knows how the implementation works (which may not be unreasonable), and is aware of the scenario where a java method is called from a new native thread. I thought it would look cleaner to have this be more 'explicitly unspecified' instead. But, maybe having something (vague or not), is better than nothing...
>
>> It is documented by the CS JEP: https://openjdk.org/jeps/176
> 
> I read the JEP, but it only refers to `sun.reflect.Reflection.getCallerClass`, which is an internal API that I don't expect external users to know about/understand.
> 
> To be clear: I don't think we should explain exactly how CS methods determine the caller. IMO, the fact that this is implemented using a stack walk is an implementation detail that users shouldn't have to know about (and it seems plausible for VM implementations to use other mechanisms). Or at least, that's what I would _like_ to think.
> 
> In lieu of that, I think it would be better to say that: in general (depending on the VM impl) there may be cases in which the caller can not be determined, and then as an example explicitly enumerate the cases in which the caller class can not be determined by the reference implementation. That explanation can then be linked to from the CS methods.

The whole notion of calls is implicitly stack-based so I'm not sure what your concern is here. A caller sensitive method's behaviour is affected by who its Java caller is, and that is implicitly "up the stack". Whether we walk the stack dynamically or have it recorded elsewhere for quick look up is not relevant, but the fact the caller is in the stack is simply a fact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1772692912

From dholmes at openjdk.org  Wed Oct  2 01:53:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 01:53:40 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v3]
In-Reply-To: <2FnLGXf2S5arfbUC-uyno4Emiwx5MAKPAB6CM_Fo-PU=.42d335cf-e283-4d09-97ec-da820eedaf51@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <OD5Dz4H-EvGUGevsUgAUdX-DXi7lcMlj_qQrFdrqyL0=.9cfcb95c-d7c1-4ec7-bd7d-8f6c2682b82c@github.com>
 <FCsQjdU7A7ezaZNO62sSJPScHAEzhGH99ktGyKVunPc=.ca03c6ee-09e3-4396-a40d-ec6ba63a4be6@github.com>
 <G5w1BMAjDHEXgd25MnUi9iSM018wIQgapeGMvLtvVLk=.f92b2755-7c3a-4e75-b924-ed156f215a76@github.com>
 <JLqME30VU0F--FtKZuCy6r9GChmneOctv9D8Rn3R1dI=.b5251f45-7b27-470f-8128-e202b6db7269@github.com>
 <MA1g4ugxGpNjN_5vYMPLNwzkJmzS6T1vynbRlkP7ujE=.cdc817ba-ff29-49e6-97e5-264b0e948176@github.com>
 <1AGpdcS7qbxSFsJ4iaowWjffrOKpxKsRywWLnD_1h-A=.3356bec0-1c3f-457d-a2eb-daa50589bbdf@github.com>
 <yNZ1tynuIB6KbFUxltn99a_KxNpRa0LdiHCZgtB9T1I=.41b5b994-5e45-4404-9d75-4f3cae119898@github.com>
 <1OIu-oVRoJPvJE72Tdh6o7q2uHU0iD2XfPvGkfVCWoE=.b64341b7-ad41-4344-b26d-465de03eed3f@github.com>
 <2FnLGXf2S5arfbUC-uyno4Emiwx5MAKPAB6CM_Fo-PU=.42d335cf-e283-4d09-97ec-da820eedaf51@github.com>
Message-ID: <TU8I79I1fM5-fUm7Vm3WQrpp0B5ImoG5o_Da5_JFlOk=.b219e51a-26e8-4a29-ac6d-e144734dc62f@github.com>

On Tue, 24 Sep 2024 14:48:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> The "stack" is exposed in the API with StackWalker, Thread::getStackTrace and other APIs. For CS and restricted methods then I think we are trying to convey that there are no Java frames on the caller stack. Several existing CS APIs document the case where there is "no caller frame on the stack". This is mostly to cover the case where a CS method is invoked from a JNI attached thread. If there are native frames sandwiched between Java frames and a CS method then the intention was that these methods use the Java frame for the check, but that is hard to specify and it sounds like we have to re-visit this a bit.
>> 
>> For now, I think the proposed wording in this PR is okay. There are clearly some follows up needed.
>
>> For now, I think the proposed wording in this PR is okay. 
> 
> Yes, I agree what I'm suggesting is out of scope for this PR.

> as an example explicitly enumerate the cases in which the caller class can not be determined by the reference implementation

Any accessible CS method can be called directly from JNI and so have no Java caller on the stack.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1783749430

From henryjen at openjdk.org  Wed Oct  2 02:04:35 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 2 Oct 2024 02:04:35 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v3]
In-Reply-To: <PHcgSgtgxfAHpFOS16ibX_Z_8jcLDscDDfiM1GVnrlI=.ce3fa939-852e-40ce-87c4-2fe425660710@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <ZFeRSh2srMD1N6pj0o75l_L4JfIK4jBbcumcHVhdeeA=.f621bf17-b36a-459a-bc45-5a1c492b5862@github.com>
 <a88h9OyDv_ysObDgEjqv04yqqRB3uWhB0mYq_twEH8k=.f65717a2-1425-47dc-bf3b-ec316ea1b47b@github.com>
 <ps6kNtRr_hIm0TvRz7qKVcU9XCw7_7dhMYUKY-FHN5I=.cc2035de-3dd9-45b5-9909-ee73ab5032cd@github.com>
 <oPEP460Zy3E3NzEY8syxmpWy4HCQGa6aVQjofTPX80Q=.ce14baa2-ee0b-41c9-b891-ef8e645a3adc@github.com>
 <PHcgSgtgxfAHpFOS16ibX_Z_8jcLDscDDfiM1GVnrlI=.ce3fa939-852e-40ce-87c4-2fe425660710@github.com>
Message-ID: <q_ShE9nMWeg4a7inyQZWhdvUXyb8e2iw1OobB3H5B1E=.9e0f625b-8a8b-4a05-8856-b07f0132e450@github.com>

On Mon, 30 Sep 2024 15:26:07 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Hello Henry, I think this `-k` option help text would need a slight modification. Right now it states that if a file appears more than once in an archive, then this setting this flag will not overwrite the earlier copies. In reality, it doesn't matter how many times the file appears in the archive - even if it appears just once, and if the file is being extracted into a directory which already has the same named file at that path, then this `-k` flag will not overwrite that existing file.
>> 
>> So I think we should reword it to talk about its behaviour in context of some file already existing in the destination directory where the jar contents are being extracted. 
>> 
>> I wonder if we should make a mention that we don't do any case sensitive checks for the existence of the file in the destination directory and instead we use filesystem API to check for existence (which depending on the filesystem may be case insensitive, like macosx).
>
> You have valid point. I refer to the tar man page, and I thought do not overwrite existing files says it. The in particular is just to call out a specific use case.

Please review the update and see if that's good enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1783755856

From dholmes at openjdk.org  Wed Oct  2 02:16:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 02:16:42 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v9]
In-Reply-To: <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
Message-ID: <WSLrm07XPgw4024Z32lDS6xnyyZ-VrGARzO8CYLlz7M=.490ea91d-5eb1-494c-970c-fdad8bd57683@github.com>

On Tue, 1 Oct 2024 17:30:10 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trailing whitespace

Nothing further from me on the VM side. Just a couple of minor nits.

Thanks

src/hotspot/share/cds/filemap.cpp line 974:

> 972:   if (header()->has_full_module_graph() && !matched_module_paths) {
> 973:     CDSConfig::stop_using_optimized_module_handling();
> 974:     log_info(cds)("optimized module handling: disabled because mismatched module paths");

Suggestion:

    log_info(cds)("optimized module handling: disabled because of mismatched module paths");

src/hotspot/share/cds/heapShared.cpp line 885:

> 883:       ClassLoaderExt::num_module_paths() > 0) {
> 884:     // ArchivedModuleGraph was created with a --module-path that's different than the runtime --module-path.
> 885:     // Thus, it might contain references to modules that do not exist in runtime. We cannot use it.

Suggestion:

    // Thus, it might contain references to modules that do not exist at runtime. We cannot use it.

src/hotspot/share/classfile/classLoaderExt.cpp line 123:

> 121: 
> 122:   // Sort the module paths before storing into CDS archive for simpler
> 123:   // checking during runtime.

Suggestion:

  // checking at runtime.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21048#pullrequestreview-2341785448
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783757502
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783754320
PR Review Comment: https://git.openjdk.org/jdk/pull/21048#discussion_r1783758610

From iklam at openjdk.org  Wed Oct  2 03:00:36 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Oct 2024 03:00:36 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v9]
In-Reply-To: <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
Message-ID: <t-VwcaJ1AYAtJYoVowLiSgpsIZZZ7kkvGfyBAceQ-uI=.2df8b23d-e4e1-4ecf-8c2b-d29075a8be2a@github.com>

On Tue, 1 Oct 2024 17:30:10 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trailing whitespace

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21048#pullrequestreview-2341825251

From liach at openjdk.org  Wed Oct  2 03:32:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Oct 2024 03:32:45 GMT
Subject: RFR: 8341277: Validate slot argument for instruction factories
In-Reply-To: <lODCQNzWsyYv_d8I0tu24rPWDDVTOW75rsjlV07XX4Q=.256e6f3c-b05b-470b-852d-2c1aa4d67def@github.com>
References: <lODCQNzWsyYv_d8I0tu24rPWDDVTOW75rsjlV07XX4Q=.256e6f3c-b05b-470b-852d-2c1aa4d67def@github.com>
Message-ID: <jTtaKqYR2CzuF2a6jsCWeZHkktl85e9qasw2ffnsF3M=.ba150e19-30a1-44a7-8f5c-c8ff6014cc46@github.com>

On Mon, 30 Sep 2024 23:36:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> Perform validation of local variable slots, multinewarray dimension, iinc value and specify these validations are performed. Specify these exception behaviors for sipush and bipush as well.
> 
> This validation avoids using invalid values that will be lost once class files are written, and avoids invalid value pollution from upstream in chained transformations.
> 
> This changes the exception specs of Class-File API, but does not block the JEP as it does not change the intended functionality of these APIs.
> 
> Unfortunately, I cannot test the DirectCodeBuilder overloads due to it failing to generate stack maps, so the tests are restricted to instruction factories.

I think I can probably add a system property to suppress stack map generation/stack counting to test contracts on `CodeBuilder`, but will do it in a separate patch instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/21275#issuecomment-2387558571

From liach at openjdk.org  Wed Oct  2 03:32:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Oct 2024 03:32:46 GMT
Subject: Integrated: 8341277: Validate slot argument for instruction factories
In-Reply-To: <lODCQNzWsyYv_d8I0tu24rPWDDVTOW75rsjlV07XX4Q=.256e6f3c-b05b-470b-852d-2c1aa4d67def@github.com>
References: <lODCQNzWsyYv_d8I0tu24rPWDDVTOW75rsjlV07XX4Q=.256e6f3c-b05b-470b-852d-2c1aa4d67def@github.com>
Message-ID: <7CcfkuomKi2R8N42WA29mJZKwVhdItSPZFAFHdQgA3g=.ced431ed-2db6-4759-a079-640df5e554bb@github.com>

On Mon, 30 Sep 2024 23:36:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> Perform validation of local variable slots, multinewarray dimension, iinc value and specify these validations are performed. Specify these exception behaviors for sipush and bipush as well.
> 
> This validation avoids using invalid values that will be lost once class files are written, and avoids invalid value pollution from upstream in chained transformations.
> 
> This changes the exception specs of Class-File API, but does not block the JEP as it does not change the intended functionality of these APIs.
> 
> Unfortunately, I cannot test the DirectCodeBuilder overloads due to it failing to generate stack maps, so the tests are restricted to instruction factories.

This pull request has now been integrated.

Changeset: 39c17b39
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39c17b392699007496816f788fca9fbe670dd6f8
Stats:     417 lines in 15 files changed: 337 ins; 51 del; 29 mod

8341277: Validate slot argument for instruction factories

Reviewed-by: asotona

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

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

From liach at openjdk.org  Wed Oct  2 03:35:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Oct 2024 03:35:36 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
Message-ID: <Fq0tfWmY9EMx4_j1-h1K5oUBEmoeAPQW43p0aIEeepg=.0ed2af2a-315f-4389-b90d-a0221d7b30e1@github.com>

On Sun, 29 Sep 2024 17:44:30 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
> 
> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.

test/jdk/java/util/ArrayList/Bug8340572.java line 34:

> 32:  */
> 33: 
> 34: public class Bug8340572 {

Can we give this a descriptive name, like `ConcurrentSubListSort`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21250#discussion_r1783800883

From swen at openjdk.org  Wed Oct  2 04:29:12 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 2 Oct 2024 04:29:12 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v18]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <j_FNL_zcKqQum3MLyqtRtV5_vLqOz-iB4kzohN_XACY=.ac3fd7b4-31fd-4c10-8c37-8dd6d8c78800@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits:

 - Merge branch 'master' into optim_direct_code_builder_202409
 - optimize DirectClassBuilder::build
 - writeU2U2U2
 - optimization for powerOctal
 - label write clean
 - optimizer for codeSize
 - optimize MethodTypeDescImpl::descriptorString
 - Remove redundant requireNonNull
 - optimize buildContent
 - optimize setLabelTarget
 - ... and 67 more: https://git.openjdk.org/jdk/compare/39c17b39...6dfa07ed

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

Changes: https://git.openjdk.org/jdk/pull/21243/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=17
  Stats: 967 lines in 16 files changed: 585 ins; 119 del; 263 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

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

From swen at openjdk.org  Wed Oct  2 04:32:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 2 Oct 2024 04:32:10 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v19]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <owv1MsiRKgK4LjPEYYgPvxin-W1AsCUkq2ZCNiLHCrQ=.c9e5f436-0b3c-4b90-936a-736f8dc064b9@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix merge error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/6dfa07ed..8b092270

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=17-18

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

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

From dholmes at openjdk.org  Wed Oct  2 05:17:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 05:17:35 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v6]
In-Reply-To: <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
Message-ID: <6yC3rrWKvUxQrkbcSKb9F8Oc4sXYMS-TIE3E034CgUY=.c0988c2e-e337-4379-a0cb-74c1f0a80e47@github.com>

On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix paths to links

Hmm seems github got confused and some of my comments last week did already get pushed through. Probably best to clearly state where I currently stand:

1. Now that I've seen how a restricted method gets marked up in the javadoc with the very prominent text and link to the restricted-methods page, I think that addresses my concern about each restricted method documenting what happens if there is no caller.
2. I do think there should be some description as to why a given method is declared "restricted", as it may not be obvious. But I will agree with Alan that this can addressed separately as needed.
3. I will just note that the description for this issue  is "Clarify handling of restricted and caller-sensitive methods" but there is nothing in the proposed changes that relate to CS methods, and I think we have agreed that any documentation that may be lacking for pre-existing CS methods should also be handled outside this PR.

Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2387646586

From ccheung at openjdk.org  Wed Oct  2 05:50:14 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 05:50:14 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v10]
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @dholmes-ora comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21048/files
  - new: https://git.openjdk.org/jdk/pull/21048/files/b9a9b75a..47f164fb

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

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

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

From ccheung at openjdk.org  Wed Oct  2 05:50:14 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 05:50:14 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v9]
In-Reply-To: <WSLrm07XPgw4024Z32lDS6xnyyZ-VrGARzO8CYLlz7M=.490ea91d-5eb1-494c-970c-fdad8bd57683@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <MgLRwRPJxwjuVSXL97IvjaOZRaEpT7CGNzryt0e4enA=.766c0e4b-b910-4d1c-8d1f-a785dceeaf32@github.com>
 <WSLrm07XPgw4024Z32lDS6xnyyZ-VrGARzO8CYLlz7M=.490ea91d-5eb1-494c-970c-fdad8bd57683@github.com>
Message-ID: <WBau3nLuwAYZQxCxudtXWRERs5-ZyYmU3tJrdEfeCwY=.8c45a58c-69db-4ed3-b960-2c161acdface@github.com>

On Wed, 2 Oct 2024 02:13:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Nothing further from me on the VM side. Just a couple of minor nits.
> 
> Thanks

I've pushed another commit to address the nits.
Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21048#issuecomment-2387676650

From alanb at openjdk.org  Wed Oct  2 06:48:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Oct 2024 06:48:46 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification [v2]
In-Reply-To: <UetM6IVXP1D5fn9NGjJALDixrGPO51YjgW2bSEnvOF8=.c56af6e1-9ab7-4d85-9d20-53f6cf9abea8@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <UetM6IVXP1D5fn9NGjJALDixrGPO51YjgW2bSEnvOF8=.c56af6e1-9ab7-4d85-9d20-53f6cf9abea8@github.com>
Message-ID: <qsnQerjkdIAzCUIGWwFPigsi5uP0yzCQRNSJ6podalI=.623720de-b2a7-45f1-a50b-5738ec3fe697@github.com>

On Tue, 1 Oct 2024 16:08:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8340229: Revert FIS(fdObj) change

src/java.base/share/classes/java/io/FileInputStream.java line 118:

> 116:     /**
> 117:      * Creates a {@code FileInputStream} to read from an existing file
> 118:      * reoresented by the {@code File} object {@code file}.

Suggestion:

     * represented by the {@code File} object {@code file}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1783908169

From alanb at openjdk.org  Wed Oct  2 07:42:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Oct 2024 07:42:38 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v10]
In-Reply-To: <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>
Message-ID: <nDSy2CigmErZcYzjiCQWJRYrOmWEHq-adxUNXd5S_D8=.44190dca-1e49-45be-8934-a49e36c21243@github.com>

On Wed, 2 Oct 2024 05:50:14 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

Thanks for the updates, I don't have any other comments.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21048#pullrequestreview-2342081231

From mbaesken at openjdk.org  Wed Oct  2 07:58:40 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 2 Oct 2024 07:58:40 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Lju2Q06vASMUTddIzoJX4NuaXBzbj_6_Q5KWJ72IYec=.3ef1b9b0-1da1-4622-8528-744d0a23b6e6@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <O7XW4a3YxSJeLCtbLUJ73xeINN5P0m2MQMEPtbkhuNU=.05a00a08-6a49-42be-917c-4df8702f3f9b@github.com>
 <Lju2Q06vASMUTddIzoJX4NuaXBzbj_6_Q5KWJ72IYec=.3ef1b9b0-1da1-4622-8528-744d0a23b6e6@github.com>
Message-ID: <qOa30w0Zk0hHo5U5H_IYHluC5p-m9aAvs4UDXUS5lIY=.26d80f4f-ac1d-4009-a867-a5b0957b9072@github.com>

On Tue, 1 Oct 2024 08:20:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> `jni_md.h` is shipped as part of every JDK distribution - this change does NOT belong in that file.
>
>> `jni_md.h` is shipped as part of every JDK distribution - this change does NOT belong in that file.
> 
> Hi David, should I introduce a separate ub.hpp  (similar to what we have in Hotspot) ?

> @MBaesken my understanding is that src/java.base/share/native/include is for exported header files, it is not a general location to put this new header.

Seems the include directories
src/java.base/unix/native/libjava
and also hotspot/os/posix/include  and  src/hotspot/share/include 
show up in the  '-I'  settings of these C compilation units in jdk.  And from what I see those are not exported
Should I move the header to  some of these ?
Putting it into some hotspot location sounds odd  because we have already 'sanitizers/ub.hpp'    in hotspot.
So maybe src/java.base/unix/native/libjava  ?

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

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2387849588

From mbaesken at openjdk.org  Wed Oct  2 08:17:39 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 2 Oct 2024 08:17:39 GMT
Subject: Integrated: 8341135: Incorrect format string after JDK-8339475
In-Reply-To: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
References: <QldLLQvVUQ-ah_2j1EL1skqu8_QVgVrEG6-YgcuE4Cw=.3908aa2a-b40d-49e2-afc2-2ed4b422bcc9@github.com>
Message-ID: <_SSL5uYP2OiPrLMtQjMSSAbhbNNNuxPx38VHTjmj54M=.c91f70b6-0774-446f-8e1c-dc907a1bd358@github.com>

On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This fixes a format string issue.
> 
> In the error report it was reported : 'The compiler should be able to catch this if JLI_ReportErrorMessageSys was declared with something like __attribute__ ((format (printf, 1, 2))).'
> Should we maybe adjust  JLI_ReportErrorMessageSys , JLI_ReportErrorMessage  and related functions/methods  using a format string so that such errors can be found already at build time ?

This pull request has now been integrated.

Changeset: c8c4ff20
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8c4ff2035c4e19a71f4395d23f036ba88d2e291
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8341135: Incorrect format string after JDK-8339475

Reviewed-by: shade, clanger, alanb

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

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

From rgiulietti at openjdk.org  Wed Oct  2 08:53:37 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 2 Oct 2024 08:53:37 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]
In-Reply-To: <rR809jlAUr76JxVjmp0geb9K6vuqsLTTBh5HLPmD2VM=.063ae524-8db1-421f-82f2-647fdb19aae4@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
 <rR809jlAUr76JxVjmp0geb9K6vuqsLTTBh5HLPmD2VM=.063ae524-8db1-421f-82f2-647fdb19aae4@github.com>
Message-ID: <D1JqNrFRoTHcPJBbQezwi0vsaIBrk9NIHq9LEFdRbuU=.490ba01c-c03d-4a31-9c8c-035d65d7edd0@github.com>

On Tue, 1 Oct 2024 20:43:24 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code simplification
>
> `/integrate`

@fabioromano1 Seems like your integration was not successful.
Retry without any formatting, just /integrate

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2387952388

From dholmes at openjdk.org  Wed Oct  2 09:41:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 09:41:40 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]
In-Reply-To: <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
Message-ID: <Y25NH3pX3xwsvAoumohHxxj_VNX-GEZr4LjK5fNjlJ0=.38d47630-c93d-4cfe-861e-cb605e7526c2@github.com>

On Tue, 1 Oct 2024 13:45:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ubsan changes from jni_md.h

`hotspot/share/include` contains the headers that hotspot exports to the jdk. `os/posix/include/` has the platform specific header that hotspot exports to the jdk.

> So maybe src/java.base/unix/native/libjava

That is header files for libjava.

This is why I said it would be hard to find a shared location where this can be used across different modules - because there presently isn't one.

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

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2388071669

From duke at openjdk.org  Wed Oct  2 09:43:38 2024
From: duke at openjdk.org (duke)
Date: Wed, 2 Oct 2024 09:43:38 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v17]
In-Reply-To: <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
 <3TjrYtG4sij3fwGwDT4h2BrrrLbvLtwrflwN39r5v8k=.bc54d909-8b7b-456e-a74e-ccb1e78596cc@github.com>
Message-ID: <5KAwKvQg4N3VbArnAcAqNg8R_2OOdsJ_o_kK1iwgrR8=.ed620b87-52aa-45ef-8333-332086111d14@github.com>

On Tue, 1 Oct 2024 14:21:19 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

@fabioromano1 
Your change (at version d324f495514a05715ea085967212fb726ce73954) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20008#issuecomment-2388080847

From duke at openjdk.org  Wed Oct  2 09:48:44 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 2 Oct 2024 09:48:44 GMT
Subject: Integrated: 8336274: MutableBigInteger.leftShift(int) optimization
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <C7E17OEqlm6oWI_6sIR0_szhmOzgwwKs3lI86ldRCtc=.eecdd5fd-fb17-4271-b17c-0cba494d20fe@github.com>

On Wed, 3 Jul 2024 14:17:37 GMT, fabioromano1 <duke at openjdk.org> wrote:

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

This pull request has now been integrated.

Changeset: d6820d13
Author:    fabioromano1 <51378941+fabioromano1 at users.noreply.github.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6820d1324711eac95a297dd68ec94e6f6be4b35
Stats:     476 lines in 3 files changed: 423 ins; 25 del; 28 mod

8336274: MutableBigInteger.leftShift(int) optimization

Reviewed-by: rgiulietti

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

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

From thartmann at openjdk.org  Wed Oct  2 10:49:36 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Oct 2024 10:49:36 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
Message-ID: <V1ChvAolG5oJx4Y9AGbLAwmsYxcg2gmvMDGy6J2BHMU=.8a15d731-ba69-4cfa-9471-6b064feab70f@github.com>

On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 server fastdebug, `all`
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also dispatch to slow-path on other arches

test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java line 2:

> 1: //
> 2: // * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.

Drive-by comment: The `// *` format looks weird.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1784292673

From mbaesken at openjdk.org  Wed Oct  2 11:39:35 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 2 Oct 2024 11:39:35 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]
In-Reply-To: <Y25NH3pX3xwsvAoumohHxxj_VNX-GEZr4LjK5fNjlJ0=.38d47630-c93d-4cfe-861e-cb605e7526c2@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
 <Y25NH3pX3xwsvAoumohHxxj_VNX-GEZr4LjK5fNjlJ0=.38d47630-c93d-4cfe-861e-cb605e7526c2@github.com>
Message-ID: <bGgVmiz3Gsu6upuyZsD-tXpd3G7ZFXez7UaT6wHFLrU=.a4d2544f-a85f-42be-b2f5-3428a905054a@github.com>

On Wed, 2 Oct 2024 09:38:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > So maybe src/java.base/unix/native/libjava
> 
> That is header files for libjava.
> 
> This is why I said it would be hard to find a shared location where this can be used across different modules - because there presently isn't one.

In practise the headers from there go into **a lot** of libs across the whole  jdk C codebase.
Take for example jni_util.h  (share/native/libjava/jni_util.h) - I see this additionally to libjava in C code from libmanagement, awt, librmi , libnio  just to name a few .

So maybe  jni_util.h /  jni_util_md.h  itself is a place where this can be put.  Or a header located beside it .

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

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2388428790

From duke at openjdk.org  Wed Oct  2 11:41:06 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 2 Oct 2024 11:41:06 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
Message-ID: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@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.

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

Commit messages:
 - Merge branch 'openjdk:master' into patchBigDecimalSqrt
 - Change BigDecimal.sqrt() implementation

Changes: https://git.openjdk.org/jdk/pull/21301/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341402
  Stats: 302 lines in 2 files changed: 109 ins; 129 del; 64 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 Oct  2 13:28:42 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 2 Oct 2024 13:28:42 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v8]
In-Reply-To: <uk0JI1cKrg6jWecOzS6Ysmk-4GJ_nI8dcInmd5cxhqU=.cc6865cd-46a4-4ab1-a52c-0e2eaa8acade@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
 <uk0JI1cKrg6jWecOzS6Ysmk-4GJ_nI8dcInmd5cxhqU=.cc6865cd-46a4-4ab1-a52c-0e2eaa8acade@github.com>
Message-ID: <hmROxxv_l2UIyTn5vnB_PvPo7ibiP-Jl5hUrdqqKjWc=.8851f833-6066-4c4e-8957-ac9299a195c9@github.com>

On Mon, 30 Sep 2024 20:30:57 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> I think that if there is a PortUnreachable thrown, during DnsClient.query processing from the doUdpQuery, then the timeout may expire early ... if I've interpreted the outer loop processing correctly

The `DnsClient.query` marks server as misconfigured (not suitable for further retries) in scenarios when  `PortUnreachable` is caught (see `doNotRetry`). And since the timeout/retries are specified per server it is expected for the timeout to expire early. For scenarios with one server and `PortUnreachable` exception - the `DnsClient.query` will throw the `CommunicationException`  with `PortUnreachable` set as its cause.

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

PR Comment: https://git.openjdk.org/jdk/pull/20892#issuecomment-2388641756

From aefimov at openjdk.org  Wed Oct  2 13:38:18 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 2 Oct 2024 13:38:18 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v8]
In-Reply-To: <fxZZ1yA6aBrXUB597Rj15ffQ0sCTW9GImpdE97sOlWw=.a5dfad55-09c4-4c9c-9632-b69127757050@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
 <fxZZ1yA6aBrXUB597Rj15ffQ0sCTW9GImpdE97sOlWw=.a5dfad55-09c4-4c9c-9632-b69127757050@github.com>
Message-ID: <xFEyEKzkNzt4dsBnAUJctqYX6-rty5C-gaVnZRlVnpk=.839bdfaf-1ca8-4539-9258-d05f0ef8f4e8@github.com>

On Mon, 30 Sep 2024 13:38:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Track unfulfilled timeouts during UDP queries.
>>   Update exceptions handling.
>>   Update TCP client to use nano time source.
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 247:
> 
>> 245:                         continue;
>> 246:                     }
>> 247:                     AtomicLong unfulfilledServerTimeout = unfulfilledUdpTimeouts[i];
> 
> Suggestion:
> 
>                     // unfulfilledServerTimeout is always >= 0
>                     AtomicLong unfulfilledServerTimeout = unfulfilledUdpTimeouts[i];

Thanks for the suggestion. Added in [793cfda](https://github.com/openjdk/jdk/pull/20892/commits/793cfda3282788d5af5efa57db6eeb58641eb3ed)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1784539513

From aefimov at openjdk.org  Wed Oct  2 13:38:17 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 2 Oct 2024 13:38:17 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v9]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <LKxjEdW30-Ftwl9OaAk3PTeH2DIozenA2W4YOubxCZI=.7acbb4e5-f367-44da-87bc-d98c45baf411@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Add comment suggested by Daniel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/70922207..793cfda3

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

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

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

From dfuchs at openjdk.org  Wed Oct  2 13:38:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 2 Oct 2024 13:38:17 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v9]
In-Reply-To: <LKxjEdW30-Ftwl9OaAk3PTeH2DIozenA2W4YOubxCZI=.7acbb4e5-f367-44da-87bc-d98c45baf411@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <LKxjEdW30-Ftwl9OaAk3PTeH2DIozenA2W4YOubxCZI=.7acbb4e5-f367-44da-87bc-d98c45baf411@github.com>
Message-ID: <1f6noo5OebWePKbiuCTguLQYvGZ9XQ43k9mZm2hu31I=.16b279d8-5c34-4395-9818-2daf28af279e@github.com>

On Wed, 2 Oct 2024 13:35:00 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment suggested by Daniel

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20892#pullrequestreview-2342978749

From rgiulietti at openjdk.org  Wed Oct  2 13:47:36 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 2 Oct 2024 13:47:36 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <IS8RKT9AcGJuhjLtW9XSOjBjXZYH8RKc14k8RbjILH8=.44639722-5970-428a-bc37-114f66d2887d@github.com>

On Wed, 2 Oct 2024 10:31:09 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.

This takes more than 3 minutes on my laptop, although it is faster than the current implementation:
`BigDecimal.valueOf(121).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN)).shortValue()`

I think the running time is dominated by the back scaling, which involves a division by a large power of 10.

I wonder if scaling up and down by an appropriate combination of large powers of 2 and small powers of 10 might improve performance for such high precision. The combination should, of course, minimally cover the requested precision. Final corrective steps might be needed, though.

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()`

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2388683885

From swen at openjdk.org  Wed Oct  2 13:49:11 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 2 Oct 2024 13:49:11 GMT
Subject: RFR: 8341415: Optimize RawBytecodeHelper::next
Message-ID: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>

A small optimization to the RawBytecodeHelper::next method
* Remove `len <= 0` once
* merge store opcode and isWide

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

Commit messages:
 - merge store opcode & isWide
 - optimize RawBytecodeHelper::next

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

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

From duke at openjdk.org  Wed Oct  2 13:49:11 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 2 Oct 2024 13:49:11 GMT
Subject: RFR: 8341415: Optimize RawBytecodeHelper::next
In-Reply-To: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
References: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
Message-ID: <vzpcD7R5Iu3_egyqZhb2W1sCi2usgQH1mq6fdRuT9QI=.65de2b13-fa74-4bcd-8327-f86c8ea4f29e@github.com>

On Wed, 2 Oct 2024 07:53:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to the RawBytecodeHelper::next method
> * Remove `len <= 0` once
> * merge store opcode and isWide

src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 350:

> 348:      */
> 349:     public boolean isWide() {
> 350:         return (opcode & (WIDE << 8)) != 0;

Suggestion:

        return (opcode >>> 8) == WIDE;

src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 449:

> 447:         }
> 448: 
> 449:         if ((nextBci += len) > end) {

This?change makes?it?that `nextBci` will?no?longer monotonically increase in?case of?a?malformed special?instruction.

Suggestion:

        if (len <= 0 || (nextBci += len) > end) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21300#discussion_r1784315687
PR Review Comment: https://git.openjdk.org/jdk/pull/21300#discussion_r1784331432

From swen at openjdk.org  Wed Oct  2 13:49:11 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 2 Oct 2024 13:49:11 GMT
Subject: RFR: 8341415: Optimize RawBytecodeHelper::next
In-Reply-To: <vzpcD7R5Iu3_egyqZhb2W1sCi2usgQH1mq6fdRuT9QI=.65de2b13-fa74-4bcd-8327-f86c8ea4f29e@github.com>
References: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
 <vzpcD7R5Iu3_egyqZhb2W1sCi2usgQH1mq6fdRuT9QI=.65de2b13-fa74-4bcd-8327-f86c8ea4f29e@github.com>
Message-ID: <bDF2MYoCu3u_ZUVornyj1xoCQ2RPxCmJrkp4BD08hhA=.c3c545cf-6ff7-4cca-bc5c-cef6ae5e492d@github.com>

On Wed, 2 Oct 2024 11:09:52 GMT, ExE Boss <duke at openjdk.org> wrote:

>> A small optimization to the RawBytecodeHelper::next method
>> * Remove `len <= 0` once
>> * merge store opcode and isWide
>
> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 350:
> 
>> 348:      */
>> 349:     public boolean isWide() {
>> 350:         return (opcode & (WIDE << 8)) != 0;
> 
> Suggestion:
> 
>         return (opcode >>> 8) == WIDE;

WIDE is a constant, WIDE << 8 will do constant folding, your suggestion will be longer in bytecode.

> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 449:
> 
>> 447:         }
>> 448: 
>> 449:         if ((nextBci += len) > end) {
> 
> This?change makes?it?that `nextBci` will?no?longer monotonically increase in?case of?a?malformed special?instruction.
> 
> Suggestion:
> 
>         if (len <= 0 || (nextBci += len) > end) {

The checkSpecialInstruction has already added the 'len <= 0' process, so there is no need to check 'len <= '0' again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21300#discussion_r1784531869
PR Review Comment: https://git.openjdk.org/jdk/pull/21300#discussion_r1784533279

From rgiulietti at openjdk.org  Wed Oct  2 13:52:36 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 2 Oct 2024 13:52:36 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <xG4f_Myviavs6EJJLDyuJF6rP73txEtCsQ-uffNsrc8=.9129d7b0-0dfc-4878-aa4c-b8e6306f6683@github.com>

On Wed, 2 Oct 2024 10:31:09 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.

Looking at the code, the divisors are quite limited, so my hypothesis above and the suggestions are out of place.

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2388696062

From swen at openjdk.org  Wed Oct  2 13:57:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 2 Oct 2024 13:57:37 GMT
Subject: RFR: 8341415: Optimize RawBytecodeHelper::next
In-Reply-To: <bDF2MYoCu3u_ZUVornyj1xoCQ2RPxCmJrkp4BD08hhA=.c3c545cf-6ff7-4cca-bc5c-cef6ae5e492d@github.com>
References: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
 <vzpcD7R5Iu3_egyqZhb2W1sCi2usgQH1mq6fdRuT9QI=.65de2b13-fa74-4bcd-8327-f86c8ea4f29e@github.com>
 <bDF2MYoCu3u_ZUVornyj1xoCQ2RPxCmJrkp4BD08hhA=.c3c545cf-6ff7-4cca-bc5c-cef6ae5e492d@github.com>
Message-ID: <W-_a_eb9eGaMjuVZXA6dULxELXe71NZuOtdf-B1LE1U=.7c29c0cf-c911-438d-812d-668a26e18257@github.com>

On Wed, 2 Oct 2024 13:28:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 350:
>> 
>>> 348:      */
>>> 349:     public boolean isWide() {
>>> 350:         return (opcode & (WIDE << 8)) != 0;
>> 
>> Suggestion:
>> 
>>         return (opcode >>> 8) == WIDE;
>
> WIDE is a constant, WIDE << 8 will do constant folding, your suggestion will be longer in bytecode.

public isWide()Z
   L0
    LINENUMBER 8 L0
    ALOAD 0
    GETFIELD internal/classfile/impl/RawBytecodeHelper.opcode : I
    LDC 50176
    IAND
    IFEQ L1
    ICONST_1
    GOTO L2
   L1
   FRAME SAME
    ICONST_0
   L2
   FRAME SAME1 I
    IRETURN
   L3
    LOCALVARIABLE this Linternal/classfile/impl/RawBytecodeHelper; L0 L3 0
    MAXSTACK = 2
    MAXLOCALS = 1
}

public isWide1()Z
   L0
    LINENUMBER 12 L0
    ALOAD 0
    GETFIELD internal/classfile/impl/RawBytecodeHelper.opcode : I
    BIPUSH 8
    IUSHR
    SIPUSH 196
    IF_ICMPNE L1
    ICONST_1
    GOTO L2
   L1
   FRAME SAME
    ICONST_0
   L2
   FRAME SAME1 I
    IRETURN
   L3
    LOCALVARIABLE this Linternal/classfile/impl/RawBytecodeHelper; L0 L3 0
    MAXSTACK = 2
    MAXLOCALS = 1
}



The above are the bytecodes of the two implementations. It can be seen that the original implementation is more concise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21300#discussion_r1784575918

From mcimadamore at openjdk.org  Wed Oct  2 14:02:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 2 Oct 2024 14:02:19 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v5]
In-Reply-To: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
Message-ID: <nkFSZWJ4JuhfUYy2ZVSDTj9vb9Tg0KM4AkDFVSOuji0=.c81bd431-3b9b-4af6-ac6b-17e56c067e17@github.com>

> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
> 
> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
> 
> This problem was originally reported here:
> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
> 
> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
> 
> 
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
> 
> 
> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add `@ForceInline` to `MethodHandle::asType`, as per review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21283/files
  - new: https://git.openjdk.org/jdk/pull/21283/files/964a273f..c4daec51

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

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

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

From mcimadamore at openjdk.org  Wed Oct  2 14:02:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 2 Oct 2024 14:02:19 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v4]
In-Reply-To: <SRLEZW4ALgLREa2qssaBQhTGoRKL6PKnrjki8tF93h4=.b9f41d57-bf55-455f-aeb3-6a508764eef9@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <8vSM8Uy5IXsnlurOK1fEC6kIahVGeERepIyG8RWsef0=.8cd004e6-890a-45c5-b021-be46bfd8c1dc@github.com>
 <SRLEZW4ALgLREa2qssaBQhTGoRKL6PKnrjki8tF93h4=.b9f41d57-bf55-455f-aeb3-6a508764eef9@github.com>
Message-ID: <LRL4pZ5S73KD81hKPohdAfNtHIl7XF2ONJbvrui3e2o=.60096c4e-fbb5-453f-9260-44228b80c3bf@github.com>

On Tue, 1 Oct 2024 22:51:01 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I don't have a clear understanding how `VarHandleGuards` is used, but I assume that `MethodHandle::asType` calls there are no-ops in scenarios you care about.

A var handle guard is a piece of code that detects var handle call of a certain shape, to avoid creation of lambda forms in some common cases. This was done in Java 9, and was unchanged by FFM. In this case, we just happen to hit the var handle guard for `(LJ -> J)`. And yes, the asType adaptation is a no-op here.

The difference is that in the normal code path (lambda form), the call to `asType` is guarded by a check:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/Invokers.java#L513

Normally, var handle guards don't need an `asType` adaptation:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java#L230

But if a var handle guard is triggered on an "indirect" var handle (read:  a var handle that has been adapted with some combinator - this part is new since FFM), then we go through a different path in the guard code which _always_ calls `asType`:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java#L233

(note: this "slow path" inside var handle guards predates FFM, but var handle adaptation has increased the number of cases in which we hit this slow path).

The PR that introduced this regression made all FFM var handles undergo some adaptation. Which is why now we're seeing this issue - as we're now hitting a (no-op) `asType` call which was never made before.

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

PR Comment: https://git.openjdk.org/jdk/pull/21283#issuecomment-2388712441

From duke at openjdk.org  Wed Oct  2 14:02:37 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 2 Oct 2024 14:02:37 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <xG4f_Myviavs6EJJLDyuJF6rP73txEtCsQ-uffNsrc8=.9129d7b0-0dfc-4878-aa4c-b8e6306f6683@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <xG4f_Myviavs6EJJLDyuJF6rP73txEtCsQ-uffNsrc8=.9129d7b0-0dfc-4878-aa4c-b8e6306f6683@github.com>
Message-ID: <_cQhoaIpW9GVVHmJbQXPuL-_7IsITEx08DAYRByBJbY=.338068bd-f7a2-494a-9983-02c25a0551d3@github.com>

On Wed, 2 Oct 2024 13:49:29 GMT, Raffaello Giulietti <rgiulietti 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.
>
> Looking at the code, the divisors are quite limited, so my hypothesis above and the suggestions are out of place.

@rgiulietti The fundamental problem is that `BigDecimal` numbers store the magnitude in binary, using `BigInteger`s objects. A solution could have been to store the magnitude in radix 10 rather than in binary, but obviously this would require to redesign the entire class `BigDecimal`, which is undesirable.

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2388722321

From nbenalla at openjdk.org  Wed Oct  2 14:03:59 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 2 Oct 2024 14:03:59 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v16]
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <ptKUj1eaw0YHXVsjJn4jyxXrBrOSuX2ajp-IU-wBL9I=.3e1c3665-4a87-49f9-b07e-d34e3fb5cf38@github.com>

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - extra check to make sure we're excluding sub-packages too
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - exclude list is now module specific
 - remove empty if statement, debugging showed the condition is never true
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - Change "found" to "should be" in the error messages
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - avoid using `continue`, fix mistake in last commit
 - extend SinceChecker to now skip some packages
 - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
 - ... and 23 more: https://git.openjdk.org/jdk/compare/d6820d13...47ba2a1c

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

Changes: https://git.openjdk.org/jdk/pull/18934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18934&range=15
  Stats: 989 lines in 3 files changed: 987 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18934/head:pull/18934

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

From rgiulietti at openjdk.org  Wed Oct  2 14:16:34 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 2 Oct 2024 14:16:34 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <HXDMFGok1zSDbitQaLG2HjpV_LTQ5XU_7AY229EGBTk=.ba2d2695-9d06-47be-96fe-74fdc571e7b7@github.com>

On Wed, 2 Oct 2024 10:31:09 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.

Sure, but that does not explain the slow running times.

Na?vely, this takes around 1s for the required precision of 1_000_000 decimal digits.
`new BigDecimal(BigInteger.valueOf(121).multiply(BigInteger.TEN.pow(2_000_000)).sqrt(), 1_000_000).shortValue()`

Of course, this is just a special case.

Do I miss something?

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2388759527

From vtewari at openjdk.org  Wed Oct  2 14:17:43 2024
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 2 Oct 2024 14:17:43 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v3]
In-Reply-To: <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>
Message-ID: <jjfDpzGukzdnnBGR8rPiSsF61x7K-0iEng1c8JHkp1s=.d8ae0524-0d1a-406f-b56a-c4b0311f5907@github.com>

On Mon, 30 Sep 2024 16:11:14 GMT, sbgoog <duke at openjdk.org> wrote:

>> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.
>
> sbgoog has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright year

Looks OK

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20938#pullrequestreview-2343086903

From duke at openjdk.org  Wed Oct  2 15:17:43 2024
From: duke at openjdk.org (duke)
Date: Wed, 2 Oct 2024 15:17:43 GMT
Subject: RFR: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile() [v3]
In-Reply-To: <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
 <mlp3-tciJREH90ev6VfM3sqE8fm0IXWvjtvoJxWYHPU=.a61f4db0-d3c8-43e9-9491-20a0691cc27d@github.com>
Message-ID: <lMQeTFuqE4YTjQIbu__-ERZbcCkmCUX8mGIApsjl5bM=.5a941e73-40aa-4fef-b9c0-d590f95b166f@github.com>

On Mon, 30 Sep 2024 16:11:14 GMT, sbgoog <duke at openjdk.org> wrote:

>> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.
>
> sbgoog has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright year

@sbgoog 
Your change (at version 2c0c18962ac4522e0da30286140e57f64eb41eb9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20938#issuecomment-2388942539

From bpb at openjdk.org  Wed Oct  2 15:23:52 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Oct 2024 15:23:52 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification [v3]
In-Reply-To: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
Message-ID: <gitZCSi8x_SzyIx3h_Qfazor6Jmw5aoROfCIqOr2ytg=.827fde65-6a2f-4ba6-a2a3-17cbe873aec7@github.com>

> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8340229: Correct typo in FIS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21223/files
  - new: https://git.openjdk.org/jdk/pull/21223/files/d345bce5..c03751d7

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

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

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

From bpb at openjdk.org  Wed Oct  2 15:23:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Oct 2024 15:23:53 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification [v2]
In-Reply-To: <qsnQerjkdIAzCUIGWwFPigsi5uP0yzCQRNSJ6podalI=.623720de-b2a7-45f1-a50b-5738ec3fe697@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <UetM6IVXP1D5fn9NGjJALDixrGPO51YjgW2bSEnvOF8=.c56af6e1-9ab7-4d85-9d20-53f6cf9abea8@github.com>
 <qsnQerjkdIAzCUIGWwFPigsi5uP0yzCQRNSJ6podalI=.623720de-b2a7-45f1-a50b-5738ec3fe697@github.com>
Message-ID: <B0mDuQo7O4kKV73Xs7VXQvz5RtYvKsGA9OFXrOioqBs=.2e93f2b0-191f-4de4-8fc7-5f3bb79a26b8@github.com>

On Wed, 2 Oct 2024 06:45:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8340229: Revert FIS(fdObj) change
>
> src/java.base/share/classes/java/io/FileInputStream.java line 118:
> 
>> 116:     /**
>> 117:      * Creates a {@code FileInputStream} to read from an existing file
>> 118:      * reoresented by the {@code File} object {@code file}.
> 
> Suggestion:
> 
>      * represented by the {@code File} object {@code file}.

Fixed in c03751d.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21223#discussion_r1784769072

From louisb at broadinstitute.org  Wed Oct  2 15:26:21 2024
From: louisb at broadinstitute.org (Louis Bergelson)
Date: Wed, 2 Oct 2024 11:26:21 -0400
Subject: Illegal Seek when using File.newInputStream()
Message-ID: <CALexLmGSxcF2k53cpVNX6nJc9=dOLwJac+hGBE3Ma1S0YADA+w@mail.gmail.com>

Hello,


There's a long standing bug when using Files.newInputStream() with unix
non-regular files.  (/dev/stdin , /dev/random/  etc).  It was reported in
JDK-8233451 <https://bugs.openjdk.org/browse/JDK-8233451> but it doesn't
seem like there's been much movement on it.  It's causing repeated problems
in our code base because it means reading from a piped input has to be
treated differently than reading from any other input.  We've made an
effort to move away from using File inputs and using Paths everywhere, but
this causes issues with that.


It's very easy to trigger:

InputStream inputStream = Files.*newInputStream*(Paths.*get*("/dev/stdin/"
));

inputStream.available();  // throws the following


java.io.IOException: Illegal seek

at java.base/sun.nio.ch.FileDispatcherImpl.seek0(Native Method)

at java.base/sun.nio.ch.FileDispatcherImpl.seek(FileDispatcherImpl.java:78)

at java.base/sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:344)

at
java.base/sun.nio.ch.ChannelInputStream.available(ChannelInputStream.java:114)


The relevant line is here in FileChannelImpl.position();


*   // in append-mode then position is advanced to end before writing*

   p = (append) ? nd.size(fd) : nd.seek(fd, -1);


Since the channel is an input it always has append == false which means it
always results in a call to  nd.seek(fd, -1)


This throws the Illegal Seek exception.  However, I believe this is not
ideal behavior, because a call to seek with a value of -1 should be
interpreted as a request for the current file position rather than a
request to seek.

>From seeks documentation:  "Sets or reports this file's position *If offset
is -1, the current position is returned *otherwise the position is set to
offset."


It seems like returning either 0, -1, or a count of the number of bytes
read from the channel so far would all be better behavior than throwing in
this case.

It should be noted that calling position() on this channel is immediately
fatal which is also extremely unexpected.


If changing that behavior isn't possible, it might make sense to have the
default file system provider for Files.newInputStream return a different
implementation when reading from a unix irregular file.   The mismatch
happens because it treating all files as seekable when they are strictly
not.


Is there any way to get this on the radar?  It's been a continuous source
of confusing errors in our codebase for years.


Thank you,

Louis Bergelson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241002/1b70a1e0/attachment.htm>

From alanb at openjdk.org  Wed Oct  2 15:27:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Oct 2024 15:27:35 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification [v3]
In-Reply-To: <gitZCSi8x_SzyIx3h_Qfazor6Jmw5aoROfCIqOr2ytg=.827fde65-6a2f-4ba6-a2a3-17cbe873aec7@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <gitZCSi8x_SzyIx3h_Qfazor6Jmw5aoROfCIqOr2ytg=.827fde65-6a2f-4ba6-a2a3-17cbe873aec7@github.com>
Message-ID: <pGW7AU4Zbm4jJCCs5wy3wXxxRlD87QScXacSYEGrRKc=.7273bf69-f110-4039-9b07-13ecc701f2d2@github.com>

On Wed, 2 Oct 2024 15:23:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8340229: Correct typo in FIS

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21223#pullrequestreview-2343319051

From duke at openjdk.org  Wed Oct  2 15:33:41 2024
From: duke at openjdk.org (sbgoog)
Date: Wed, 2 Oct 2024 15:33:41 GMT
Subject: Integrated: 8339850: Restore the interrupt status in
 FileSystemPreferences.lockFile()
In-Reply-To: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
References: <-MTPO2tMQMlhdH5xmtyzMTQX43EYHjAqjj1wp3eNTII=.c76e6fdf-a276-4937-a10b-fa26696bba1a@github.com>
Message-ID: <dLQ_mFyDuC30hjg7cyKNcBgeoL26yllnchEX-aBoGis=.b9ba8fbb-45b2-41c9-8d0f-5e7e8b7adf84@github.com>

On Tue, 10 Sep 2024 16:37:11 GMT, sbgoog <duke at openjdk.org> wrote:

> FIleSystemPreferences.lockFile() catches an InterruptedException and just returns false, forgetting to re-interrupt the current thread. This leaves the caller with no way to observe that the thread was interrupted. This change restores the interrupted status on the current thread before returning.

This pull request has now been integrated.

Changeset: 9fc1c684
Author:    Sorin Basca <sorinbasca at google.com>
Committer: Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fc1c684421043ac8df9ac7cd10fefd2a75e7a6b
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8339850: Restore the interrupt status in FileSystemPreferences.lockFile()

Reviewed-by: bpb, djelinski, vtewari

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

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

From ccheung at openjdk.org  Wed Oct  2 15:54:45 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 15:54:45 GMT
Subject: RFR: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time [v10]
In-Reply-To: <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
 <5AxrZkt3y_LP-2krG4WmONTrqA8diyZk1k1y_VoAsLs=.8ff3e9df-a93c-41be-a81c-a8982eccc984@github.com>
Message-ID: <fUGEG-WPTTWiBErPwR5J_NeQI6QViesWLilPIg53sgg=.d690f063-5181-4ef9-a228-46b51d2c43a9@github.com>

On Wed, 2 Oct 2024 05:50:14 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Prior to this patch, if `--module-path` is specified in the command line:
>> during CDS dump time, full module graph will not be included in the CDS archive;
>> during run time, full module graph will not be used.
>> 
>> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
>> 
>> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
>> E.g. the following is considered a match:
>> dump time      runtime
>> m1,m2             m2,m1
>> m1,m2             m1,m2,m2
>> 
>> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

Thanks Alan, David, Ioi for the reviews!
Also thanks Alan for your help on the core-libs changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/21048#issuecomment-2389023082

From ccheung at openjdk.org  Wed Oct  2 15:54:46 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 2 Oct 2024 15:54:46 GMT
Subject: Integrated: 8328313: Archived module graph should allow identical
 --module-path to be specified during dump time and run time
In-Reply-To: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
References: <vZl7cDuEGqgjJHAFkSnXT3Yuf-rcoFLJky7iu5wcBKY=.f8379b0a-972d-45f0-a779-7939272109df@github.com>
Message-ID: <Qz7p9oRxxi9zz0r6JpJMUxOFt48unbIsEM0MaZppe3g=.4273b65f-457c-4479-bd93-903627875c7d@github.com>

On Tue, 17 Sep 2024 23:44:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Prior to this patch, if `--module-path` is specified in the command line:
> during CDS dump time, full module graph will not be included in the CDS archive;
> during run time, full module graph will not be used.
> 
> With this patch, the full module graph will be included in the CDS archive with the `--module-path` option. During run time, if the same `--module-path` option is specified, the archived module graph will be used.
> 
> The checking of module paths between dump time and run time is more lenient compared with the checking of class paths; the ordering of the modules is unimportant, duplicate module names are ignored.
> E.g. the following is considered a match:
> dump time      runtime
> m1,m2             m2,m1
> m1,m2             m1,m2,m2
> 
> I included some [notes](https://bugs.openjdk.org/browse/JDK-8328313?focusedId=14699275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699275) in the bug report regarding some changes in the corelib classes.

This pull request has now been integrated.

Changeset: 0bdfe88e
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bdfe88e4c5d2f2364b07b803aae16ca0ba7b9d2
Stats:     600 lines in 19 files changed: 549 ins; 9 del; 42 mod

8328313: Archived module graph should allow identical --module-path to be specified during dump time and run time

Reviewed-by: alanb, dholmes, iklam

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

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

From duke at openjdk.org  Wed Oct  2 16:20:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 2 Oct 2024 16:20:36 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>

On Wed, 2 Oct 2024 10:31:09 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.

src/java.base/share/classes/java/math/BigDecimal.java line 2213:

> 2211: 
> 2212:                 BigDecimal working = new BigDecimal(this.intVal, this.intCompact, (int) workingScale, this.precision);
> 2213:                 BigInteger workingInt = working.toBigInteger();

@rgiulietti The cause of slow running time starts here: casting to `BigInteger` requires to multiply by a power of 10, and if the power of 10 is large, then the multiplication costs much time, as does computing the square root on the large resulting number.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1784848729

From duke at openjdk.org  Wed Oct  2 16:37:35 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 2 Oct 2024 16:37:35 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
Message-ID: <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>

On Wed, 2 Oct 2024 16:15:29 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.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 2213:
> 
>> 2211: 
>> 2212:                 BigDecimal working = new BigDecimal(this.intVal, this.intCompact, (int) workingScale, this.precision);
>> 2213:                 BigInteger workingInt = working.toBigInteger();
> 
> @rgiulietti The cause of slow running time starts here: casting to `BigInteger` requires to multiply by a power of 10, and if the power of 10 is large, then the multiplication costs much time, as does computing the square root of the large resulting number.

@rgiulietti The only solution I can think of to avoid this is to reimplement Zimmerman's square root algorithm in the class `BigDecimal`, using the radix 10 representation of the number's magnitude.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1784873510

From duke at openjdk.org  Wed Oct  2 16:45:35 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 2 Oct 2024 16:45:35 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <IS8RKT9AcGJuhjLtW9XSOjBjXZYH8RKc14k8RbjILH8=.44639722-5970-428a-bc37-114f66d2887d@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <IS8RKT9AcGJuhjLtW9XSOjBjXZYH8RKc14k8RbjILH8=.44639722-5970-428a-bc37-114f66d2887d@github.com>
Message-ID: <4-8HmTeqt_jAN7gxmZQ02rCDnpaFY3mkbLq0ZXE_HQA=.57062632-7331-417a-8870-435f648170f7@github.com>

On Wed, 2 Oct 2024 13:44:42 GMT, Raffaello Giulietti <rgiulietti 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.

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2389131197

From rgiulietti at openjdk.org  Wed Oct  2 17:39:35 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 2 Oct 2024 17:39:35 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
Message-ID: <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>

On Wed, 2 Oct 2024 16:32:47 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 2213:
>> 
>>> 2211: 
>>> 2212:                 BigDecimal working = new BigDecimal(this.intVal, this.intCompact, (int) workingScale, this.precision);
>>> 2213:                 BigInteger workingInt = working.toBigInteger();
>> 
>> @rgiulietti The cause of slow running time starts here: casting to `BigInteger` requires to multiply by a power of 10, and if the power of 10 is large, then the multiplication costs much time, as does computing the square root of the large resulting number.
>
> @rgiulietti The only solution I can think of to avoid this is to reimplement Zimmerman's square root algorithm in the class `BigDecimal`, using the radix 10 representation of the number's magnitude.

After looking at the code more closely, these are _not_ the reasons for the long running times of my example above.
Neither the computation of the large power of 10, nor the multiplication, nor the `BigInteger` square root are slow.

The slowdown in my example of sqrt(121) above comes from the call to `stripZerosToMatchScale()`, which performs about a million divisions by 10 to meet the preferred scale.

In fact, when there are no trailing zeros in the result, the running times are very fast.
Replacing 121 (an exact square) with 122 in the example above reduces the time to less than 1 s rather than more than 3 min, because there are no trailing zeros to get rid of:
`BigDecimal.valueOf(121).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN))` more than 3 min
`BigDecimal.valueOf(122).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN))` less than 1 s

Of course, this is not the fault of `BigDecimal.sqrt()`, but of the way `stripZerosToMatchScale()` is implemented. Maybe the topic of your next PR ;-) ? Might be hard, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1784953613

From duke at openjdk.org  Wed Oct  2 18:09:37 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 2 Oct 2024 18:09:37 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
Message-ID: <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>

On Wed, 2 Oct 2024 17:37:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti The only solution I can think of to avoid this is to reimplement Zimmerman's square root algorithm in the class `BigDecimal`, using the radix 10 representation of the number's magnitude.
>
> After looking at the code more closely, these are _not_ the reasons for the long running times of my example above.
> Neither the computation of the large power of 10, nor the multiplication, nor the `BigInteger` square root are slow.
> 
> The slowdown in my example of sqrt(121) above comes from the call to `stripZerosToMatchScale()`, which performs about a million divisions by 10 to meet the preferred scale.
> 
> In fact, when there are no trailing zeros in the result, the running times are very fast.
> Replacing 121 (an exact square) with 122 in the example above reduces the time to less than 1 s rather than more than 3 min, because there are no trailing zeros to get rid of:
> `BigDecimal.valueOf(121).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN))` more than 3 min
> `BigDecimal.valueOf(122).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN))` less than 1 s
> 
> Of course, this is not the fault of `BigDecimal.sqrt()`, but of the way `stripZerosToMatchScale()` is implemented. Maybe the topic of your next PR ;-) ? Might be hard, though.

A possible faster implementation of `stripZerosToMatchScale()` could be based on dividing by increasing powers of 10 whose exponent doubles at each step (a kind of repeated squares trick), although the asymptotic running time would still be exponential.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1785005083

From rgiulietti at openjdk.org  Wed Oct  2 18:18:34 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 2 Oct 2024 18:18:34 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
 <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
Message-ID: <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>

On Wed, 2 Oct 2024 18:06:57 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> After looking at the code more closely, these are _not_ the reasons for the long running times of my example above.
>> Neither the computation of the large power of 10, nor the multiplication, nor the `BigInteger` square root are slow.
>> 
>> The slowdown in my example of sqrt(121) above comes from the call to `stripZerosToMatchScale()`, which performs about a million divisions by 10 to meet the preferred scale.
>> 
>> In fact, when there are no trailing zeros in the result, the running times are very fast.
>> Replacing 121 (an exact square) with 122 in the example above reduces the time to less than 1 s rather than more than 3 min, because there are no trailing zeros to get rid of:
>> `BigDecimal.valueOf(121).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN))` more than 3 min
>> `BigDecimal.valueOf(122).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN))` less than 1 s
>> 
>> Of course, this is not the fault of `BigDecimal.sqrt()`, but of the way `stripZerosToMatchScale()` is implemented. Maybe the topic of your next PR ;-) ? Might be hard, though.
>
> A possible faster implementation of `stripZerosToMatchScale()` could be based on dividing by increasing powers of 10 whose exponent doubles at each step (a kind of repeated squares trick), although the asymptotic running time would still be exponential.

Without experimenting a bit, it's hard to tell.
Anyway, I believe the current implementation of `stripZerosToMatchScale()` is O(n^2) rather than exponential, because each single division by 10 is linear.

But let's focus on `sqrt()` in this PR and leave `stripZerosToMatchScale()` for another time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1785026756

From alan.bateman at oracle.com  Wed Oct  2 18:30:48 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 2 Oct 2024 19:30:48 +0100
Subject: Illegal Seek when using File.newInputStream()
In-Reply-To: <CALexLmGSxcF2k53cpVNX6nJc9=dOLwJac+hGBE3Ma1S0YADA+w@mail.gmail.com>
References: <CALexLmGSxcF2k53cpVNX6nJc9=dOLwJac+hGBE3Ma1S0YADA+w@mail.gmail.com>
Message-ID: <5deb045d-1362-485d-a8d3-5cd9f4c6c8ec@oracle.com>


The InputStream created over the FileChannel assumes that the 
FileChannel is connected to a regular file, which isn't the case with 
this character special file and several other pseudo devices. As you've 
found, many of the methods defined by FileChannel doesn't make sense 
with these devices. This one is fixable with a special side channel to 
to FCI to support the available method, just hasn't been a priority as 
the. issue has always existed.

-Alan


On 02/10/2024 16:26, Louis Bergelson wrote:
>
> Hello,
>
>
> There's a long standing bug when using Files.newInputStream() with 
> unix non-regular files.? (/dev/stdin , /dev/random/? etc).? It was 
> reported in JDK-8233451 
> <https://bugs.openjdk.org/browse/JDK-8233451>?but it doesn't seem like 
> there's been much movement on it.? It's causing repeated?problems in 
> our code base because it means reading from a piped input has to be 
> treated differently than reading from any other input.? We've made an 
> effort to move away from using File inputs and using Paths everywhere, 
> but this causes issues?with that.
>
>
> It's very easy to trigger:
>
> InputStream inputStream = 
> Files./newInputStream/(Paths./get/("/dev/stdin/"));
>
> inputStream.available();// throws the following
>
>
> java.io.IOException: Illegal seek
>
> at java.base/sun.nio.ch.FileDispatcherImpl.seek0(Native Method)
>
> at 
> java.base/sun.nio.ch.FileDispatcherImpl.seek(FileDispatcherImpl.java:78)
>
> at java.base/sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:344)
>
> at 
> java.base/sun.nio.ch.ChannelInputStream.available(ChannelInputStream.java:114)
>
>
> The relevant line is here in?FileChannelImpl.position();
>
>
> /? ?// in append-mode then position is advanced to end before writing/
>
> ? ?p = (append) ? nd.size(fd) : nd.seek(fd, -1);
>
>
> Since the channel is an input it always has append == false which 
> means it always results in a call tond.seek(fd, -1)
>
>
> This throws the Illegal Seek exception.However, I believe this is not 
> ideal behavior, because a call to seek with a value of -1 should be 
> interpreted as a request for the current file position rather than a 
> request to seek.
>
> From seeksdocumentation:? "Sets or reports this file's position *If 
> offset is -1, the current position is returned *otherwise the position 
> is set to offset."
>
>
> It seems like returning either 0, -1, or a count of the number of 
> bytes read from the channel so far would all be better behavior than 
> throwing in this case.
>
> It should be noted that calling position() on this channel is 
> immediately fatal which is also extremely unexpected.
>
>
> If changing that behavior isn't possible, it might make sense to have 
> the default file system provider for Files.newInputStream return a 
> different implementation when reading from a unix irregular file.? 
> ?The mismatch happens because it treating all files as seekable when 
> they are strictly not.
>
>
> Is there any way to get this on the radar?It's been a continuous 
> source of confusing errors in our codebase for years.
>
>
> Thank you,
>
> Louis Bergelson
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241002/62e4cc33/attachment-0001.htm>

From vlivanov at openjdk.org  Wed Oct  2 18:34:45 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 2 Oct 2024 18:34:45 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v6]
In-Reply-To: <Ut7bbNPxK59v3Gm-DIPJtHEP4KeOOaDqh9QEtJt5r3k=.7780611a-1759-499f-acc9-925b2f56c369@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <Ut7bbNPxK59v3Gm-DIPJtHEP4KeOOaDqh9QEtJt5r3k=.7780611a-1759-499f-acc9-925b2f56c369@github.com>
Message-ID: <pMVPtRR4g0OhMlDmCJRzfyJcvT-g4K_svwnpl-ok_4E=.f9d076c1-ad11-4ae3-9897-4a5472ea0b21@github.com>

On Thu, 19 Sep 2024 12:20:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - use resolve_global_jobject on s390
>  - Merge branch 'master' into LoadVMTraget
>  - remove PC save/restore on s390
>  - use fatal()
>  - add RISC-V as target platform
>  - Adjust ppc & RISC-V code
>  - Add s390 changes
>  - Merge branch 'master' into LoadVMTraget
>  - Don't save/restore LR/CR + resolve_jobject on s390
>  - eyeball other platforms
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/2faf8b8d...b703b162

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20479#pullrequestreview-2343806028

From duke at openjdk.org  Wed Oct  2 18:35:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 2 Oct 2024 18:35:36 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
 <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
 <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
Message-ID: <8hrkKQNJ8YOMJsO8pON7v8kiFOqDLklV667WU9HfZrc=.86f9bef7-2ec6-4847-92ce-a315c275ad28@github.com>

On Wed, 2 Oct 2024 18:16:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Without experimenting a bit, it's hard to tell. Anyway, I believe the current implementation of `stripZerosToMatchScale()` is O(n^2) rather than exponential, because each single division by 10 is linear.
> 
> But let's focus on `sqrt()` in this PR and leave `stripZerosToMatchScale()` for another time.

Yes, it is linear, but in the length of the magnitude, while it is exponential in the length of the precision... (`1_000_000` of divisions for a precision of 7 digits)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1785059976

From jvernee at openjdk.org  Wed Oct  2 18:58:44 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Oct 2024 18:58:44 GMT
Subject: RFR: 8337753: Target class of upcall stub may be unloaded [v6]
In-Reply-To: <Ut7bbNPxK59v3Gm-DIPJtHEP4KeOOaDqh9QEtJt5r3k=.7780611a-1759-499f-acc9-925b2f56c369@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
 <Ut7bbNPxK59v3Gm-DIPJtHEP4KeOOaDqh9QEtJt5r3k=.7780611a-1759-499f-acc9-925b2f56c369@github.com>
Message-ID: <E9mCyfQfrHAYt2hEKoXLElopySqi9G1KkvD9ceW2fWo=.d96cb090-756d-4730-b7f6-5edd96d314b1@github.com>

On Thu, 19 Sep 2024 12:20:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> As discussed in the JBS issue:
>> 
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
>> 
>> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
>> 
>> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
>> 
>> <details>
>> <summary>Performance numbers</summary>
>> x64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
>> 
>> 
>> aarch64:
>> 
>> before:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
>> 
>> 
>> after:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
>> 
>> </details>
>> 
>> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
>> 
>> Testing: tier 1-4
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - use resolve_global_jobject on s390
>  - Merge branch 'master' into LoadVMTraget
>  - remove PC save/restore on s390
>  - use fatal()
>  - add RISC-V as target platform
>  - Adjust ppc & RISC-V code
>  - Add s390 changes
>  - Merge branch 'master' into LoadVMTraget
>  - Don't save/restore LR/CR + resolve_jobject on s390
>  - eyeball other platforms
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/2faf8b8d...b703b162

Thanks for all the reviews! I will do one more round of testing before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/20479#issuecomment-2389467122

From duke at openjdk.org  Wed Oct  2 20:01:36 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 2 Oct 2024 20:01:36 GMT
Subject: RFR: 8341415: Optimize RawBytecodeHelper::next
In-Reply-To: <bDF2MYoCu3u_ZUVornyj1xoCQ2RPxCmJrkp4BD08hhA=.c3c545cf-6ff7-4cca-bc5c-cef6ae5e492d@github.com>
References: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
 <vzpcD7R5Iu3_egyqZhb2W1sCi2usgQH1mq6fdRuT9QI=.65de2b13-fa74-4bcd-8327-f86c8ea4f29e@github.com>
 <bDF2MYoCu3u_ZUVornyj1xoCQ2RPxCmJrkp4BD08hhA=.c3c545cf-6ff7-4cca-bc5c-cef6ae5e492d@github.com>
Message-ID: <Z0eai5z0I7WiD0TiCRkWa66eFu4TiKcgwxMlcYT15JI=.9f60f716-542c-4650-a7ab-642f5cfb488b@github.com>

On Wed, 2 Oct 2024 13:29:22 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java line 449:
>> 
>>> 447:         }
>>> 448: 
>>> 449:         if ((nextBci += len) > end) {
>> 
>> This?change makes?it?that `nextBci` will?no?longer monotonically increase in?case of?a?malformed special?instruction.
>> 
>> Suggestion:
>> 
>>         if (len <= 0 || (nextBci += len) > end) {
>
> The checkSpecialInstruction has already added the 'len <= 0' process, so there is no need to check 'len <= '0' again.

`checkSpecialInstruction` will?return?`-1` in?the?following?cases:
* `code == WIDE` and `bci + 1 >= end`
* `code == TABLESWITCH` and `align(bci + 1) + 3 * 4 >= end`
* `code == LOOKUPSWITCH` and
  * `align(bci + 1) + 2 * 4 >= end`
  * or `npairs` is out of range

Which?will?cause `nextBci` to?be?decremented in?those?cases in?the?proposed?implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21300#discussion_r1785154110

From duke at openjdk.org  Wed Oct  2 20:02:41 2024
From: duke at openjdk.org (Luca Kellermann)
Date: Wed, 2 Oct 2024 20:02:41 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v9]
In-Reply-To: <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
Message-ID: <1z6p_WlO9R1dgc-H29ZjuewTZm04jg-d3YX4is0F8C4=.4405cf0d-484d-4ccc-8022-a37284142545@github.com>

On Tue, 24 Sep 2024 17:23:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
>> 
>> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
>> 
>> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AbstractPoolEntry is broken too

src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 482:

> 480:      * describe the possible return values of this method.
> 481:      */
> 482:     char tag();

Why is the type of the constants different from the return type of this function?

src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java line 104:

> 102:      * describe the possible return values of this method.
> 103:      */
> 104:     byte tag();

The same question applies here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1785109411
PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1785114283

From duke at openjdk.org  Wed Oct  2 20:16:39 2024
From: duke at openjdk.org (fitzsim)
Date: Wed, 2 Oct 2024 20:16:39 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: <xMMOUqBJzbseFcoQv9bzpz2CTnDONHFcDo5ElNU_t4E=.b5ebefbc-f644-4358-8b26-26a13241bb7c@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 (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.

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

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2389597190

From liach at openjdk.org  Wed Oct  2 20:27:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Oct 2024 20:27:41 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v9]
In-Reply-To: <1z6p_WlO9R1dgc-H29ZjuewTZm04jg-d3YX4is0F8C4=.4405cf0d-484d-4ccc-8022-a37284142545@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
 <1z6p_WlO9R1dgc-H29ZjuewTZm04jg-d3YX4is0F8C4=.4405cf0d-484d-4ccc-8022-a37284142545@github.com>
Message-ID: <8O4cLBgiKtvDB-LbpkdsMs-9DwrQ8i4_Vv9cVOZ7A7g=.46886782-6549-4095-912d-e66872d67d17@github.com>

On Wed, 2 Oct 2024 19:16:08 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   AbstractPoolEntry is broken too
>
> src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 482:
> 
>> 480:      * describe the possible return values of this method.
>> 481:      */
>> 482:     char tag();
> 
> Why is the type of the constants different from the return type of this function?

First, some bit of history. These API methods are added before those constants, and this patch did not change the type of these methods or constants.

I believe the methods have restricted return types to be informative: `tag()` is a U1, but it can be interpreted as a char (see [JVMS 4.7.16.1](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) and thus is returned as one. CP tag is a U1 too (see [JVMS 4.4](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) so maybe `byte` is just used out of convenience.

However, we usually use `int` to represent U1, also called unsigned bytes. See [`DataInput::readUnsignedByte`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/io/DataInput.java#L323) and [`ClassReader::readU1`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/lang/classfile/ClassReader.java#L133). Guess that's why we used `int` for the constants. (Also, note that byte and char are all [erased to int](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/classfile/TypeKind.html#computational-type) in bytecode, so this has little practical effect and that might be why I didn't bother to change these)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1785208822

From liach at openjdk.org  Wed Oct  2 20:31:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Oct 2024 20:31:34 GMT
Subject: RFR: 8341415: Optimize RawBytecodeHelper::next
In-Reply-To: <Z0eai5z0I7WiD0TiCRkWa66eFu4TiKcgwxMlcYT15JI=.9f60f716-542c-4650-a7ab-642f5cfb488b@github.com>
References: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
 <vzpcD7R5Iu3_egyqZhb2W1sCi2usgQH1mq6fdRuT9QI=.65de2b13-fa74-4bcd-8327-f86c8ea4f29e@github.com>
 <bDF2MYoCu3u_ZUVornyj1xoCQ2RPxCmJrkp4BD08hhA=.c3c545cf-6ff7-4cca-bc5c-cef6ae5e492d@github.com>
 <Z0eai5z0I7WiD0TiCRkWa66eFu4TiKcgwxMlcYT15JI=.9f60f716-542c-4650-a7ab-642f5cfb488b@github.com>
Message-ID: <tGMsS8X6rpFWget8ONugjg9sfWxJOmToBAEhZFwdo0Q=.6e79ea2a-7463-4be2-9362-667c1f5a650e@github.com>

On Wed, 2 Oct 2024 19:59:07 GMT, ExE Boss <duke at openjdk.org> wrote:

>> The checkSpecialInstruction has already added the 'len <= 0' process, so there is no need to check 'len <= '0' again.
>
> `checkSpecialInstruction` will?return?`-1` in?the?following?cases:
> * `code == WIDE` and `bci + 1 >= end`
> * `code == TABLESWITCH` and `align(bci + 1) + 3 * 4 >= end`
> * `code == LOOKUPSWITCH` and
>   * `align(bci + 1) + 2 * 4 >= end`
>   * or `npairs` is out of range
> 
> Which?will?cause `nextBci` to?be?decremented in?those?cases in?the?proposed?implementation.

`nextBci` is used only if we proceed. I believe none of the use sites processing untrusted bytecode (including verification but excluding stack map generation) proceeds when it receives an `INVALID` result, so change to `nextBci` in that case has no impact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21300#discussion_r1785213182

From dholmes at openjdk.org  Wed Oct  2 20:31:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 20:31:36 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]
In-Reply-To: <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
Message-ID: <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>

On Tue, 1 Oct 2024 13:45:56 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ubsan changes from jni_md.h

jni_util.h is used across all modules but it is located in `java.base/share/native/libjava` not `java.base/unix/native/libjava`. 

I think you could probably place ub.h along-side jni_util.h in that directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2389640145

From almatvee at openjdk.org  Wed Oct  2 20:37:45 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 2 Oct 2024 20:37:45 GMT
Subject: RFR: 8341443: [macos] AppContentTest and SigningOptionsTest failed due
 to "codesign" does not fails with "--app-content" on macOS 15
Message-ID: <hju35Q4minf8idhGVHExjUethcw84gj0taEC4rBgKp0=.89a83513-53f6-411e-9579-1747b75e042c@github.com>

- `AppContentTest` and `SigningOptionsTest` failed on macOS 15 due to `codesign` no longer fails if additional content is added to app image.
- `SigningOptionsTest` fixed by failing `codesign` due to missing identity, since we only need to check that warning message is displayed when codesign fails and `--app-content` is specified.
- `AppContentTest` is fixed by setting expected exit code based on macOS version.

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

Commit messages:
 - 8341443: [macos] AppContentTest and SigningOptionsTest failed due to "codesign" does not fails with "--app-content" on macOS 15

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

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

From asemenyuk at openjdk.org  Wed Oct  2 20:45:36 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 2 Oct 2024 20:45:36 GMT
Subject: RFR: 8341443: [macos] AppContentTest and SigningOptionsTest failed
 due to "codesign" does not fails with "--app-content" on macOS 15
In-Reply-To: <hju35Q4minf8idhGVHExjUethcw84gj0taEC4rBgKp0=.89a83513-53f6-411e-9579-1747b75e042c@github.com>
References: <hju35Q4minf8idhGVHExjUethcw84gj0taEC4rBgKp0=.89a83513-53f6-411e-9579-1747b75e042c@github.com>
Message-ID: <ixkSZc5UfMHHpQq_jH4_6j8MA2j4s5BxyBzVPLJza8w=.638de578-e75b-4c2c-bd42-f4d5ac908703@github.com>

On Wed, 2 Oct 2024 20:32:57 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - `AppContentTest` and `SigningOptionsTest` failed on macOS 15 due to `codesign` no longer fails if additional content is added to app image.
> - `SigningOptionsTest` fixed by failing `codesign` due to missing identity, since we only need to check that warning message is displayed when codesign fails and `--app-content` is specified.
> - `AppContentTest` is fixed by setting expected exit code based on macOS version.

Marked as reviewed by asemenyuk (Reviewer).

Looks good

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

PR Review: https://git.openjdk.org/jdk/pull/21313#pullrequestreview-2344071580
PR Comment: https://git.openjdk.org/jdk/pull/21313#issuecomment-2389662348

From louisb at broadinstitute.org  Wed Oct  2 20:48:30 2024
From: louisb at broadinstitute.org (Louis Bergelson)
Date: Wed, 2 Oct 2024 16:48:30 -0400
Subject: Illegal Seek when using File.newInputStream()
In-Reply-To: <5deb045d-1362-485d-a8d3-5cd9f4c6c8ec@oracle.com>
References: <CALexLmGSxcF2k53cpVNX6nJc9=dOLwJac+hGBE3Ma1S0YADA+w@mail.gmail.com>
 <5deb045d-1362-485d-a8d3-5cd9f4c6c8ec@oracle.com>
Message-ID: <CALexLmGPB1sNfdFd4md7aNwYx3Byc+-DPHTikkk3hmHxWdoxCg@mail.gmail.com>

If I wanted to contribute a patch, can you suggest what you think would be
the best path forward?

I've listed some options but I'm sure there are more:

1.    It seems like amending the underlying issue in the native code
underlying FileDispatcherImpl.seek() so that it returns a value when asked
for the position in the file instead of crashing would be the most durable
fix.  That seems like possibly the most complex though since it's in the
native code which I am not very familiar with.

2.  Another possibility would be to modify FileChannelImpl.position() to
return a value instead of throwing.  This would fix multiple issues ,for
instance it's very possible that the returned InputStream from
Files.newInputStream is at some point re-wrapped into a channel, and then
benign looking calls to position() fail.
ex:

FileInputStream in = new FileInputStream("/dev/stdin");
FileChannel channel = in.getChannel();
channel.position(); // throws

3.  Modify the available method on ChannelInputStream to return 0 in this
case.

4.  Modify the FileSystemProviders to return a different sort of
InputStream if the underlying file isn't actually seekable.  You could for
instance override it in UnixFilesSystem.

Thank you.  I would love to help fix this problem.
Louis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241002/eb4c79a0/attachment-0001.htm>

From brian.burkhalter at oracle.com  Wed Oct  2 21:37:31 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Oct 2024 21:37:31 +0000
Subject: Illegal Seek when using File.newInputStream()
In-Reply-To: <CALexLmGPB1sNfdFd4md7aNwYx3Byc+-DPHTikkk3hmHxWdoxCg@mail.gmail.com>
References: <CALexLmGSxcF2k53cpVNX6nJc9=dOLwJac+hGBE3Ma1S0YADA+w@mail.gmail.com>
 <5deb045d-1362-485d-a8d3-5cd9f4c6c8ec@oracle.com>
 <CALexLmGPB1sNfdFd4md7aNwYx3Byc+-DPHTikkk3hmHxWdoxCg@mail.gmail.com>
Message-ID: <B7B855AC-56A9-48A7-9E51-8CE9194998BC@oracle.com>

Hi Louis,

I have a  functional patch implemented. It adds available() to FileChannelImpl which then uses it if the SeekableByteChannel is a FileChannelImpl. The patch only had the UNIX changes for now; I?ve not investigated Windows enough to know what to do there.

Does that sound reasonable?

Thanks,

Brian

On Oct 2, 2024, at 1:48?PM, Louis Bergelson <louisb at broadinstitute.org> wrote:

3.  Modify the available method on ChannelInputStream to return 0 in this case.


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

From duke at openjdk.org  Wed Oct  2 22:10:41 2024
From: duke at openjdk.org (duke)
Date: Wed, 2 Oct 2024 22:10:41 GMT
Subject: Withdrawn: 8337838: Remove unused methods from ChronoLocalDateImpl
In-Reply-To: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
References: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
Message-ID: <xW6r8yd_hnSazgHjGBKjaIdRp8iADZlNl2a848ZrqfU=.623c3a9c-0ef4-495e-a3c9-7e588978fb95@github.com>

On Fri, 19 Jul 2024 09:52:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few methods in `java.time.chrono.ChronoLocalDateImpl` are unused and could be removed:
> 1. plusWeeks(long)
> 2. minusYears(long)
> 3. minusMonths(long)
> 4. minusWeeks(long)
> 5. minusDays(long)
> 
> Tested `test/jdk/java/time` on Linux x64 release

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Wed Oct  2 22:18:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Oct 2024 22:18:34 GMT
Subject: RFR: 8341415: Optimize RawBytecodeHelper::next
In-Reply-To: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
References: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
Message-ID: <1eUqPQRkIzI1IbukmPj-A5bRDq6uSpIDeCc6TSzJw78=.a603cda0-045b-4eea-a273-3db035eca149@github.com>

On Wed, 2 Oct 2024 07:53:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to the RawBytecodeHelper::next method
> * Remove `len <= 0` once
> * merge store opcode and isWide

Marked as reviewed by liach (Reviewer).

This patch is neutral for startup benchmark. Good if it improves the repeated JMH benchmarks.

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

PR Review: https://git.openjdk.org/jdk/pull/21300#pullrequestreview-2344188871
PR Comment: https://git.openjdk.org/jdk/pull/21300#issuecomment-2389783496

From vlivanov at openjdk.org  Wed Oct  2 23:14:37 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 2 Oct 2024 23:14:37 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v7]
In-Reply-To: <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>
Message-ID: <yvJd3RW9yaLG_JKkwISGAIk7IrN67Ah-JgSnxjdQJE4=.4ed0e67a-0e63-48d1-94bc-bc8f0747aa23@github.com>

On Wed, 2 Oct 2024 01:06:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/bad1f0b3...1b067b7b

Overall, looks good.

src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java line 92:

> 90:         CUSTOMIZE_THRESHOLD = Integer.parseInt(
> 91:                 props.getProperty("java.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD", "127"));
> 92:         NO_SOFT_CACHE = CDS.disableMethodHandleSoftCache();

I suggest to use `CDS.disableMethodHandleSoftCache()` as the default and allow to override the mode through a property.


NO_SOFT_CACHE = Boolean.parseBoolean( 
        props.getProperty("java.lang.invoke.MethodHandle.NO_SOFT_CACHE", 
                                        Boolean.toString(CDS.disableMethodHandleSoftCache()));

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21049#pullrequestreview-2344311986
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1785372914

From psandoz at openjdk.org  Wed Oct  2 23:17:35 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 2 Oct 2024 23:17:35 GMT
Subject: RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline [v5]
In-Reply-To: <nkFSZWJ4JuhfUYy2ZVSDTj9vb9Tg0KM4AkDFVSOuji0=.c81bd431-3b9b-4af6-ac6b-17e56c067e17@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
 <nkFSZWJ4JuhfUYy2ZVSDTj9vb9Tg0KM4AkDFVSOuji0=.c81bd431-3b9b-4af6-ac6b-17e56c067e17@github.com>
Message-ID: <S_dFn_SEZNVGYf5HZEeIcneR8wwh4Z32nkXuyw7mUTE=.cb9ecf89-b11f-43d2-9cda-7bb7bcdb4a31@github.com>

On Wed, 2 Oct 2024 14:02:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some round of adaptation.
>> Adapting a var handle results in a so called *indirect* var handle.
>> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
>> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
>> 
>> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
>> 
>> This problem was originally reported here:
>> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
>> 
>> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
>> 
>> 
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
>> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
>> 
>> 
>> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add `@ForceInline` to `MethodHandle::asType`, as per review comment

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21283#pullrequestreview-2344326430

From jlu at openjdk.org  Wed Oct  2 23:20:50 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 2 Oct 2024 23:20:50 GMT
Subject: RFR: 8341445: DecimalFormatSymbols can throw NPE for equals()
Message-ID: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>

Please review this PR which improves the safety of equality checking for DecimalFormatSymbols.

DecimalFormatSymbols via its setters, allows certain instance variables to be set as null. (Note that some variables are allowed to be null, and others are not.) However, non null safe comparisons are used for all variables during the equality check. This can lead to an unexpected NPE when `DecimalFormatSymbols.equals()` is invoked.

The nullable variables in question should be equality checked via the static `Object.equals()`. An associated regression test is added to confirm the change.

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

Commit messages:
 - small shortening of MethodSource
 - init

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

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

From msheppar at openjdk.org  Wed Oct  2 23:36:36 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 2 Oct 2024 23:36:36 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v8]
In-Reply-To: <hmROxxv_l2UIyTn5vnB_PvPo7ibiP-Jl5hUrdqqKjWc=.8851f833-6066-4c4e-8957-ac9299a195c9@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <6J--IvJLc0NGwNkQvjHimAGx2X1Q9Yj_8eLtlGcTpjg=.5d97197e-213f-45be-8440-5d6d332466f3@github.com>
 <uk0JI1cKrg6jWecOzS6Ysmk-4GJ_nI8dcInmd5cxhqU=.cc6865cd-46a4-4ab1-a52c-0e2eaa8acade@github.com>
 <hmROxxv_l2UIyTn5vnB_PvPo7ibiP-Jl5hUrdqqKjWc=.8851f833-6066-4c4e-8957-ac9299a195c9@github.com>
Message-ID: <0HsA2BK7z2A73gzxmtafEmf3STfMlts_DM7-jQkoaoI=.60ae83f1-ba8c-42da-b726-038a1d9b2bd2@github.com>

On Wed, 2 Oct 2024 13:25:54 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> > I think that if there is a PortUnreachable thrown, during DnsClient.query processing from the doUdpQuery, then the timeout may expire early ... if I've interpreted the outer loop processing correctly
> 
> The `DnsClient.query` marks server as misconfigured (not suitable for further retries) in scenarios when `PortUnreachable` is caught (see `doNotRetry`). And since the timeout/retries are specified per server it is expected for the timeout to expire early. For scenarios with one server and `PortUnreachable` exception - the `DnsClient.query` will throw the `CommunicationException` with `PortUnreachable` set as its cause.

Here's two set of trace (pre your current change) for the main Timeout test. The second trace is a simulated receipt of an ICMP Host unreachable

normal successful execution of Timeout test

----------System.out:(19/715)----------
Skip local DNS Server creation 
DnsClient.query retry == 0
DnsClient.doUdpQuery pktTimeout == 250
DnsClient.blockingReceive: select with timeout == 250
DnsClient.query retry == 1
DnsClient.doUdpQuery pktTimeout == 500
DnsClient.blockingReceive: select with timeout == 500
DnsClient.query retry == 2
DnsClient.doUdpQuery pktTimeout == 1000
DnsClient.blockingReceive: select with timeout == 1000
DnsClient.query retry == 3
DnsClient.doUdpQuery pktTimeout == 2000
DnsClient.blockingReceive: select with timeout == 2000
DnsClient.query retry == 4
DnsClient.doUdpQuery pktTimeout == 4000
DnsClient.blockingReceive: select with timeout == 4000
Elapsed (ms):  7793
Expected (ms): 7750
elapsed time is as long as expected.
----------System.err:(18/768)----------
DNS: SEND ID (1): 29440
DNS: Trying RECEIVE(1) retry(1) for:29440    sock-timeout:250 ms.
DNS: Caught IOException:java.net.SocketTimeoutException
DNS: SEND ID (2): 29440
DNS: Trying RECEIVE(1) retry(2) for:29440    sock-timeout:500 ms.
DNS: Caught IOException:java.net.SocketTimeoutException
DNS: SEND ID (3): 29440
DNS: Trying RECEIVE(1) retry(3) for:29440    sock-timeout:1000 ms.
DNS: Caught IOException:java.net.SocketTimeoutException
DNS: SEND ID (4): 29440
DNS: Trying RECEIVE(1) retry(4) for:29440    sock-timeout:2000 ms.
DNS: Caught IOException:java.net.SocketTimeoutException
DNS: SEND ID (5): 29440
DNS: Trying RECEIVE(1) retry(5) for:29440    sock-timeout:4000 ms.
DNS: Caught IOException:java.net.SocketTimeoutException

--------------oOo----------------
timeout failure due to PortUnreachableException

----------System.out:(12/392)----------
Skip local DNS Server creation 
DnsClient.query retry == 0
DnsClient.doUdpQuery pktTimeout == 250
DnsClient.blockingReceive: select with timeout == 250
DnsClient.query retry == 1
DnsClient.doUdpQuery pktTimeout == 500
DnsClient.blockingReceive: select with timeout == 500
DnsClient.query retry == 2
DnsClient.query retry == 3
DnsClient.query retry == 4
Elapsed (ms):  777
Expected (ms): 7750
----------System.err:(21/1055)----------
DNS: SEND ID (1): 27504
DNS: Trying RECEIVE(1) retry(1) for:27504    sock-timeout:250 ms.
DNS: Caught IOException:java.net.SocketTimeoutException
DNS: SEND ID (2): 27504
DNS: Trying RECEIVE(1) retry(2) for:27504    sock-timeout:500 ms.
DNS: Caught IOException:java.net.SocketTimeoutException
DNS: SEND ID (3): 27504
DNS: Caught Exception:java.net.PortUnreachableException: simulated ICMP Host unreachable
java.lang.RuntimeException: Failed: timeout in 777 ms, expected7750ms
	at Timeout.handleException(Timeout.java:116)
	at TestBase.launch(TestBase.java:84)
	at TestBase.run(TestBase.java:50)
	at Timeout.main(Timeout.java:59)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:588)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed: timeout in 777 ms, expected7750ms


test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Failed: timeout in 777 ms, expected7750ms


So if a PortUnreachableException is thrown, which can happen for either a send or receive anytime after the first iteration through the retry loop, then there will be an early timeout. As such, your assertion does not appear to be true.

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

PR Comment: https://git.openjdk.org/jdk/pull/20892#issuecomment-2389979568

From duke at openjdk.org  Thu Oct  3 00:05:17 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 00:05:17 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <bg7EvWF1v6Kf-V8R3T-tYvNpXeHhxGs2_NbRSik8bdY=.110f3117-7eea-4b47-b23e-c5bd3a0105eb@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:

  Removed stripZerosToEvenScale to simplify the code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/e708a445..129f79ff

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

  Stats: 93 lines in 1 file changed: 8 ins; 78 del; 7 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 darcy at openjdk.org  Thu Oct  3 00:49:52 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 3 Oct 2024 00:49:52 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <bg7EvWF1v6Kf-V8R3T-tYvNpXeHhxGs2_NbRSik8bdY=.110f3117-7eea-4b47-b23e-c5bd3a0105eb@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <bg7EvWF1v6Kf-V8R3T-tYvNpXeHhxGs2_NbRSik8bdY=.110f3117-7eea-4b47-b23e-c5bd3a0105eb@github.com>
Message-ID: <JFchYTt6qVtzaYCwt6O_pM4aetCTWhee4l_psP8VSVU=.dfa6e368-ffd9-4c41-a2c7-98dff4aa0a4e@github.com>

On Thu, 3 Oct 2024 00:05:17 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:
> 
>   Removed stripZerosToEvenScale to simplify the code

I've skimmed the PR; it will likely take me several weeks to come back for an in-depth review.

My initial question is what additional regression test cases should be added to probe the new code.

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

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2390287137

From liach at openjdk.org  Thu Oct  3 00:51:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Oct 2024 00:51:38 GMT
Subject: RFR: 8341445: DecimalFormatSymbols can throw NPE for equals()
In-Reply-To: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
Message-ID: <7OCCSaGNXW-howL9CvomoTStKSiPC9NBkl5Xe4iz1UM=.84cb711e-da14-45c3-81fd-402c797caafe@github.com>

On Wed, 2 Oct 2024 23:16:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols.
> 
> DecimalFormatSymbols via its setters, allows certain instance variables to be set as null. (Note that some variables are allowed to be null, and others are not.) However, non null safe comparisons are used for all variables during the equality check. This can lead to an unexpected NPE when `DecimalFormatSymbols.equals()` is invoked.
> 
> The nullable variables in question should be equality checked via the static `Object.equals()`. An associated regression test is added to confirm the change.

Should we add an explicit whitelist of methods allowed to throw NPE, so that if we add new getter/setters to DFS, we can avoid this nasty null problem for the future? This whitelist will be validated by tests for sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/21315#issuecomment-2390288579

From liach at openjdk.org  Thu Oct  3 01:07:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Oct 2024 01:07:38 GMT
Subject: RFR: 8341006: Optimize StackMapGenerator detect frames [v2]
In-Reply-To: <6Ti1R4kgPQBmivebRnrIEN3o74woLqUuCqGLMF7ylsk=.ae6813f5-aabf-4748-a608-965cfe6da475@github.com>
References: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
 <6Ti1R4kgPQBmivebRnrIEN3o74woLqUuCqGLMF7ylsk=.ae6813f5-aabf-4748-a608-965cfe6da475@github.com>
Message-ID: <4FT32TIVpC58kr_UHuT-27blAcF_aXlNY2LdXe6VX1A=.74933640-e4a2-43c7-9091-b38eed82186d@github.com>

On Fri, 27 Sep 2024 01:34:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> 1. Construct Frames directly without BitSet
>> 2. Use Frame[] instead of ArrayList
>> 3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects when there is no frame.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

The removal of bitset makes this frame detection significantly slower for startup. A heap sort or manual unrolling of bitset may be better.

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

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21183#pullrequestreview-2344464999

From jpai at openjdk.org  Thu Oct  3 01:59:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Oct 2024 01:59:34 GMT
Subject: RFR: 8340229: Improve opening sentence of FileInputStream
 constructor specification [v3]
In-Reply-To: <gitZCSi8x_SzyIx3h_Qfazor6Jmw5aoROfCIqOr2ytg=.827fde65-6a2f-4ba6-a2a3-17cbe873aec7@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
 <gitZCSi8x_SzyIx3h_Qfazor6Jmw5aoROfCIqOr2ytg=.827fde65-6a2f-4ba6-a2a3-17cbe873aec7@github.com>
Message-ID: <_LLqwMN08EULDZmbcT85Oz8aQxFBtcOj_k1yRYP6zlc=.4073ee50-77ff-4997-85a6-74491ee49b9a@github.com>

On Wed, 2 Oct 2024 15:23:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8340229: Correct typo in FIS

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21223#pullrequestreview-2344498142

From mchung at openjdk.org  Thu Oct  3 02:14:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 3 Oct 2024 02:14:45 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v3]
In-Reply-To: <HvB3n3NzkjFR2uY4TxwxZGwd8ZzsrK2voEI-Q-3QKhM=.307efa67-8944-4e5c-81ab-3ab603b7672c@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
 <HvB3n3NzkjFR2uY4TxwxZGwd8ZzsrK2voEI-Q-3QKhM=.307efa67-8944-4e5c-81ab-3ab603b7672c@github.com>
Message-ID: <FxFQRTod7Kmx3VZKmz5XX_B_-JXXnxKLKVtChP3PE24=.4e768077-e4e9-497b-8e1e-1eced6a38666@github.com>

On Fri, 27 Sep 2024 18:03:14 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:
> 
>   Missing from last commit

Quick comments on this PR.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 558:

> 556:         private final int moduleDescriptorsPerMethod;
> 557: 
> 558:         private final ArrayList<Consumer<ClassBuilder>> amendaments = new ArrayList<>();

Typo: `s/amendaments/amendments/`

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 665:

> 663:         private void genConstants(ClassBuilder clb) {
> 664:             var cinitSnippets = dedupSetBuilder.buildConstants(clb);
> 665:             if (!cinitSnippets.isEmpty()) {

Suggestion:

            var clinitSnippets = dedupSetBuilder.buildConstants(clb);
            if (!clinitSnippets.isEmpty()) {

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 795:

> 793:                                    this.classDesc,
> 794:                                    helperMethodNamePrefix + "0",
> 795:                                    MethodTypeDesc.of(CD_void, CD_MODULE_DESCRIPTOR.arrayType())

The comment line 741-767 needs to be updated to reflect the new helper method as well as the new methods `module{$index}Packages` and `module{$index}Exports`

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1714:

> 1712:             }
> 1713: 
> 1714:             class SetReference<T extends Comparable<T>> implements Comparable<SetReference<T>> {

The class name `SetReference` is not obvious what it does.   A comment would be helpful.

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

PR Review: https://git.openjdk.org/jdk/pull/21022#pullrequestreview-2341647851
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1783660750
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1783661198
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1783662487
PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1783667229

From dhanalla at openjdk.org  Thu Oct  3 02:23:35 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Thu, 3 Oct 2024 02:23:35 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <EIgPRPPps4JFWQNlv_Gxp4Zo94bNVp3I3YSOenYP7Dg=.7518f304-0842-4102-9aad-0f039a2b8128@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
 <EIgPRPPps4JFWQNlv_Gxp4Zo94bNVp3I3YSOenYP7Dg=.7518f304-0842-4102-9aad-0f039a2b8128@github.com>
Message-ID: <LAmVop7jTMkdyWsk9mIYw1lFRu1mnZ0w01vkqxb_UQ8=.d6448823-062a-45b2-a0ac-eff3b3c14762@github.com>

On Thu, 26 Sep 2024 16:17:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix missing code
>
> I don't have a suggestion for maintaining compatibility other than not making the change.

Thank you @plummercj, @kevinjwalls,
We appreciate your concerns regarding compatibility. However, we implemented this change to enhance security. 
According to the documentation at https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha#remarks, it is recommended to use GetTempPath2. If you believe that compatibility is more critical than the security improvements we've made, we are willing to close the pull request.

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

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2390368801

From duke at openjdk.org  Thu Oct  3 04:22:41 2024
From: duke at openjdk.org (duke)
Date: Thu, 3 Oct 2024 04:22:41 GMT
Subject: Withdrawn: 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: <u2WvIWqFFjnC0lCbafiCTzZG-u8RaIiPoLi53W82Fn8=.6fb82cef-b9fa-40c6-867b-2f1821ca0758@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 been closed without being integrated.

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

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

From jbhateja at openjdk.org  Thu Oct  3 05:09:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 05:09:22 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v15]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <TjvxhAjgb783SX3hLwya_KCLlKM6ci1jIZfw1ZGjCdI=.29de9360-4a15-4aaf-b3df-840e66da5385@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Review comments resolution.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338023
 - Review comments resolutions.
 - Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.
 - Incorporating review and documentation suggestions.
 - Jcheck clearance
 - Review comments resolution.
 - Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.
 - Documentation suggestions from Paul.
 - Review resolutions.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/bdfb41f9...6215ab91

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

Changes: https://git.openjdk.org/jdk/pull/20508/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=14
  Stats: 2804 lines in 89 files changed: 2785 ins; 18 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

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

From jbhateja at openjdk.org  Thu Oct  3 05:09:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 05:09:22 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v14]
In-Reply-To: <5wF2qLX9Z_tquvURMW0HVnrmMla1awxtz6C0UYI0lh4=.94df7340-1a27-4d93-80fa-d4c561641a97@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <gr0t8AMHsNLOiUnl1NiEaICixmENi5Geo1igGaQ2zPs=.fa783172-eaee-48c1-8c7d-4cc337184369@github.com>
 <5wF2qLX9Z_tquvURMW0HVnrmMla1awxtz6C0UYI0lh4=.94df7340-1a27-4d93-80fa-d4c561641a97@github.com>
Message-ID: <uM4S2rRyAjE5sz0Syh5VfT3XNlpu_26aWzh1ljoLDQw=.82832862-0a98-43e4-8fd7-415d8ab88b44@github.com>

On Tue, 1 Oct 2024 18:10:10 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 2797:
> 
>> 2795: 
>> 2796:   Node* operation = lowerSelectFromOp ?
>> 2797:                       LowerSelectFromTwoVectorOperation(gvn(), opd1, opd2, opd3, vt) :
> 
> Thanks for bringing the lowering right here. It opens up an optimization opportunity: currently for float/double we have two casts for index (e.g. from float -> int at line 2786 and from int -> byte at line 2661 as part of LowerSelectFromTwoVectorOperation. Could this be done by one cast?

This is not sub-optimal, Float to sub-word cast is two step process where we first convert float value to integer following by integer down casting to sub-word. So resulting JIT code will still be same if we directly emit F2X or the way its handled currently. All existing targets support F2X take this route. But its good to be safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1785634731

From jbhateja at openjdk.org  Thu Oct  3 05:09:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 05:09:22 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
 <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
 <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>
Message-ID: <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>

On Tue, 1 Oct 2024 18:03:06 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>>> This could instead be: src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2); Or even simplified to: src1.rearrange(this.toShuffle(), src2);
>> 
>> Yes, this may save additional allocation penalty of result array allocation which may slightly improve fall back performance, but logical operation cannot be directly applied over floating point vectors. so, we will need an explicit conversion to integral vector, which is why I opted for current fallback implementation which is in line with rest of the code.
>
> I see the problem with float/double vectors. Let us do the rearrange form only for Integral (byte, short, int, long) vectors then. For float/double vector we could keep the code that you have currently.

You will also need additional handling for NPOT vector sizes which is handled by existing fallback implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1785634658

From duke at openjdk.org  Thu Oct  3 07:58:35 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 07:58:35 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
 <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
 <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
Message-ID: <_rG9FOYbIDlwgOHQZmRdX_6AKYk_ChZKhFdUfFyFiJ4=.b79bdb7e-29be-48f5-ab82-f6a865b46232@github.com>

On Wed, 2 Oct 2024 18:16:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> A possible faster implementation of `stripZerosToMatchScale()` could be based on dividing by increasing powers of 10 whose exponent doubles at each step (a kind of repeated squares trick), although the asymptotic running time would still be exponential.
>
> Without experimenting a bit, it's hard to tell.
> Anyway, I believe the current implementation of `stripZerosToMatchScale()` is O(n^2) rather than exponential, because each single division by 10 is linear.
> 
> But let's focus on `sqrt()` in this PR and leave `stripZerosToMatchScale()` for another time.

@rgiulietti  I tried to implement and test stripping zeros  algorithm with repeated squares trick, and on my laptop it takes around two seconds for strip one million of zeros. So, I decided to remove the method `stripZerosToEvenScale()`, in order to use only the `stripZerosToMatchScale()` logic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1785790063

From rgiulietti at openjdk.org  Thu Oct  3 09:07:35 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 3 Oct 2024 09:07:35 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <_rG9FOYbIDlwgOHQZmRdX_6AKYk_ChZKhFdUfFyFiJ4=.b79bdb7e-29be-48f5-ab82-f6a865b46232@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
 <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
 <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
 <_rG9FOYbIDlwgOHQZmRdX_6AKYk_ChZKhFdUfFyFiJ4=.b79bdb7e-29be-48f5-ab82-f6a865b46232@github.com>
Message-ID: <qLivJ9E1xuLJ8wb__O3k6HREpdaik2o4JlVuxq-bLvo=.87edae6f-0ffa-42cb-bf27-9bf2e8c75ede@github.com>

On Thu, 3 Oct 2024 07:55:26 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Without experimenting a bit, it's hard to tell.
>> Anyway, I believe the current implementation of `stripZerosToMatchScale()` is O(n^2) rather than exponential, because each single division by 10 is linear.
>> 
>> But let's focus on `sqrt()` in this PR and leave `stripZerosToMatchScale()` for another time.
>
> @rgiulietti  I tried to implement and test stripping zeros  algorithm with repeated squares trick, and on my laptop it takes around two seconds for strip one million of zeros. So, I decided to remove the method `stripZerosToEvenScale()`, in order to use only the `stripZerosToMatchScale()` logic.

Nice!

Perhaps it would make sense to have your new implementation of `stripZerosToMatchScale()` in another PR, integrate that one first, and then come back to this PR. For general usage of `BigDecimal`, its more useful to have a faster `stripZerosToMatchScale()` than a faster `sqrt()`, I think.

Let me know if you agree of if you prefer to go ahead with with PR first.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1785883833

From duke at openjdk.org  Thu Oct  3 09:12:37 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 09:12:37 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <_rG9FOYbIDlwgOHQZmRdX_6AKYk_ChZKhFdUfFyFiJ4=.b79bdb7e-29be-48f5-ab82-f6a865b46232@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
 <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
 <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
 <_rG9FOYbIDlwgOHQZmRdX_6AKYk_ChZKhFdUfFyFiJ4=.b79bdb7e-29be-48f5-ab82-f6a865b46232@github.com>
Message-ID: <Yzuad1R7dn3wMYbKVJq8l_hhDhZXszzubTzjs4KpBjs=.f129a138-e17f-4e28-98dd-33e3d868aa9c@github.com>

On Thu, 3 Oct 2024 07:55:26 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Without experimenting a bit, it's hard to tell.
>> Anyway, I believe the current implementation of `stripZerosToMatchScale()` is O(n^2) rather than exponential, because each single division by 10 is linear.
>> 
>> But let's focus on `sqrt()` in this PR and leave `stripZerosToMatchScale()` for another time.
>
> @rgiulietti  I tried to implement and test stripping zeros  algorithm with repeated squares trick, and on my laptop it takes around two seconds for strip one million of zeros. So, I decided to remove the method `stripZerosToEvenScale()`, in order to use only the `stripZerosToMatchScale()` logic.

@fabioromano1 I agree with starting a new PR for speed up `stripZerosToMatchScale()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1785890823

From denisbredelet at boomi.com  Thu Oct  3 09:17:53 2024
From: denisbredelet at boomi.com (Denis Bredelet)
Date: Thu, 3 Oct 2024 10:17:53 +0100
Subject: Minor OpenJDK 11 update changed ObjectIdentifer constructor to private
Message-ID: <CAHxSrfLfRodixUNq+1zYeXatjzqfaR7Y0YGmMECYDyvfXa=P2A@mail.gmail.com>

Hello,

With the OpenJDK 11.0.21 release the constructor visibility changed.
That breaks code that relied on
"sun.security.util.ObjectIdentifier(String oid)" such as Apache Kerby
directory's GssTokenV1 class.

The error I receive is:

class org.apache.kerby.kerberos.kerb.gss.impl.GssTokenV1 tried to
access private method 'void
sun.security.util.ObjectIdentifier.<init>(java.lang.String)'

The change that affected the visibility of the constructor is:

https://bugs.openjdk.org/browse/JDK-8310005

Shouldn't the signature of the class remain stable between minor
versions? 11.0.20 -> 11.0.21

Thanks!

Denis Bredelet
Advanced Support Engineering

From rgiulietti at openjdk.org  Thu Oct  3 09:21:37 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 3 Oct 2024 09:21:37 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <Yzuad1R7dn3wMYbKVJq8l_hhDhZXszzubTzjs4KpBjs=.f129a138-e17f-4e28-98dd-33e3d868aa9c@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
 <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
 <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
 <_rG9FOYbIDlwgOHQZmRdX_6AKYk_ChZKhFdUfFyFiJ4=.b79bdb7e-29be-48f5-ab82-f6a865b46232@github.com>
 <Yzuad1R7dn3wMYbKVJq8l_hhDhZXszzubTzjs4KpBjs=.f129a138-e17f-4e28-98dd-33e3d868aa9c@github.com>
Message-ID: <aB14Ky1irR4Eyk5TlWet7RfJt36vSFs0OMnyP4I8LZ0=.8dad1dd5-62ab-4a51-95d2-c9ec9032280d@github.com>

On Thu, 3 Oct 2024 09:10:07 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> @rgiulietti  I tried to implement and test stripping zeros  algorithm with repeated squares trick, and on my laptop it takes around two seconds for strip one million of zeros. So, I decided to remove the method `stripZerosToEvenScale()`, in order to use only the `stripZerosToMatchScale()` logic.
>
> @fabioromano1 I agree with starting a new PR for speed up `stripZerosToMatchScale()`.

I'll open a JBS issue to refer to as soon as you open the new PR.

Please keep the first PR comment as short as possible, then add further details in another comment. As only the first comment is auto-copied in every email in the mailing list, keeping it short helps with bandwidth.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1785902622

From alan.bateman at oracle.com  Thu Oct  3 09:51:23 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Thu, 3 Oct 2024 10:51:23 +0100
Subject: Minor OpenJDK 11 update changed ObjectIdentifer constructor to
 private
In-Reply-To: <CAHxSrfLfRodixUNq+1zYeXatjzqfaR7Y0YGmMECYDyvfXa=P2A@mail.gmail.com>
References: <CAHxSrfLfRodixUNq+1zYeXatjzqfaR7Y0YGmMECYDyvfXa=P2A@mail.gmail.com>
Message-ID: <03e17fef-a012-4ecf-8442-2b2f66d97eb0@oracle.com>

On 03/10/2024 10:17, Denis Bredelet wrote:
> Hello,
>
> With the OpenJDK 11.0.21 release the constructor visibility changed.
> That breaks code that relied on
> "sun.security.util.ObjectIdentifier(String oid)" such as Apache Kerby
> directory's GssTokenV1 class.
>
> The error I receive is:
>
> class org.apache.kerby.kerberos.kerb.gss.impl.GssTokenV1 tried to
> access private method 'void
> sun.security.util.ObjectIdentifier.<init>(java.lang.String)'
>
> The change that affected the visibility of the constructor is:
>
> https://bugs.openjdk.org/browse/JDK-8310005
>
> Shouldn't the signature of the class remain stable between minor
> versions? 11.0.20 -> 11.0.21
>
This is a JDK internal class that can change at any release or build. I 
don't know anything about Apache Kerby, is it actively maintained? Is 
there is an issue in its issue tracker to remove the dependency on this 
JDK internal class?

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

From jvernee at openjdk.org  Thu Oct  3 12:05:46 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 3 Oct 2024 12:05:46 GMT
Subject: Integrated: 8337753: Target class of upcall stub may be unloaded
In-Reply-To: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
References: <uEYYXkFW-aCs6Xw-tEoSaMnydXFpazE9o7uWiViSxWM=.20bbf5de-06a5-4042-b60f-563a93f77210@github.com>
Message-ID: <2THc5A3PP0cegVF4ySYMLsgc4FO2ieqBgOEI02XgxOk=.0f92be1b-ddbc-4486-ac22-2c303f442ba2@github.com>

On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> As discussed in the JBS issue:
> 
> FFM upcall stubs embed a `Method*` of the target method in the stub. This `Method*` is read from the `LambdaForm::vmentry` field associated with the target method handle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: `MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder)`
> 
> However, it appears that, due to multiple threads racing to initialize the `vmentry` field of the `LambdaForm` of the target method handle of an upcall stub, it is possible that the `vmentry` is updated _after_ we embed the corresponding `Method`* into an upcall stub (or rather, the latest update is not visible to the thread generating the upcall stub). Technically, it is fine to keep using a 'stale' `vmentry`, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target `Method*`, and doesn't keep the stale `vmentry` reachable. The holder class can then be unloaded, resulting in a crash.
> 
> The fix I've chosen for this is to mimic what we already do in `MethodHandles::jump_to_lambda_form`, and re-load the `vmentry` field from the target method handle each time. Luckily, this does not really seem to impact performance.
> 
> <details>
> <summary>Performance numbers</summary>
> x64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  69.216 ? 1.791  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  67.787 ? 0.684  ns/op
> 
> 
> aarch64:
> 
> before:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.574 ? 0.801  ns/op
> 
> 
> after:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> Upcalls.panama_blank  avgt   30  61.218 ? 0.554  ns/op
> 
> </details>
> 
> As for the added TestUpcallStress test, it takes about 800 seconds to run this test on the dev machine I'm using, so I've set the timeout quite high. Since it runs for so long, I've dropped it from the default `jdk_foreign` test suite, which runs in tier2. Instead the new test will run in tier4.
> 
> Testing: tier 1-4

This pull request has now been integrated.

Changeset: 6af13580
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6af13580c2086afefde489275bc2353c2320ff3f
Stats:     333 lines in 23 files changed: 255 ins; 26 del; 52 mod

8337753: Target class of upcall stub may be unloaded

Reviewed-by: amitkumar, vlivanov, mdoerr

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

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

From eosterlund at openjdk.org  Thu Oct  3 12:09:41 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 3 Oct 2024 12:09:41 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <ixtfOfUmd7Qvf1icAGdzNWdP4rA_CAeIOnHT5X4OWIU=.7bdfd24b-f7aa-462b-ae65-6fda54dec9dd@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
 <hZWL_XWLx6Go4HVThv8eKSKI36UKVxxvz9jzgPrhg_s=.b3db549d-4b42-43ab-9f86-6de0caec26ca@github.com>
 <rcGTOJcKY3ZAscPyEi3G5zKbPXRdHnJqibX5fiP4Elw=.8347be15-1ae3-4125-9f72-e230d2018a1a@github.com>
 <Lm3cvu-YkJizbmEGvRISkK4y57V46IKdGBY7INNmjD4=.70226a4a-322b-4e04-acfa-b64a16883031@github.com>
 <ixtfOfUmd7Qvf1icAGdzNWdP4rA_CAeIOnHT5X4OWIU=.7bdfd24b-f7aa-462b-ae65-6fda54dec9dd@github.com>
Message-ID: <WzpvuDoA-1FylguokFAivFxQG0E2PQvkWwkwx875piQ=.d9c0d4a7-edff-40af-9c98-c6d4b75b8a81@github.com>

On Mon, 30 Sep 2024 16:32:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I think we need a new ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing(oop* p) and to make that the selected slow path function when ZBarrierNoKeepalive is set on a StorePNode. Its implementation would call ZBarrier::no_keep_alive_store_barrier_on_heap_oop_field. This should do the trick.
> 
> Thanks! See new commits: is that the shape you were thinking of?

Yeah that's perfect. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2391252177

From swen at openjdk.org  Thu Oct  3 12:11:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 3 Oct 2024 12:11:44 GMT
Subject: Integrated: 8341415: Optimize RawBytecodeHelper::next
In-Reply-To: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
References: <iLsdQ85j_ee1sNcQGjvqc7LGTjUtJz4vDYRCAcq1zr0=.b4e143de-de14-4a49-bfb2-8abeb8d91f7d@github.com>
Message-ID: <cLgM5VESoUSdZXofYhsXAAoL-WwcTAUgiZxlw9pBnL4=.19f54608-1768-48b7-8e1e-3e731c05ba39@github.com>

On Wed, 2 Oct 2024 07:53:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to the RawBytecodeHelper::next method
> * Remove `len <= 0` once
> * merge store opcode and isWide

This pull request has now been integrated.

Changeset: d7f32d89
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7f32d891cde2278fe7158fb28d29235db5c818c
Stats:     40 lines in 1 file changed: 9 ins; 14 del; 17 mod

8341415: Optimize RawBytecodeHelper::next

Reviewed-by: liach

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

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

From eosterlund at openjdk.org  Thu Oct  3 12:16:38 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 3 Oct 2024 12:16:38 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
Message-ID: <GFRSx-YcBOAyZfgBied8BTn3uz2IbEM4VZDh3quDmXE=.c79bb9eb-f314-42bf-aa01-2bd0792fba26@github.com>

On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [ ] Linux x86_64 server fastdebug, `all`
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also dispatch to slow-path on other arches

Changes requested by eosterlund (Reviewer).

src/hotspot/share/opto/library_call.cpp line 7002:

> 7000:   // Add memory barrier to prevent commoning the accesses in this code,
> 7001:   // since GC can change the value of referent at any time.
> 7002:   insert_mem_bar(Op_MemBarCPUOrder);

I think this CPU memory barrier and comment above are confusing and obviously just taken from the referent loading intrinsics. The commoning it is talking about is to short circuit a second load with the result of a first load of the referent field, since the compiler "knows" the first load would give the "same" answer unless "something happened" (GC clearing it).
In this case the mutator just cleared it, so what the compiler thinks is that null is stored in that field. And that's completely accurate, and the GC is not going to transition the field from null to some random other object.
Let's remove this CPU memory barrier and the misleading comments.

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

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2345438249
PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1786116003

From duke at openjdk.org  Thu Oct  3 12:33:35 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 12:33:35 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <aB14Ky1irR4Eyk5TlWet7RfJt36vSFs0OMnyP4I8LZ0=.8dad1dd5-62ab-4a51-95d2-c9ec9032280d@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
 <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
 <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
 <_rG9FOYbIDlwgOHQZmRdX_6AKYk_ChZKhFdUfFyFiJ4=.b79bdb7e-29be-48f5-ab82-f6a865b46232@github.com>
 <Yzuad1R7dn3wMYbKVJq8l_hhDhZXszzubTzjs4KpBjs=.f129a138-e17f-4e28-98dd-33e3d868aa9c@github.com>
 <aB14Ky1irR4Eyk5TlWet7RfJt36vSFs0OMnyP4I8LZ0=.8dad1dd5-62ab-4a51-95d2-c9ec9032280d@github.com>
Message-ID: <4CkNAaWL3o8PrmdJl6xWU73Y0LYDLqBWYgqZlkNHI2c=.13a9a770-c19d-4f81-9285-fd2bcd1ab9d4@github.com>

On Thu, 3 Oct 2024 09:18:56 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @fabioromano1 I agree with starting a new PR for speed up `stripZerosToMatchScale()`.
>
> I'll open a JBS issue to refer to as soon as you open the new PR.
> 
> Please keep the first PR comment as short as possible, then add further details in another comment. As only the first comment is auto-copied in every email in the mailing list, keeping it short helps with bandwidth.

@rgiulietti I've created the PR: [here](https://github.com/openjdk/jdk/pull/21323)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1786137964

From rgiulietti at openjdk.org  Thu Oct  3 12:45:35 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 3 Oct 2024 12:45:35 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <4CkNAaWL3o8PrmdJl6xWU73Y0LYDLqBWYgqZlkNHI2c=.13a9a770-c19d-4f81-9285-fd2bcd1ab9d4@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <EVPk9Z9D_HPJVSXvFFNtrxdU2Czt-cGUeoZMjimaHd4=.7664b31e-7ae3-45db-a5c8-e542c2d28390@github.com>
 <eou6sOp42rEaciWHdBWftWDSGtJy6ZKKJHZkgjFfrV4=.00ab92c5-0521-4422-8194-6cd08f8dd6a4@github.com>
 <rTm6TxupU7UJ3d1Tlp7Mbv_t7ZNEZQucph7FZkcpnug=.3e3a24dc-53f6-4f6f-afa2-962b7901352c@github.com>
 <Nr1SJknPcnD2M9FvPle_VDsvnDjr1rAs8g1bim9cR6I=.762f49f7-9d0e-4fdc-a8d3-bf50d1afe140@github.com>
 <5su-mUfjZ-fe37BGzMBiNeTTKBnZ_-2m8ML_22Q8CXk=.c84833cc-be78-427f-b690-d26f3f05b7cc@github.com>
 <_rG9FOYbIDlwgOHQZmRdX_6AKYk_ChZKhFdUfFyFiJ4=.b79bdb7e-29be-48f5-ab82-f6a865b46232@github.com>
 <Yzuad1R7dn3wMYbKVJq8l_hhDhZXszzubTzjs4KpBjs=.f129a138-e17f-4e28-98dd-33e3d868aa9c@github.com>
 <aB14Ky1irR4Eyk5TlWet7RfJt36vSFs0OMnyP4I8LZ0=.8dad1dd5-62ab-4a51-95d2-c9ec9032280d@github.com>
 <4CkNAaWL3o8PrmdJl6xWU73Y0LYDLqBWYgqZlkNHI2c=.13a9a770-c19d-4f81-9285-fd2bcd1ab9d4@github.com>
Message-ID: <4CeTknZD_vOpUeFvmNd1WdEIYNJK_2msqwPzsXg-ULs=.34a894d7-dae7-4f51-8d9d-a4779e3aa066@github.com>

On Thu, 3 Oct 2024 12:30:20 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I'll open a JBS issue to refer to as soon as you open the new PR.
>> 
>> Please keep the first PR comment as short as possible, then add further details in another comment. As only the first comment is auto-copied in every email in the mailing list, keeping it short helps with bandwidth.
>
> @rgiulietti I've created the PR: [here](https://github.com/openjdk/jdk/pull/21323)

Thanks.
To link it to the JBS issue, the title of that PR should read
8341470: BigDecimal.stripTrailingZeros() optimization

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1786155672

From duke at openjdk.org  Thu Oct  3 12:48:45 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 12:48:45 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization
Message-ID: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>

An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

Commit messages:
 - Removed trailing whitespaces
 - Changed stripTrailingZeros() implementation

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

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

From liach at openjdk.org  Thu Oct  3 13:01:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Oct 2024 13:01:35 GMT
Subject: RFR: 8341006: Optimize StackMapGenerator detect frames [v2]
In-Reply-To: <6Ti1R4kgPQBmivebRnrIEN3o74woLqUuCqGLMF7ylsk=.ae6813f5-aabf-4748-a608-965cfe6da475@github.com>
References: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
 <6Ti1R4kgPQBmivebRnrIEN3o74woLqUuCqGLMF7ylsk=.ae6813f5-aabf-4748-a608-965cfe6da475@github.com>
Message-ID: <7hFpzCY2X0URqT_Qlh0xfHmJ0RAdSa9tD4dpmCKUn0I=.cd29ff54-608c-42af-ad32-d00e72a17308@github.com>

On Fri, 27 Sep 2024 01:34:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> 1. Construct Frames directly without BitSet
>> 2. Use Frame[] instead of ArrayList
>> 3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects when there is no frame.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

This should be startup neutral.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21183#pullrequestreview-2345547806

From liach at openjdk.org  Thu Oct  3 13:10:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Oct 2024 13:10:39 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v19]
In-Reply-To: <owv1MsiRKgK4LjPEYYgPvxin-W1AsCUkq2ZCNiLHCrQ=.c9e5f436-0b3c-4b90-936a-736f8dc064b9@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <owv1MsiRKgK4LjPEYYgPvxin-W1AsCUkq2ZCNiLHCrQ=.c9e5f436-0b3c-4b90-936a-736f8dc064b9@github.com>
Message-ID: <6ysw-92u2B_dMvqVHBxGtcIWR03xnaX-qvmxMNSMcU0=.08763bf9-5fbc-4fe1-a668-cb78c17a1039@github.com>

On Wed, 2 Oct 2024 04:32:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge error

src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 33:

> 31: 
> 32: public class AttributeHolder {
> 33:     private static Attribute<?>[] EMPTY_ATTRIBUTE_ARRAY = {};

Suggestion:

    private static final Attribute<?>[] EMPTY_ATTRIBUTE_ARRAY = {};

src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java line 51:

> 49:                     attributesCount--;
> 50:                     System.arraycopy(attributes, i + 1, attributes, i, attributesCount - i);
> 51:                 }

Suggestion:

                    break;
                }

We can just break when wew find the attribute as thia mapper already prevents the attribute from appearing more than once.```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1786189079
PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1786192222

From duke at openjdk.org  Thu Oct  3 13:14:09 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 13:14:09 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v2]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <IGyfotywYM7otfJDNj8th7BoA92InsOckYCvSH7-l5A=.ceed3d7e-96e3-4431-8b22-44c278d92fd3@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Correction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/cffaf0ed..0818c263

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

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

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

From swen at openjdk.org  Thu Oct  3 13:15:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 3 Oct 2024 13:15:10 GMT
Subject: RFR: 8341006: Optimize StackMapGenerator detect frames [v3]
In-Reply-To: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
References: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
Message-ID: <LsR8yjmiSQXzTYmbZvkXT9JyIRV8vs80gIVEzTD9nSo=.5ee8372e-7b91-4724-a0fe-42940e674e02@github.com>

> 1. Construct Frames directly without BitSet
> 2. Use Frame[] instead of ArrayList
> 3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects when there is no frame.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  reduce codeSize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21183/files
  - new: https://git.openjdk.org/jdk/pull/21183/files/905acdda..aa390010

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

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

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

From liach at openjdk.org  Thu Oct  3 13:17:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Oct 2024 13:17:36 GMT
Subject: RFR: 8341006: Optimize StackMapGenerator detect frames [v3]
In-Reply-To: <LsR8yjmiSQXzTYmbZvkXT9JyIRV8vs80gIVEzTD9nSo=.5ee8372e-7b91-4724-a0fe-42940e674e02@github.com>
References: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
 <LsR8yjmiSQXzTYmbZvkXT9JyIRV8vs80gIVEzTD9nSo=.5ee8372e-7b91-4724-a0fe-42940e674e02@github.com>
Message-ID: <wllNhNqR3PNE7wuILPI6rs0HIdPpz0I606aLBsgUr2Q=.6dc7c315-3ac0-4072-aa71-9f5520c4fd07@github.com>

On Thu, 3 Oct 2024 13:15:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> 1. Construct Frames directly without BitSet
>> 2. Use Frame[] instead of ArrayList
>> 3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects when there is no frame.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce codeSize

Thanks for this last-minute small change cleanup.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21183#pullrequestreview-2345588574

From duke at openjdk.org  Thu Oct  3 13:18:09 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 13:18:09 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v3]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <z2aGRjrTILuAw4xxSPc6235prLYb9fOsTFssNiBqeZs=.7412fdfa-00f7-4dea-9927-7fa98a360c5c@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Removed superfluous conditions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/0818c263..bdad3faf

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

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

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

From duke at openjdk.org  Thu Oct  3 13:23:06 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 13:23:06 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v4]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <R6x4UYMUwtzcv34vi-mXyO3TdIyUDEHzdSe6UrcZpeo=.76ed73ed-248a-4a5c-bdf7-5daf461d4599@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Removed trailing whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/bdad3faf..6effc66b

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

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

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

From duke at openjdk.org  Thu Oct  3 13:29:49 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 13:29:49 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v5]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <7oxhkORW-p5uq2nnnLHmetADKtJ_-Ul3D_Blw9QeVpo=.8b790ef8-9923-4f31-ba66-9702c02bd124@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Small correction to avoid an unlikely overflow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/6effc66b..ad780461

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

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

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

From duke at openjdk.org  Thu Oct  3 13:52:51 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 13:52:51 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v6]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <V666ab5k5uObJOYEjKH0ESfzYX83EI4vwb87zZcZRA4=.4a520705-89c6-45cd-9d6e-65cd1013a829@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  An optimization in counting remaining zeros

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/ad780461..1ed24c58

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

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

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

From duke at openjdk.org  Thu Oct  3 13:58:55 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 13:58:55 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v7]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <83shs8GwHUwmfSK8vB-wiTtVriyyS0GRgvMoi5qHS3U=.1083121d-e0e9-432d-82a9-6110ae81eaab@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

 - Removed old exp declaration
 - Moved exp declaration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/1ed24c58..955a623c

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

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

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

From duke at openjdk.org  Thu Oct  3 14:33:51 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 14:33:51 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v8]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <mnXgmVNvyCe8qCwc0j_2B6Jy_xgzleHevvW-FZzaf_0=.dc8405f6-4771-4eb7-a316-81345ebfc30f@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Use powers of 5 instead of 10 by removing binary trailing zeros

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/955a623c..9ab98bb9

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

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

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

From swen at openjdk.org  Thu Oct  3 14:36:43 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 3 Oct 2024 14:36:43 GMT
Subject: Integrated: 8341006: Optimize StackMapGenerator detect frames
In-Reply-To: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
References: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
Message-ID: <9V3VTPX5B_AvXev_UeqqfSTP_R6oiW8okhX-va2hgpI=.fb30ccf4-a756-464e-bc17-67609a28bad9@github.com>

On Wed, 25 Sep 2024 12:05:02 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> 1. Construct Frames directly without BitSet
> 2. Use Frame[] instead of ArrayList
> 3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects when there is no frame.

This pull request has now been integrated.

Changeset: 12028000
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12028000db2ef3b1c784af119c495aa3ef9590cf
Stats:     128 lines in 1 file changed: 60 ins; 37 del; 31 mod

8341006: Optimize StackMapGenerator detect frames

Reviewed-by: liach

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

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

From iklam at openjdk.org  Thu Oct  3 14:38:40 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Oct 2024 14:38:40 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v7]
In-Reply-To: <yvJd3RW9yaLG_JKkwISGAIk7IrN67Ah-JgSnxjdQJE4=.4ed0e67a-0e63-48d1-94bc-bc8f0747aa23@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>
 <yvJd3RW9yaLG_JKkwISGAIk7IrN67Ah-JgSnxjdQJE4=.4ed0e67a-0e63-48d1-94bc-bc8f0747aa23@github.com>
Message-ID: <5jaO3m9o-P76upJgf54nHDsFzNiyBUsrXnZYAzMWeJo=.66011078-093f-48da-95ad-f65b9a9681ad@github.com>

On Wed, 2 Oct 2024 23:08:52 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Ioi Lam 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 branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - @liach and @cl4es comments
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - @dholmes-ora review comments
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Do not use system property to limit usage to only CDS static dumps
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/438ea318...1b067b7b
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java line 92:
> 
>> 90:         CUSTOMIZE_THRESHOLD = Integer.parseInt(
>> 91:                 props.getProperty("java.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD", "127"));
>> 92:         NO_SOFT_CACHE = CDS.disableMethodHandleSoftCache();
> 
> I suggest to use `CDS.disableMethodHandleSoftCache()` as the default and allow to override the mode through a property.
> 
> 
> NO_SOFT_CACHE = Boolean.parseBoolean( 
>         props.getProperty("java.lang.invoke.MethodHandle.NO_SOFT_CACHE", 
>                                         Boolean.toString(CDS.disableMethodHandleSoftCache()));

My initial implementation used a `java.lang.invoke.MethodHandle.NO_SOFT_CACHE` property. However, I was afraid that such a property might be abused, which would cause problems with class unloading. Therefore, I decided to make it fully controlled by HotSpot via a native method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1786336817

From duke at openjdk.org  Thu Oct  3 14:39:16 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 14:39:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v9]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <u7KVrDZBmT4NtAkeCJUfCXowuSsYc9VlQGGfvbt4kUk=.3f7280bc-69af-481e-b3fb-f88d9871f549@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Correct abs(intVal) >= 10 to abs(intVal) >= 5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/9ab98bb9..8a6e38f3

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

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

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

From bpb at openjdk.org  Thu Oct  3 15:16:46 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Oct 2024 15:16:46 GMT
Subject: Integrated: 8340229: Improve opening sentence of FileInputStream
 constructor specification
In-Reply-To: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
References: <m5t6Do213R4Jwys1OjKVobdYBtKnHHdDKZlHTcvNIzg=.078cbf31-ddba-4e61-bad2-4d5d2320e1c0@github.com>
Message-ID: <rD8pFBxCqsz5HGJ-TVA93MeGOFzav8nGFoD7ni0LT0U=.40006448-9a2f-4e97-aad4-9b455483e82c@github.com>

On Fri, 27 Sep 2024 16:06:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve the first sentences of the three `FileInputStream` constructors, in particular removing the term "connection."

This pull request has now been integrated.

Changeset: f1ea57f0
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1ea57f06a044ebd39d31a7c4765d0220327b0a0
Stats:     8 lines in 1 file changed: 0 ins; 3 del; 5 mod

8340229: Improve opening sentence of FileInputStream constructor specification

Reviewed-by: alanb, jpai

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

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

From swen at openjdk.org  Thu Oct  3 16:57:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 3 Oct 2024 16:57:20 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v20]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <9kMYAnRXWY6UHJE5-jIJI2fT31Qs3b0cpCIbQQhAm0M=.85ef1feb-a958-4891-9664-5b02265cc087@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/8b092270..356761ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=18-19

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

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

From shade at openjdk.org  Thu Oct  3 16:57:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Oct 2024 16:57:39 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <GFRSx-YcBOAyZfgBied8BTn3uz2IbEM4VZDh3quDmXE=.c79bb9eb-f314-42bf-aa01-2bd0792fba26@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
 <GFRSx-YcBOAyZfgBied8BTn3uz2IbEM4VZDh3quDmXE=.c79bb9eb-f314-42bf-aa01-2bd0792fba26@github.com>
Message-ID: <zxDyh8g2y3ovrRYwS68Z8v1VmSlfgTe4axCNpD426g4=.b5ba863d-66fc-4723-8c2d-21799e710168@github.com>

On Thu, 3 Oct 2024 12:14:08 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also dispatch to slow-path on other arches
>
> src/hotspot/share/opto/library_call.cpp line 7002:
> 
>> 7000:   // Add memory barrier to prevent commoning the accesses in this code,
>> 7001:   // since GC can change the value of referent at any time.
>> 7002:   insert_mem_bar(Op_MemBarCPUOrder);
> 
> I think this CPU memory barrier and comment above are confusing and obviously just taken from the referent loading intrinsics. The commoning it is talking about is to short circuit a second load with the result of a first load of the referent field, since the compiler "knows" the first load would give the "same" answer unless "something happened" (GC clearing it).
> In this case the mutator just cleared it, so what the compiler thinks is that null is stored in that field. And that's completely accurate, and the GC is not going to transition the field from null to some random other object.
> Let's remove this CPU memory barrier and the misleading comments.

Right. I removed it in my local patch queue. Now I have to reconcile this PR with late barrier expansion in G1, I'll push the update once that is done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1786549120

From shade at openjdk.org  Thu Oct  3 16:57:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Oct 2024 16:57:40 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <V1ChvAolG5oJx4Y9AGbLAwmsYxcg2gmvMDGy6J2BHMU=.8a15d731-ba69-4cfa-9471-6b064feab70f@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
 <V1ChvAolG5oJx4Y9AGbLAwmsYxcg2gmvMDGy6J2BHMU=.8a15d731-ba69-4cfa-9471-6b064feab70f@github.com>
Message-ID: <MsPOYHq_-sRol1vs_8uBPp2b2DuCSHQRLzTPWH8V1mg=.bfbce9b8-c16c-46bc-90af-d9185255409e@github.com>

On Wed, 2 Oct 2024 10:47:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also dispatch to slow-path on other arches
>
> test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java line 2:
> 
>> 1: //
>> 2: // * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
> 
> Drive-by comment: The `// *` format looks weird.

Actually, this constellation of single-line comments should be replaced with a multi-line comment block. The fix is now in my (unpublished) patch queue, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1786548233

From duke at openjdk.org  Thu Oct  3 16:59:11 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 16:59:11 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v10]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <_w-tCw5g2F57Z7LWWuzjUsCGGqK6tk5RdiDSLYmnqsU=.c88ef837-e40d-4199-bd10-8c114c0ac4e0@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Cache the powers of 5 to allow the reuse

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/8a6e38f3..030c97a6

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

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

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

From duke at openjdk.org  Thu Oct  3 17:05:11 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 17:05:11 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v11]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <GhFljF68sLKAntvvoF23b39WyKMN3-tw5JqDivFs5II=.5c819433-ca55-4bca-b8ad-ddd5ddc62f8e@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Small change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/030c97a6..df0746fb

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

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

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

From duke at openjdk.org  Thu Oct  3 17:11:09 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 17:11:09 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/df0746fb..50d59fe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=10-11

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

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

From denisbredelet at boomi.com  Wed Oct  2 17:12:51 2024
From: denisbredelet at boomi.com (Denis Bredelet)
Date: Wed, 2 Oct 2024 18:12:51 +0100
Subject: Minor OpenJDK 11 update changed ObjectIdentifer constructor to private
Message-ID: <CAHxSrfJ-d8Aro9STCY2NtDXrMfFkc6F6KGzgct60W-7UeL-xLQ@mail.gmail.com>

Hello,

With the OpenJDK 11.0.21 release the constructor visibility changed.
That breaks code that relied on
"sun.security.util.ObjectIdentifier(String oid)" such as Apache Kerby
directory's GssTokenV1 class.

The error I receive is:

class org.apache.kerby.kerberos.kerb.gss.impl.GssTokenV1 tried to
access private method 'void
sun.security.util.ObjectIdentifier.<init>(java.lang.String)'

The change that affected the visibility of the constructor is:

https://bugs.openjdk.org/browse/JDK-8310005

Shouldn't the signature of the class remain stable between minor
versions? 11.0.20 -> 11.0.21

Thanks!

Denis Bredelet
Advanced Support Engineering

From sviswanathan at openjdk.org  Thu Oct  3 17:30:45 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 17:30:45 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v19]
In-Reply-To: <Rgx6r8xrA1DNQm-uuRrGmNnpWlvXWxMsBrvaYsWjQjE=.4bd7bd2b-aa3f-49e0-8d7b-0fd0b17577aa@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <Rgx6r8xrA1DNQm-uuRrGmNnpWlvXWxMsBrvaYsWjQjE=.4bd7bd2b-aa3f-49e0-8d7b-0fd0b17577aa@github.com>
Message-ID: <Q8p2kG7qU5nko7ELoX6Xrxlsg7JXYdroCdpCzlEkf-E=.9af66ab2-fd9f-4e9f-888f-3dd0774b89a8@github.com>

On Tue, 1 Oct 2024 05:09:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Merge stashing and re-commit

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 140:

> 138:      * @param b the second operand.
> 139:      * @return the saturating addition of the operands.
> 140:      * @see VectorOperators#SADD

This should be SUADD.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 167:

> 165:      * @param b the second operand.
> 166:      * @return the saturating difference of the operands.
> 167:      * @see VectorOperators#SSUB

This should be SUSUB.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786595393
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786595850

From sviswanathan at openjdk.org  Thu Oct  3 17:53:42 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 17:53:42 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
 <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
 <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>
 <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>
Message-ID: <n965SL7FQ_uU5-y-LPIStvMgWKeScMXeBkYbcKdri4Y=.96172206-5aec-4626-af89-372b6cf4b133@github.com>

On Thu, 3 Oct 2024 05:04:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I see the problem with float/double vectors. Let us do the rearrange form only for Integral (byte, short, int, long) vectors then. For float/double vector we could keep the code that you have currently.
>
> You will also need additional handling for NPOT vector sizes which is handled by existing fallback implementation.

The intrinsic is limited to power of two. We can safely do src1.rearrange(this.lanewise(VectorOperators.AND, 2 * VLENGTH - 1).toShuffle(), src2) for integral types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1786637638

From prr at openjdk.org  Thu Oct  3 17:59:36 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Oct 2024 17:59:36 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v7]
In-Reply-To: <Xd9CmvY6XmRJCcRuj-sb_TaVOIIpljceDPpMPVAjZy0=.142b8e70-5132-4d64-8823-1c48e3539dac@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <Xd9CmvY6XmRJCcRuj-sb_TaVOIIpljceDPpMPVAjZy0=.142b8e70-5132-4d64-8823-1c48e3539dac@github.com>
Message-ID: <D_wnYl9hbniwgypla2TSvwEiUIMyq5DhpadG53PrtEI=.d2b17d49-7a51-416b-82ff-cc1eb39094f4@github.com>

On Fri, 27 Sep 2024 18:08:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert bugID update to tests

test/jdk/java/util/TimeZone/DefaultTimeZoneTest.java line 32:

> 30:  * correctly on Windows. This is a manual test dependent on making changes to
> 31:  * the platform setting of the machine and thus cannot be automated.
> 32:  * @library /java/awt/regtesthelpers

You are missing "@build PassFailJFrame".
Per https://openjdk.org/jtreg/tag-spec.html -

In general, classes in library directories are not automatically compiled as part of a compilation command explicitly naming the source files containing those classes.
A test that relies upon library classes should contain appropriate @build directives to ensure that the classes will be compiled.
It is strongly recommended that tests do not rely on the use of implicit compilation by the Java compiler. Such an approach is generally fragile,
 and may lead to incomplete recompilation when a test or library code has been modified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21096#discussion_r1786644201

From duke at openjdk.org  Thu Oct  3 18:05:49 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 18:05:49 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v13]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <gm9OmOYLd37-g2XBgFlbViC8_8ZQMdW5-iz4_KWshG8=.21099531-9ca1-49cc-b9a6-153576580817@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Update documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/50d59fe0..6b184be8

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

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

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

From jlu at openjdk.org  Thu Oct  3 18:15:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 3 Oct 2024 18:15:55 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v8]
In-Reply-To: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
Message-ID: <4y81EJSqbylcEsEo-KkBu14tGWB4R0ysQsT9wHmiqjo=.593642c8-1e39-4410-a3cc-2f52b634ae2e@github.com>

> Please review this PR which removes usages of Applet within the corelibs tests.
> 
> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
> 
> The following files were removed,
> 
> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>   - Test runner is no longer an Applet, so not needed
> - test/jdk/java/net/Socket/SocketImplTest.java
>   - An old Applet test missing Jtreg tags.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect Phil's review: build tag for PassFailJFrame

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21096/files
  - new: https://git.openjdk.org/jdk/pull/21096/files/5b6bd624..8a06843e

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

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

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

From sviswanathan at openjdk.org  Thu Oct  3 18:18:44 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 18:18:44 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v15]
In-Reply-To: <TjvxhAjgb783SX3hLwya_KCLlKM6ci1jIZfw1ZGjCdI=.29de9360-4a15-4aaf-b3df-840e66da5385@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <TjvxhAjgb783SX3hLwya_KCLlKM6ci1jIZfw1ZGjCdI=.29de9360-4a15-4aaf-b3df-840e66da5385@github.com>
Message-ID: <UY7D7-cVhI8qBm4VzmK7RDT5R6iNo1sytclt0oa8bZk=.a832b4cb-1147-4dfe-b572-8342a761a0e0@github.com>

On Thu, 3 Oct 2024 05:09:22 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Review comments resolution.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338023
>  - Review comments resolutions.
>  - Handling NPOT vector length for AArch64 SVE with vector sizes varying b/w 128 and 2048 bits at 128 bit increments.
>  - Incorporating review and documentation suggestions.
>  - Jcheck clearance
>  - Review comments resolution.
>  - Disabling VectorLoadShuffle bypassing optimization to comply with rearrange semantics at IR level.
>  - Documentation suggestions from Paul.
>  - Review resolutions.
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/bdfb41f9...6215ab91

Thanks for making the changes. It looks to me that  the following checks at lines 2963-2071 in file vectorIntrinsics.cpp is now only needed when lowerSelectFromOp is false. Could you please verify and update accordingly?

 if (is_floating_point_type(elem_bt)) {
    if (!arch_supports_vector(Op_AndV, num_elem, index_elem_bt, VecMaskNotUsed)              ||
        !arch_supports_vector(cast_vopc, num_elem, index_elem_bt, VecMaskNotUsed)            ||
        !arch_supports_vector(Op_Replicate, num_elem, index_elem_bt, VecMaskNotUsed)) {
      log_if_needed("  ** index wrapping not supported: vlen=%d etype=%s" ,
                     num_elem, type2name(elem_bt));
      return false; // not supported
    }
  }

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

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2392036048

From louisb at broadinstitute.org  Thu Oct  3 18:35:48 2024
From: louisb at broadinstitute.org (Louis Bergelson)
Date: Thu, 3 Oct 2024 14:35:48 -0400
Subject: Illegal Seek when using File.newInputStream()
In-Reply-To: <B7B855AC-56A9-48A7-9E51-8CE9194998BC@oracle.com>
References: <CALexLmGSxcF2k53cpVNX6nJc9=dOLwJac+hGBE3Ma1S0YADA+w@mail.gmail.com>
 <5deb045d-1362-485d-a8d3-5cd9f4c6c8ec@oracle.com>
 <CALexLmGPB1sNfdFd4md7aNwYx3Byc+-DPHTikkk3hmHxWdoxCg@mail.gmail.com>
 <B7B855AC-56A9-48A7-9E51-8CE9194998BC@oracle.com>
Message-ID: <CALexLmG8M9H7s1Ko97bFQE3eK9DZueo2+UhY37X1+sANb+AhuA@mail.gmail.com>

Hi Brian,

Thanks for looking into this!  That sounds like it would work for my use
case.  Anything that returns a result instead of a crash would be a huge
improvement.   My main concern is definitely unix/bsd/osx systems, I don't
have a good sense of how pipes work on windows or if there is an analogous
issue there.

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

From sviswanathan at openjdk.org  Thu Oct  3 18:41:40 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 18:41:40 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v13]
In-Reply-To: <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <QUmd09oIZJqK101nl8zz0i84gtl7TtW7dkpsik9EY6M=.348582ac-1665-4f11-a05b-39c60e3aae3d@github.com>
 <HY1cUyE2pOIzOWFXeKzBt-CtgNGOODOMcEX8tG_VPq4=.b3c497d6-4862-49b2-9bf3-a8ce84bdab93@github.com>
 <IiAlGl78eRnGzD4q82d6qd5H9IehP41BOpzgvB79cEc=.c244cc98-246e-4091-92e7-2e934c80baf5@github.com>
 <LmJv3EFA94_s5G__oFl7SfI8MXb3sX_puP97sDfimaE=.3e314bef-3c70-40e2-b732-502e5393c316@github.com>
 <vX4d1GNr-4JAB1mn1zj974lj8uRs4aUU504yuyR9k4o=.95f041b5-871b-4c80-8583-3c5ebff15df3@github.com>
 <rIJiEu4HJ2A58r-B_mB4pkhJKoEWdw9UWFb9i5goDEI=.d69d8a24-c6ce-4800-9f91-b3feee4be08b@github.com>
 <fNAdydPUEAHLrF8QOUQXXsj9YtVtNIaeWmTT8pdC7Xk=.926a2392-1efe-4154-adcd-289c0f1cbafe@github.com>
Message-ID: <95BWoQiYfM-c7esOvzluxwrXbh_sQD9MAUm9-5JhULc=.c3f1f31e-5b13-4698-9481-e02a763b1ce6@github.com>

On Thu, 3 Oct 2024 05:04:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I see the problem with float/double vectors. Let us do the rearrange form only for Integral (byte, short, int, long) vectors then. For float/double vector we could keep the code that you have currently.
>
> You will also need additional handling for NPOT vector sizes which is handled by existing fallback implementation.

Agree, so we can't assume power of two in fallback.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1786691519

From shade at openjdk.org  Thu Oct  3 18:48:55 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 3 Oct 2024 18:48:55 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v7]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <bj0w7Ne_uiYmwLdiUcItNyFa2GA4hqlMpUZxNZplu74=.8f383fb0-a1dd-4fe4-aed0-b31260b19490@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Reconcile with late barrier expansion in G1
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Review comments
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Also dispatch to slow-path on other arches
 - Fix other arches
 - Tighten up comments in Reference javadoc
 - Attempt at implementing ZGC AArch64 parts
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Amend the test case for guaranteing it works under different compilation regimes
 - ... and 5 more: https://git.openjdk.org/jdk/compare/ebb4759c...c3338302

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

Changes: https://git.openjdk.org/jdk/pull/20139/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=06
  Stats: 372 lines in 25 files changed: 351 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/20139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139

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

From jbhateja at openjdk.org  Thu Oct  3 19:05:14 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 19:05:14 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v16]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Sharpening intrinsic exit check.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/6215ab91..1cca8e24

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

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

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

From prr at openjdk.org  Thu Oct  3 19:04:47 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Oct 2024 19:04:47 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v8]
In-Reply-To: <4y81EJSqbylcEsEo-KkBu14tGWB4R0ysQsT9wHmiqjo=.593642c8-1e39-4410-a3cc-2f52b634ae2e@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <4y81EJSqbylcEsEo-KkBu14tGWB4R0ysQsT9wHmiqjo=.593642c8-1e39-4410-a3cc-2f52b634ae2e@github.com>
Message-ID: <L-TIjqC9sEjEYyAqqHnWRon009ukpffXRBH-uX92BhY=.61f4514e-fb24-4653-b874-72d392ae28a5@github.com>

On Thu, 3 Oct 2024 18:15:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect Phil's review: build tag for PassFailJFrame

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21096#pullrequestreview-2346484426

From jbhateja at openjdk.org  Thu Oct  3 19:13:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 19:13:22 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v20]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <auBsz19_LG_UiHmP2r8gQmCY0-wj-QGYQXZGBDMdE8M=.0ac31bfd-a0b4-4219-85e6-f8a76cc33bef@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Typographic error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/952920ae..f5b5e6f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=18-19

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

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

From psandoz at openjdk.org  Thu Oct  3 19:21:43 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 3 Oct 2024 19:21:43 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v20]
In-Reply-To: <auBsz19_LG_UiHmP2r8gQmCY0-wj-QGYQXZGBDMdE8M=.0ac31bfd-a0b4-4219-85e6-f8a76cc33bef@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <auBsz19_LG_UiHmP2r8gQmCY0-wj-QGYQXZGBDMdE8M=.0ac31bfd-a0b4-4219-85e6-f8a76cc33bef@github.com>
Message-ID: <RS_W7uDGWq3EkfjkFUERraJljQKCXQnYiy5Ap-qhtlY=.e5f53613-0f15-483e-bc05-2e1c8875217f@github.com>

On Thu, 3 Oct 2024 19:13:22 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typographic error

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 46:

> 44:      * @return the smaller of {@code a} and {@code b}.
> 45:      * @see VectorOperators#UMIN
> 46:      * @since 24

Remove `@since 24` in the documentation of each method and place in the documentation on the class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786732581

From attila at openjdk.org  Thu Oct  3 19:31:06 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Thu, 3 Oct 2024 19:31:06 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists [v2]
In-Reply-To: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
Message-ID: <ePXbun_E1H4dUToSlLN9cyBBcA83a_8IWcQI0cF1VW8=.b8c7da5e-6bf1-4cbb-9771-03de25caffae@github.com>

> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
> 
> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.

Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:

  - Rename test to more descriptive
  - Add a test case for whole list sorting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21250/files
  - new: https://git.openjdk.org/jdk/pull/21250/files/43185d7e..e0ae1cc9

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

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

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

From attila at openjdk.org  Thu Oct  3 19:38:36 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Thu, 3 Oct 2024 19:38:36 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <kczPwsVuWWURWOHDrWmwjiqYamMp2X3iUgNnap7AKyk=.57641c1b-5a39-43ab-8d50-8b273e4a5b91@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
 <aIxX6fMnCtQ9eQqUU1Ou32J1J_MgQ5gZUyej0PcRP5M=.fbbeab52-4033-405f-851b-13b0431cdbcc@github.com>
 <B56h2M-9ARx7sZZvfRdJ3Luu5hNCt-U2_DKMmisTcuk=.0d40b2f2-cb84-43f2-af41-1446e3b0b594@github.com>
 <kczPwsVuWWURWOHDrWmwjiqYamMp2X3iUgNnap7AKyk=.57641c1b-5a39-43ab-8d50-8b273e4a5b91@github.com>
Message-ID: <5xPpQ5DHZi66kaoedVymTxjuN3OzeWdWAd0VwS4cqXY=.6e7744dd-91e4-4c50-b3cb-8966dc98aa5f@github.com>

On Tue, 1 Oct 2024 03:26:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> @dholmes-ora and @dfuch both your observations are quite valid and I agree with them. If you look at the [JBS issue](https://bugs.openjdk.org/browse/JDK-8340572), we discussed this topic there. 
>> 
>> Clarifying the collections' behavior with regard to when to throw a CME, and hopefully making that behavior be consistent would be a welcome enhancement. As things stand, the scope of this fix is just ensuring that the behavior of ArrayList reverts back to what it was prior to my optimization, since the change triggered a test failure in some Google test suite. All the while recognizing that the behavior was not particularly consistent to begin with.
>
> @szegedi Thanks for starting this. Just a couple comments on the test.
> 
> 1. It would be good to have a test case that verifies that sorting the entire list **does** increment modcount, in addition to the existing test case that tests that sorting a sublist **does not** increment modcount. (As before, this is arguably not the correct behavior, but it's the behavior that the system exhibited prior to JDK-8325679.)
> 2. It would be good for the test to have a more descriptive name than just the bug ID. Something like SortingModCount or similar would be fine.
> 
> Thanks.

@stuart-marks and @liach thanks, those are good suggestions ? done.

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

PR Comment: https://git.openjdk.org/jdk/pull/21250#issuecomment-2392185387

From jlu at openjdk.org  Thu Oct  3 19:53:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 3 Oct 2024 19:53:43 GMT
Subject: RFR: 8341484: TimeZone.toZoneId() throws exception when using old
 mapping for "HST"
Message-ID: <UnvFa2tl5Dgm0gViyWpN0IOnAV_TF5AxKfBvP782cQ4=.736933d1-33cc-43e3-83bc-090ef5ec4635@github.com>

Please review this PR which fixes an unexpected exception for `TimeZone.toZoneId("HST")` when the old mapping system property is used.

The culprit is in `TimeZone.toZoneId0()`.

This method provides workarounds for "EST", "MST", and "HST" when the old mapping system property is true. However, it seems that "HST" was added with "America/Honolulu" when it should have been "Pacific/Honolulu".

Added a basic test.

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

Commit messages:
 - init

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

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

From jbhateja at openjdk.org  Thu Oct  3 19:55:03 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 19:55:03 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v21]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <59ZQPsSgxrGE2E4vGKs0PvO7KJIJdAhKCkZb8OPv4qI=.7762bee0-fcb0-4ab5-ae29-1069d7d64ca4@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Doc fixups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/f5b5e6f5..3beac2db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=19-20

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

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

From psandoz at openjdk.org  Thu Oct  3 19:55:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 3 Oct 2024 19:55:04 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v21]
In-Reply-To: <59ZQPsSgxrGE2E4vGKs0PvO7KJIJdAhKCkZb8OPv4qI=.7762bee0-fcb0-4ab5-ae29-1069d7d64ca4@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <59ZQPsSgxrGE2E4vGKs0PvO7KJIJdAhKCkZb8OPv4qI=.7762bee0-fcb0-4ab5-ae29-1069d7d64ca4@github.com>
Message-ID: <CDI4nALJMy3cuzF9pYU4IYy0wAdvWYaApYdqgRPku94=.e9426f79-b2af-462f-a7eb-f9545b8a132d@github.com>

On Thu, 3 Oct 2024 19:51:31 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doc fixups

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 30:

> 28:  * The class {@code VectorMath} contains methods for performing
> 29:  * scalar numeric operations in support of vector numeric operations.
> 30:  * @author  Paul Sandoz

We no longer use the `@author` tag on newly added classes, can you please remove it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786769928

From jbhateja at openjdk.org  Thu Oct  3 19:55:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 3 Oct 2024 19:55:04 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v20]
In-Reply-To: <RS_W7uDGWq3EkfjkFUERraJljQKCXQnYiy5Ap-qhtlY=.e5f53613-0f15-483e-bc05-2e1c8875217f@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <auBsz19_LG_UiHmP2r8gQmCY0-wj-QGYQXZGBDMdE8M=.0ac31bfd-a0b4-4219-85e6-f8a76cc33bef@github.com>
 <RS_W7uDGWq3EkfjkFUERraJljQKCXQnYiy5Ap-qhtlY=.e5f53613-0f15-483e-bc05-2e1c8875217f@github.com>
Message-ID: <FcFuMTSu9mgyzFIWQJcp3XQ-MfLgGL9f3Eiqjz6Na0w=.710b4907-131d-440d-89c5-a09e57091b4a@github.com>

On Thu, 3 Oct 2024 19:18:38 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typographic error
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 46:
> 
>> 44:      * @return the smaller of {@code a} and {@code b}.
>> 45:      * @see VectorOperators#UMIN
>> 46:      * @since 24
> 
> Remove `@since 24` in the documentation of each method and place in the documentation on the class.

DONE

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1786767732

From duke at openjdk.org  Thu Oct  3 20:12:42 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 3 Oct 2024 20:12:42 GMT
Subject: RFR: 8341006: Optimize StackMapGenerator detect frames [v3]
In-Reply-To: <LsR8yjmiSQXzTYmbZvkXT9JyIRV8vs80gIVEzTD9nSo=.5ee8372e-7b91-4724-a0fe-42940e674e02@github.com>
References: <0QCy0bW3KXAb-vThPvlUv_tC_Yb2VfplXH9zBIPVU6c=.10deec43-41fa-4429-9882-1eeb8388e1c4@github.com>
 <LsR8yjmiSQXzTYmbZvkXT9JyIRV8vs80gIVEzTD9nSo=.5ee8372e-7b91-4724-a0fe-42940e674e02@github.com>
Message-ID: <XrFYHUQyxNvWM2RkIrfjsivl-IeL537Jdefbb29F_lE=.0dd8452a-57ff-4996-81ae-b6070802d1d6@github.com>

On Thu, 3 Oct 2024 13:15:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> 1. Construct Frames directly without BitSet
>> 2. Use Frame[] instead of ArrayList
>> 3. Use EMPTY_FRAME_ARRAY for initialization. No need to allocate objects when there is no frame.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduce codeSize

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 852:

> 850:     /**
> 851:      * Performs detection of mandatory stack map frames in a single bytecode traversing pass
> 852:      * @return detected frames

`@return` on?`void`?method:
Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21183#discussion_r1786788792

From jlu at openjdk.org  Thu Oct  3 21:02:16 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 3 Oct 2024 21:02:16 GMT
Subject: RFR: 8341445: DecimalFormatSymbols can throw NPE for equals()
In-Reply-To: <7OCCSaGNXW-howL9CvomoTStKSiPC9NBkl5Xe4iz1UM=.84cb711e-da14-45c3-81fd-402c797caafe@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
 <7OCCSaGNXW-howL9CvomoTStKSiPC9NBkl5Xe4iz1UM=.84cb711e-da14-45c3-81fd-402c797caafe@github.com>
Message-ID: <a1XwYYKJxTkLJlt4nvcHPT8dk3ZZUf61XEr6qs-I56U=.b73860b1-2330-413c-a61d-5a9aacad6b92@github.com>

On Thu, 3 Oct 2024 00:48:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols.
>> 
>> DecimalFormatSymbols via its setters, allows certain instance variables to be set as null. (Note that some variables are allowed to be null, and others are not.) However, non null safe comparisons are used for all variables during the equality check. This can lead to an unexpected NPE when `DecimalFormatSymbols.equals()` is invoked.
>> 
>> The nullable variables in question should be equality checked via the static `Object.equals()`. An associated regression test is added to confirm the change.
>
> Should we add an explicit whitelist of methods allowed to throw NPE, so that if we add new getter/setters to DFS, we can avoid this nasty null problem for the future? This whitelist will be validated by tests for sure.

Thanks for taking a look @liach . https://github.com/openjdk/jdk/pull/21315/commits/bd6b021cc84034d55eb6d262ade7ea19e520c1fe adds a test that ensures if a new NPE throwing setter is added without being whitelisted, this test will now fail. This should prevent mishaps like this in the future. While this feels a little overkill, this enforcement is done via a test, so it is fine by me.

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

PR Comment: https://git.openjdk.org/jdk/pull/21315#issuecomment-2392323915

From jlu at openjdk.org  Thu Oct  3 21:02:16 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 3 Oct 2024 21:02:16 GMT
Subject: RFR: 8341445: DecimalFormatSymbols can throw NPE for equals() [v2]
In-Reply-To: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
Message-ID: <e710dGskXiHkLRBCQpuuc0WWjHab84cIaTWPjtsp4a4=.909a2a04-0e27-47d3-80c2-62ee0f1ff280@github.com>

> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols.
> 
> DecimalFormatSymbols via its setters, allows certain instance variables to be set as null. (Note that some variables are allowed to be null, and others are not.) However, non null safe comparisons are used for all variables during the equality check. This can lead to an unexpected NPE when `DecimalFormatSymbols.equals()` is invoked.
> 
> The nullable variables in question should be equality checked via the static `Object.equals()`. An associated regression test is added to confirm the change.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  address Chen's comment - provide a NPE setter whitelist in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21315/files
  - new: https://git.openjdk.org/jdk/pull/21315/files/9bcf8996..bd6b021c

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

  Stats: 74 lines in 2 files changed: 49 ins; 20 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21315/head:pull/21315

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

From sviswanathan at openjdk.org  Thu Oct  3 21:07:40 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 3 Oct 2024 21:07:40 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v16]
In-Reply-To: <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>
Message-ID: <S6s7vF_RYOFLIoRy5J5aqiJP9fM88D6HzKJ2RSARrHI=.4323d103-1ea4-44c0-9b01-a46999070f49@github.com>

On Thu, 3 Oct 2024 19:05:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sharpening intrinsic exit check.

Looks good to me.

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

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2346694947

From brian.burkhalter at oracle.com  Thu Oct  3 21:09:02 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 3 Oct 2024 21:09:02 +0000
Subject: Illegal Seek when using File.newInputStream()
In-Reply-To: <CALexLmG8M9H7s1Ko97bFQE3eK9DZueo2+UhY37X1+sANb+AhuA@mail.gmail.com>
References: <CALexLmGSxcF2k53cpVNX6nJc9=dOLwJac+hGBE3Ma1S0YADA+w@mail.gmail.com>
 <5deb045d-1362-485d-a8d3-5cd9f4c6c8ec@oracle.com>
 <CALexLmGPB1sNfdFd4md7aNwYx3Byc+-DPHTikkk3hmHxWdoxCg@mail.gmail.com>
 <B7B855AC-56A9-48A7-9E51-8CE9194998BC@oracle.com>
 <CALexLmG8M9H7s1Ko97bFQE3eK9DZueo2+UhY37X1+sANb+AhuA@mail.gmail.com>
Message-ID: <8F1755BB-625C-482C-8867-97B1A473FC1E@oracle.com>

Hi Louis,

You?re welome!

It definitely handles the ?/dev/stdin? case. Other possible fixes are also being considered.

The Windows case is yet to be investigated, but if needed, does not have to be part of this issue.

Brian

On Oct 3, 2024, at 11:35?AM, Louis Bergelson <louisb at broadinstitute.org> wrote:

Thanks for looking into this!  That sounds like it would work for my use case.  Anything that returns a result instead of a crash would be a huge improvement.   My main concern is definitely unix/bsd/osx systems, I don't have a good sense of how pipes work on windows or if there is an analogous issue there.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241003/5f98d5c8/attachment-0001.htm>

From duke at openjdk.org  Thu Oct  3 23:34:06 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 3 Oct 2024 23:34:06 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v14]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <F-P4IsqMY18OOj4pQw0FohYGUVYbFdXT09YHf4jiq7k=.4fbf5e5c-eac9-493f-a845-96af9f02c81f@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Removed superfluous condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/6b184be8..62dd7659

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

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

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

From cushon at openjdk.org  Thu Oct  3 23:53:00 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 3 Oct 2024 23:53:00 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v2]
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <opgHOr0g42UIgDxQYf9H3Px_svuNGQOR3ZCsf17AbDw=.7cda0cb7-3f38-4aea-ba2a-9bc793eeb3cb@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 four additional commits since the last revision:

 - 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/6cd4fed2..e8ba518a

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

  Stats: 366039 lines in 4795 files changed: 284117 ins; 54835 del; 27087 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 jbhateja at openjdk.org  Fri Oct  4 00:01:59 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 4 Oct 2024 00:01:59 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v22]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <hTNfN3mdbuIvNUqr1DV48gpKQP-RFOInpRktdAvi1YE=.2804ce60-a7b3-4a49-a3fe-10c8e5e3f2ec@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Update VectorMath.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/3beac2db..550eeb9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=20-21

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

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

From cushon at openjdk.org  Fri Oct  4 00:02:52 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 4 Oct 2024 00:02:52 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v3]
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@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 incrementally with one additional commit since the last revision:

  Migrate another use of sun.misc.Unsafewq

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19397/files
  - new: https://git.openjdk.org/jdk/pull/19397/files/e8ba518a..aa688777

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 swen at openjdk.org  Fri Oct  4 03:44:14 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 03:44:14 GMT
Subject: RFR: 8341510: Optimize StackMapGenerator::processFieldInstructions
Message-ID: <zRQGSq0guyPStgS-gGxFQVnXPeR3_3UrKYa9cy5S1Nw=.5c0aaf70-1f35-4173-a03d-a98dff8caf98@github.com>

A small optimization to reduce CodeSize, codeSize reduced from 164 to 140.

1. Use local currentFrame to avoid multiple getfields
2. Use decStack instead of popStack to reduce array access in popStack
3. Call Util.fieldTypeSymbol to pass in type instead of nameAndType

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

Commit messages:
 - optimize processFieldInstructions

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

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

From liach at openjdk.org  Fri Oct  4 04:13:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 04:13:05 GMT
Subject: RFR: 8341512: Optimize
 StackMapGenerator::processInvokeInstructions
In-Reply-To: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
References: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
Message-ID: <OC_cNanWaq9iEEtXEVEqAPFE5q56xZW2v35Bx1fzPaY=.2ffe50a7-652b-4e33-a9d5-ebe745e26209@github.com>

On Fri, 4 Oct 2024 02:15:51 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization for StackMapGenerator::processInvokeInstructions.
> 
> 1. Use local currentFrame to avoid multiple getfields
> 2. remove Util.methodTypeSymbol(NameAndTypeEntry)
> 3. Use decStack instead of popStack to reduce array access in popStack
> 4. codeSize reduced from 277 to 262

? `equalsString` allows for laziness when we receive a lazy name and type from a class reader.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21344#pullrequestreview-2346987217

From swen at openjdk.org  Fri Oct  4 04:13:05 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 04:13:05 GMT
Subject: RFR: 8341512: Optimize StackMapGenerator::processInvokeInstructions
Message-ID: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>

A small optimization for StackMapGenerator::processInvokeInstructions.

1. Use local currentFrame to avoid multiple getfields
2. remove Util.methodTypeSymbol(NameAndTypeEntry)
3. Use decStack instead of popStack to reduce array access in popStack
4. codeSize reduced from 277 to 262

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

Commit messages:
 - use decStack instead of popStack
 - remove Util.methodTypeSymbol(NameAndTypeEntry)
 - optimize processInvokeInstructions

Changes: https://git.openjdk.org/jdk/pull/21344/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21344&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341512
  Stats: 20 lines in 10 files changed: 1 ins; 7 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21344.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21344/head:pull/21344

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

From liach at openjdk.org  Fri Oct  4 05:01:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 05:01:43 GMT
Subject: RFR: 8341510: Optimize StackMapGenerator::processFieldInstructions
In-Reply-To: <zRQGSq0guyPStgS-gGxFQVnXPeR3_3UrKYa9cy5S1Nw=.5c0aaf70-1f35-4173-a03d-a98dff8caf98@github.com>
References: <zRQGSq0guyPStgS-gGxFQVnXPeR3_3UrKYa9cy5S1Nw=.5c0aaf70-1f35-4173-a03d-a98dff8caf98@github.com>
Message-ID: <L5Vs5L4hs8rx3ocSAisyq8XJ2akkrlKtQX8oEiguj84=.4a941964-ed90-4428-90d6-75256860946e@github.com>

On Fri, 4 Oct 2024 02:47:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce CodeSize, codeSize reduced from 164 to 140.
> 
> 1. Use local currentFrame to avoid multiple getfields
> 2. Use decStack instead of popStack to reduce array access in popStack
> 3. Call Util.fieldTypeSymbol to pass in type instead of nameAndType

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 234:

> 232:     }
> 233: 
> 234:     public static MethodTypeDesc methodTypeSymbol(NameAndTypeEntry nat) {

Can you remove this method too, since we have a Utf8Entry version?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21345#discussion_r1787156100

From swen at openjdk.org  Fri Oct  4 07:07:34 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 07:07:34 GMT
Subject: RFR: 8341510: Optimize StackMapGenerator::processFieldInstructions
In-Reply-To: <L5Vs5L4hs8rx3ocSAisyq8XJ2akkrlKtQX8oEiguj84=.4a941964-ed90-4428-90d6-75256860946e@github.com>
References: <zRQGSq0guyPStgS-gGxFQVnXPeR3_3UrKYa9cy5S1Nw=.5c0aaf70-1f35-4173-a03d-a98dff8caf98@github.com>
 <L5Vs5L4hs8rx3ocSAisyq8XJ2akkrlKtQX8oEiguj84=.4a941964-ed90-4428-90d6-75256860946e@github.com>
Message-ID: <zicWUqNVwQjjZEifQ8EuaHFGFBPKuEVa9toWfpaTjcw=.6108910b-034e-4012-a3cb-f076d27bdf5d@github.com>

On Fri, 4 Oct 2024 04:59:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A small optimization to reduce CodeSize, codeSize reduced from 164 to 140.
>> 
>> 1. Use local currentFrame to avoid multiple getfields
>> 2. Use decStack instead of popStack to reduce array access in popStack
>> 3. Call Util.fieldTypeSymbol to pass in type instead of nameAndType
>
> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 234:
> 
>> 232:     }
>> 233: 
>> 234:     public static MethodTypeDesc methodTypeSymbol(NameAndTypeEntry nat) {
> 
> Can you remove this method too, since we have a Utf8Entry version?

`methodTypeSymbol(NameAndTypeEntry nat) ` This method will be removed in PR #21344

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21345#discussion_r1787255216

From duke at openjdk.org  Fri Oct  4 08:30:53 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 08:30:53 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v15]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <fqLLlCCjysyzZ5MDCyZ9i1WiyFOxLLOBNObCa7q9EJA=.4c6d0886-504e-401c-827a-25e059c10468@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/62dd7659..191310b5

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

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

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

From duke at openjdk.org  Fri Oct  4 08:34:08 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 08:34:08 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v16]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <ga3gw5Rle4o1z2GBkCwKgVGZjDP9iGy4x62OFiGfyZY=.13b1a605-c608-4d77-8256-c99186740755@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/191310b5..0fb7f663

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

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

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

From duke at openjdk.org  Fri Oct  4 08:49:16 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 08:49:16 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v3]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <CPwEDMG3HVP-zohvUJjUomokAZSk7Key3_kF79MxP1M=.77f42130-967d-4d4b-8474-46ef0b1f7224@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:

  Demand overflow checks to checkScale()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/129f79ff..15de892b

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

  Stats: 9 lines in 1 file changed: 0 ins; 7 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 duke at openjdk.org  Fri Oct  4 08:56:58 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 08:56:58 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v4]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <CjuU1mO1MMuHVkM-b14slFcnEDapTBGbVIkgDwq9W50=.671a6552-f821-4250-bf7b-bf1cb8b3f356@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:

  Avoid check for null value of this.intVal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/15de892b..acbe9927

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

  Stats: 5 lines in 1 file changed: 4 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 mbaesken at openjdk.org  Fri Oct  4 09:34:17 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Oct 2024 09:34:17 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v3]
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <h-ayzrZ0RwwhCDppYY5B5cvKLWcISIEAa2wQYBkyvVE=.b412428d-9758-4601-a092-91d69992c87e@github.com>

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  move ub.h to a better location

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21184/files
  - new: https://git.openjdk.org/jdk/pull/21184/files/fb17d1bc..cfbf904b

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

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

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

From duke at openjdk.org  Fri Oct  4 09:34:54 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 09:34:54 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v17]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <qK6wFW8DXsfIBEsskg1uthVW5MLtn-1nfkXgk3qBMlI=.fcff459a-c29c-409f-be90-fa0eb7fbea0d@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Avoid overflow of scale - preferredScale

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/0fb7f663..fd91e7b5

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

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

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

From mcimadamore at openjdk.org  Fri Oct  4 09:51:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Oct 2024 09:51:43 GMT
Subject: Integrated: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline
In-Reply-To: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
References: <h4gEW0rTo1SyNSKE-Tomoq3-87L1PxRlSMI43ryFWyE=.d4056e3e-2583-48ac-8cb5-280d37d6ad49@github.com>
Message-ID: <u88h9OD5rhZv5jI8gA-Krzv4xJNph9UgdoUfW-A3s1g=.eb84a52d-3399-4006-b47e-e9dc5b52ac61@github.com>

On Tue, 1 Oct 2024 10:08:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The fix for JDK-8331865 introduced an accidental performance regression.
> The main issue is that now *all* memory segment var handles go through some round of adaptation.
> Adapting a var handle results in a so called *indirect* var handle.
> When an indirect var handle is called through a *var handle guard*, an extra `MethodHandle::asType` call is triggered.
> In some cases, if `asType` has already been compiled into a big method, it cannot be inlined into the caller, which then results in a failure to inline through the var handle call, resulting in a big performance regression.
> 
> The solution is to make sure that the compiled size of `MethodHandle::asType` stays small: this is done by making sure that the slowpath (the one which populates the cache used by `asType`) is not inlined by the JVM. This is done by consolidating the slow path into a separate method, which is annotated with the internal `@DontInline` annotation.
> 
> This problem was originally reported here:
> https://mail.openjdk.org/pipermail/panama-dev/2024-September/020643.html
> 
> While we did not test this fix directly, we have made sure that running the problematic benchmark with the flags:
> 
> 
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.setAsTypeCache
> -XX:CompileCommand=dontinline,java/lang/invoke/MethodHandle.asTypeUncached
> 
> 
> Solves the performance regression. The fix in this PR is just a programmatic way to achieve the same results w/o the need of command line flags.

This pull request has now been integrated.

Changeset: 7fa2f229
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fa2f229fbee68112cbdd18b811d95721adfe2ec
Stats:     152 lines in 2 files changed: 150 ins; 0 del; 2 mod

8341127: Extra call to MethodHandle::asType from memory segment var handles fails to inline

Reviewed-by: psandoz, redestad, jvernee

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

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

From mcimadamore at openjdk.org  Fri Oct  4 09:59:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Oct 2024 09:59:12 GMT
Subject: [jdk23] RFR: 8341127: Extra call to MethodHandle::asType from memory
 segment var handles fails to inline
Message-ID: <XRSxJL994CDr2e8NmJMVOnFJlGsK4lZ4eIqfE39htbA=.a14012a2-0015-4867-a4e4-84e7020ad1d4@github.com>

8341127: Extra call to MethodHandle::asType from memory segment var handles fails to inline

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

Commit messages:
 - Backport 7fa2f229fbee68112cbdd18b811d95721adfe2ec

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

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

From mbaesken at openjdk.org  Fri Oct  4 09:59:36 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Oct 2024 09:59:36 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]
In-Reply-To: <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
 <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>
Message-ID: <IR0dA-bTA0CD20pN_5MSNq5lBL0X68IOw_PtoYWywZg=.a7d3bc58-b1e0-45df-868c-3816df91aa3a@github.com>

On Wed, 2 Oct 2024 20:29:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think you could probably place ub.h along-side jni_util.h in that directory.

I moved the header to the better location.

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

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2393323469

From mcimadamore at openjdk.org  Fri Oct  4 10:41:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Oct 2024 10:41:42 GMT
Subject: [jdk23] Withdrawn: 8341127: Extra call to MethodHandle::asType from
 memory segment var handles fails to inline
In-Reply-To: <XRSxJL994CDr2e8NmJMVOnFJlGsK4lZ4eIqfE39htbA=.a14012a2-0015-4867-a4e4-84e7020ad1d4@github.com>
References: <XRSxJL994CDr2e8NmJMVOnFJlGsK4lZ4eIqfE39htbA=.a14012a2-0015-4867-a4e4-84e7020ad1d4@github.com>
Message-ID: <YSWOBVCY6_4EasQwQfRm2h24_XyOS3IA6nfyfwZhuWE=.19ea8630-5cd8-4b6c-b437-6ada04c54a02@github.com>

On Fri, 4 Oct 2024 09:52:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a clean backport of https://git.openjdk.org/jdk/pull/21283

This pull request has been closed without being integrated.

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

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

From rgiulietti at openjdk.org  Fri Oct  4 12:31:35 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 12:31:35 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v17]
In-Reply-To: <qK6wFW8DXsfIBEsskg1uthVW5MLtn-1nfkXgk3qBMlI=.fcff459a-c29c-409f-be90-fa0eb7fbea0d@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <qK6wFW8DXsfIBEsskg1uthVW5MLtn-1nfkXgk3qBMlI=.fcff459a-c29c-409f-be90-fa0eb7fbea0d@github.com>
Message-ID: <rrIdw4GGZ9-NqcuXIpc6maMEVVJkHEmoc_yhKqq0yAk=.2f22cb6b-9e1c-443c-9932-dbc8a2d0d366@github.com>

On Fri, 4 Oct 2024 09:34:54 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid overflow of scale - preferredScale

@fabioromano1 I'll have a look once the commits settle down to something you consider stable for review.

Also, please add [JMH](https://github.com/openjdk/jmh) benchmark results with and without your changes. The benchmarks should target some public API point, like `stripTrailingZeros()`, not internal methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/21323#issuecomment-2393596438

From rgiulietti at openjdk.org  Fri Oct  4 12:37:36 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 12:37:36 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v17]
In-Reply-To: <qK6wFW8DXsfIBEsskg1uthVW5MLtn-1nfkXgk3qBMlI=.fcff459a-c29c-409f-be90-fa0eb7fbea0d@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <qK6wFW8DXsfIBEsskg1uthVW5MLtn-1nfkXgk3qBMlI=.fcff459a-c29c-409f-be90-fa0eb7fbea0d@github.com>
Message-ID: <3gxX-a2AFkSHhe9ilE0hbOG7J3Lij_XHx9UJWN50Z9o=.98535ec5-65a9-4679-b408-6e9e017a35ba@github.com>

On Fri, 4 Oct 2024 09:34:54 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid overflow of scale - preferredScale

FYI, [Rampdown Phase One for JDK 24](https://openjdk.org/projects/jdk/24/) will happen on 2024-12-05, so there's no need to rush.

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

PR Comment: https://git.openjdk.org/jdk/pull/21323#issuecomment-2393608060

From duke at openjdk.org  Fri Oct  4 12:50:37 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 12:50:37 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v17]
In-Reply-To: <rrIdw4GGZ9-NqcuXIpc6maMEVVJkHEmoc_yhKqq0yAk=.2f22cb6b-9e1c-443c-9932-dbc8a2d0d366@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <qK6wFW8DXsfIBEsskg1uthVW5MLtn-1nfkXgk3qBMlI=.fcff459a-c29c-409f-be90-fa0eb7fbea0d@github.com>
 <rrIdw4GGZ9-NqcuXIpc6maMEVVJkHEmoc_yhKqq0yAk=.2f22cb6b-9e1c-443c-9932-dbc8a2d0d366@github.com>
Message-ID: <KukKonzPHd-vIWFX0G8I4g4iQqGJGiThzNwC8Dl8Je4=.cc86a88f-d3f8-46cb-a291-5d4e39947e30@github.com>

On Fri, 4 Oct 2024 12:28:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> @fabioromano1 I'll have a look once the commits settle down to something you consider stable for review.

@rgiulietti I think the code is already stable enough now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21323#issuecomment-2393631222

From swen at openjdk.org  Fri Oct  4 14:06:11 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 14:06:11 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v2]
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <Dgrwg7iTM4zBdhEEaHFZGJSCUtOhOsLTViOSzImTQ8s=.53a4a21d-895f-458d-b2cb-9d4d2ddec14c@github.com>

> Reduce code size by combining calls and defining local variables

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - reduce codeSize
 - reduce codeSize
 - decStack & stackUnderflow
 - fix merge error
 - Merge branch 'master' into optim_stack_map_gen_202408
 - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - fix merge error
 - Merge remote-tracking branch 'origin/optim_stack_map_gen_202408' into optim_stack_map_gen_202408
 - optimize for codeSize
 - ... and 3 more: https://git.openjdk.org/jdk/compare/3f420fac...b647a4b5

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

Changes: https://git.openjdk.org/jdk/pull/20756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=01
  Stats: 363 lines in 2 files changed: 225 ins; 39 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20756/head:pull/20756

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

From duke at openjdk.org  Fri Oct  4 14:06:11 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 4 Oct 2024 14:06:11 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v2]
In-Reply-To: <Dgrwg7iTM4zBdhEEaHFZGJSCUtOhOsLTViOSzImTQ8s=.53a4a21d-895f-458d-b2cb-9d4d2ddec14c@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
 <Dgrwg7iTM4zBdhEEaHFZGJSCUtOhOsLTViOSzImTQ8s=.53a4a21d-895f-458d-b2cb-9d4d2ddec14c@github.com>
Message-ID: <nnQIYl-Pn0p_SFC5a3oacFo9wRPRFBmXsVqhxFpUqrw=.0bd18941-2d7f-4c62-92e8-d8034e6f423b@github.com>

On Fri, 4 Oct 2024 14:03:20 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Reduce code size by combining calls and defining local variables
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - reduce codeSize
>  - reduce codeSize
>  - decStack & stackUnderflow
>  - fix merge error
>  - Merge branch 'master' into optim_stack_map_gen_202408
>  - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>  - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>  - fix merge error
>  - Merge remote-tracking branch 'origin/optim_stack_map_gen_202408' into optim_stack_map_gen_202408
>  - optimize for codeSize
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/3f420fac...b647a4b5

Typo (`Lcals`???`Locals`):

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1090:

> 1088:             if (index >= frameMaxLocals) frameMaxLocals = index + 1;
> 1089:             if (locals == null) {
> 1090:                 initLcals(index);

Suggestion:

                initLocals(index);

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1097:

> 1095:         }
> 1096: 
> 1097:         private void initLcals(int index) {

Suggestion:

        private void initLocals(int index) {

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

PR Review: https://git.openjdk.org/jdk/pull/20756#pullrequestreview-2274345739
PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1740079730
PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1740079772

From liach at openjdk.org  Fri Oct  4 14:06:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 14:06:12 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <y5BRyrxwxThkU8sXOUiZK0umj9NSSami4WL1_97RCcw=.2dc82e6f-2944-4a24-9364-312b2e41d716@github.com>

On Wed, 28 Aug 2024 22:20:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Reduce code size by combining calls and defining local variables

Can you fix the merge conflicts?

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

PR Comment: https://git.openjdk.org/jdk/pull/20756#issuecomment-2372834014

From duke at openjdk.org  Fri Oct  4 14:03:45 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 4 Oct 2024 14:03:45 GMT
Subject: RFR: 8341512: Optimize
 StackMapGenerator::processInvokeInstructions
In-Reply-To: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
References: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
Message-ID: <dCxz-_0imQxB_cLPurNI8y129w1QbB4iC5Z-k0n6j24=.12abe71b-bc78-4b05-86d7-11b32f16046d@github.com>

On Fri, 4 Oct 2024 02:15:51 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization for StackMapGenerator::processInvokeInstructions.
> 
> 1. Use local currentFrame to avoid multiple getfields
> 2. remove Util.methodTypeSymbol(NameAndTypeEntry)
> 3. Use decStack instead of popStack to reduce array access in popStack
> 4. codeSize reduced from 277 to 262

src/java.base/share/classes/java/lang/classfile/attribute/EnclosingMethodAttribute.java line 95:

> 93:      */
> 94:     default Optional<MethodTypeDesc> enclosingMethodTypeSymbol() {
> 95:         return enclosingMethod().map(NameAndTypeEntry::type).map(Util::methodTypeSymbol);

Maybe?call `enclosingMethodType()` here so?that the?`NameAndTypeEntry::type` lambda?class doesn?t?get spun?up?twice:
Suggestion:

        return enclosingMethodType().map(Util::methodTypeSymbol);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21344#discussion_r1787764793

From duke at openjdk.org  Fri Oct  4 14:12:16 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 14:12:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v18]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <AYqkYLJG4r9fi2x1HvLLpiL_mHKyLRIhOhYr0qiCmm4=.d615b64f-3017-43a5-9a1a-b5b423bae64f@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

 - Merge branch 'patchStripTrailingZeros' of https://github.com/fabioromano1/jdk into patchStripTrailingZeros
 - Added benchmark tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/fd91e7b5..305c3f5e

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

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

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

From swen at openjdk.org  Fri Oct  4 14:25:09 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 14:25:09 GMT
Subject: RFR: 8341512: Optimize
 StackMapGenerator::processInvokeInstructions [v2]
In-Reply-To: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
References: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
Message-ID: <73JIkxy7m8dCQUrJFIqCOmI1R059BlDTntNHkVTJQc8=.7acce97f-805e-4708-a827-ea29455cf6f4@github.com>

> A small optimization for StackMapGenerator::processInvokeInstructions.
> 
> 1. Use local currentFrame to avoid multiple getfields
> 2. remove Util.methodTypeSymbol(NameAndTypeEntry)
> 3. Use decStack instead of popStack to reduce array access in popStack
> 4. codeSize reduced from 277 to 262

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/classfile/attribute/EnclosingMethodAttribute.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21344/files
  - new: https://git.openjdk.org/jdk/pull/21344/files/ebf280ec..eea92640

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

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

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

From acobbs at openjdk.org  Fri Oct  4 14:29:36 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 4 Oct 2024 14:29:36 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
Message-ID: <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>

On Thu, 3 Oct 2024 17:11:09 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> 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 5238:

> 5236:             BigInteger pow = FIVE_TO_2_TO[FIVE_TO_2_TO_LEN - 1];
> 5237:             for (int i = FIVE_TO_2_TO_LEN; i <= n; i++)
> 5238:                 FIVE_TO_2_TO[i] = pow = pow.multiply(pow);

Drive-by comment... apologies if I'm missing some subtle context. Doesn't this raciness create a bug? The field `FIVE_TO_2_TO_LEN` is read multiple times, and other threads could be incrementing it while this code executes, which would lead to an incorrect value for `pow`, etc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1786580894

From aefimov at openjdk.org  Fri Oct  4 15:14:52 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 4 Oct 2024 15:14:52 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v10]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <fdgkRCiqgeb3S2mBfLPwwnkjfS0f2yp558BhAF-TmkA=.8b5862cb-0218-495e-b77c-86cee92a7984@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  improve reporting for unrecoverable exceptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/793cfda3..5177a885

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

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

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

From aefimov at openjdk.org  Fri Oct  4 15:14:52 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 4 Oct 2024 15:14:52 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v9]
In-Reply-To: <LKxjEdW30-Ftwl9OaAk3PTeH2DIozenA2W4YOubxCZI=.7acbb4e5-f367-44da-87bc-d98c45baf411@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <LKxjEdW30-Ftwl9OaAk3PTeH2DIozenA2W4YOubxCZI=.7acbb4e5-f367-44da-87bc-d98c45baf411@github.com>
Message-ID: <cjxKtHuaOgbq8hwoFsQq6fsmahK0cB3lRUvLInsjWaQ=.a31a3bde-e4f3-475c-9351-0b470189fbf8@github.com>

On Wed, 2 Oct 2024 13:38:17 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment suggested by Daniel

That is a correct observation that if `PortUnreachableException` is thrown during first query or between retry attempts we could loose a part of needed timeout per-server, and it could be hidden by previous timeout exceptions. The lost timeout cannot be compensated for such cases. What we can do, is to improve the exception reporting:
 - if we have only one server - we set `PortUnreachableException` as a main exception. Even if the recoverable exceptions, like `TimeoutException`, were observed before.
 - if we have multiple servers we add `PortUnreachableException` as suppressed exception to an exception observed first.
 
Pushed the exception reporting change as 5177a8856f678bd5a721a0c058ec3dfe79addfa0.

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

PR Comment: https://git.openjdk.org/jdk/pull/20892#issuecomment-2393928511

From eirbjo at openjdk.org  Fri Oct  4 15:38:39 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 4 Oct 2024 15:38:39 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
Message-ID: <4pgmpX1RXrMF9PIE-HWvikkM2XGqKxsGTj9u1ktImnk=.5ea30930-50e8-4e4c-bc39-3d18521c1236@github.com>

On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s 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 ziperror-deprecation
>  - Simplify the deprecation note by focusing on behavior in the current release
>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>  - Update copyright year
>  - Deprecate java.util.zip.ZipError for removal

The CSR has been approved to mark `java.util.zip.ZipError` deprecated, for removal with spec changes identical to the current state of this PR.

I plan to integrate this early next week. Just in case there are still any lingering concerns. 

Thanks for all the patient reviews and comments, here and in the CSR!

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

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2393975006

From swen at openjdk.org  Fri Oct  4 15:56:36 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 15:56:36 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v3]
In-Reply-To: <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
 <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>
Message-ID: <j-pat-xTmKWbtrJPGFU2Gi3d-OLTr0kjQILeT8solj8=.b6860a42-38f7-4d94-be24-2485482ff9b8@github.com>

On Wed, 25 Sep 2024 01:10:04 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - inflateNonAscii
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Merge remote-tracking branch 'origin/optim_class_file_pool_inflat_202408' into optim_class_file_pool_inflat_202408
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - optimize Utf8EntryImpl inflate
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Suggestions from @liach
>  - fix build error
>  - optimize Utf8EntryImpl inflate

javap -c -p -v jdk.internal.classfile.impl.AbstractPoolEntry.Utf8EntryImpl

>From the output of javap, we can see that the code size of inflateNonAscii is 408

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

PR Comment: https://git.openjdk.org/jdk/pull/20767#issuecomment-2394008065

From liach at openjdk.org  Fri Oct  4 16:11:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 16:11:40 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v3]
In-Reply-To: <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
 <MzDufO428Qk4fIGXYRU4Q1YoqFG6MpHcJQs5Lcs0TFQ=.463d1d36-5652-4736-bc90-84da4ed03236@github.com>
Message-ID: <Bn1ZAiE0kA25f2v0aG4hB8fzzJWyNQjAZLCLTeFB7wU=.96dad742-35a2-44d9-9361-98e28483f86c@github.com>

On Wed, 25 Sep 2024 01:10:04 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - inflateNonAscii
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Merge remote-tracking branch 'origin/optim_class_file_pool_inflat_202408' into optim_class_file_pool_inflat_202408
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - optimize Utf8EntryImpl inflate
>  - Merge remote-tracking branch 'upstream/master' into optim_class_file_pool_inflat_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>  - Suggestions from @liach
>  - fix build error
>  - optimize Utf8EntryImpl inflate

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 257:

> 255:         }
> 256: 
> 257:         private void inflateNonAscii(int singleBytes, int hash) throws ConstantPoolException {

Suggestion:

        private void inflateNonAscii(int singleBytes, int hash) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20767#discussion_r1787935791

From swen at openjdk.org  Fri Oct  4 16:11:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 16:11:38 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v18]
In-Reply-To: <AYqkYLJG4r9fi2x1HvLLpiL_mHKyLRIhOhYr0qiCmm4=.d615b64f-3017-43a5-9a1a-b5b423bae64f@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <AYqkYLJG4r9fi2x1HvLLpiL_mHKyLRIhOhYr0qiCmm4=.d615b64f-3017-43a5-9a1a-b5b423bae64f@github.com>
Message-ID: <MMhrPmfaAf2-xuFf7fZNLTrddOW1DYnJ3BE9eEFTj9k=.5ac42e70-92a5-47d0-ac79-4e4d9898374f@github.com>

On Fri, 4 Oct 2024 14:12:16 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'patchStripTrailingZeros' of https://github.com/fabioromano1/jdk into patchStripTrailingZeros
>  - Added benchmark tests

Expand the length of FIVE_TO_2_TO to 32 and use `& 0x1F` when accessing the array to eliminate bounds checks.

private static final BigInteger[] FIVE_TO_2_TO = new BigInteger[32];

    private static BigInteger fiveToTwoToThe(int n) {
        if (n >= FIVE_TO_2_TO_LEN) {
            BigInteger pow = FIVE_TO_2_TO[(FIVE_TO_2_TO_LEN - 1) & 0x1F];
            for (int i = FIVE_TO_2_TO_LEN; i <= n; i++)
                FIVE_TO_2_TO[i & 0x1F] = pow = pow.multiply(pow);

            FIVE_TO_2_TO_LEN = n + 1;
        }

        return FIVE_TO_2_TO[n & 0x1F];
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/21323#issuecomment-2394034730

From prappo at openjdk.org  Fri Oct  4 16:35:44 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 4 Oct 2024 16:35:44 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v5]
In-Reply-To: <5sDVx0XJrcqybukBtqIWjVtRowbOK1ssyRttAJ9vxaI=.38a0c9ff-cef2-4442-a1ec-364753271ef4@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
 <5sDVx0XJrcqybukBtqIWjVtRowbOK1ssyRttAJ9vxaI=.38a0c9ff-cef2-4442-a1ec-364753271ef4@github.com>
Message-ID: <V1IPsW-mbDIBmFlyAM5Orycdsp9qrGOFcWJRaC_W1JY=.58042904-8e0a-40ab-b344-dfa7b162ca7f@github.com>

On Mon, 23 Sep 2024 21:03:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix javadoc test failure
>
> test/langtools/jdk/javadoc/doclet/testRestricted/TestRestricted.java line 45:
> 
>> 43:     public static void main(String... args) throws Exception {
>> 44:         var tester = new TestRestricted();
>> 45:         tester.setAutomaticCheckLinks(false);
> 
> @hns I had to disable this check because otherwise the test framework will attempt (and fail) to resolve `../java.base/java/lang/doc-files/RestrictedMethods.html`. Is there a better way to do this w/o disabling the link checks?

I'm not Hannes, but to my mind, the fact that you had to disable that check to make the test pass hints that it's a real problem rather than a minor inconvenience.

Basing this URL off `{@docRoot}` seems an incorrect thing to do:

    doclet.Restricted.url={@docRoot}/java.base/java/lang/doc-files/RestrictedMethods.html

It will only be `@docRoot` in the JDK, but not in any other code base, and certainly not in that test.

I don't know if restricted methods is a JDK-only feature, but for javadoc's sake, we should treat it like it's not. So the link should go to the same place where `{@link Object}` goes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1787962609

From rgiulietti at openjdk.org  Fri Oct  4 16:37:39 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 16:37:39 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v18]
In-Reply-To: <MMhrPmfaAf2-xuFf7fZNLTrddOW1DYnJ3BE9eEFTj9k=.5ac42e70-92a5-47d0-ac79-4e4d9898374f@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <AYqkYLJG4r9fi2x1HvLLpiL_mHKyLRIhOhYr0qiCmm4=.d615b64f-3017-43a5-9a1a-b5b423bae64f@github.com>
 <MMhrPmfaAf2-xuFf7fZNLTrddOW1DYnJ3BE9eEFTj9k=.5ac42e70-92a5-47d0-ac79-4e4d9898374f@github.com>
Message-ID: <T_JvYHHawj1z2ITi_i98Vt2DGEvfkiEMlCvlWVFWA8s=.9c092232-4f98-4966-ad58-343791ddac96@github.com>

On Fri, 4 Oct 2024 16:09:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'patchStripTrailingZeros' of https://github.com/fabioromano1/jdk into patchStripTrailingZeros
>>  - Added benchmark tests
>
> Expand the length of FIVE_TO_2_TO to 32 and use `& 0x1F` when accessing the array to eliminate bounds checks.
> 
> private static final BigInteger[] FIVE_TO_2_TO = new BigInteger[32];  // 30 -> 32
> 
> 
>     private static BigInteger fiveToTwoToThe(int n) {
>         if (n >= FIVE_TO_2_TO_LEN) {
>             BigInteger pow = FIVE_TO_2_TO[(FIVE_TO_2_TO_LEN - 1) & 0x1F]; // & 0x1F eliminate bounds checks.
>             for (int i = FIVE_TO_2_TO_LEN; i <= n; i++)
>                 FIVE_TO_2_TO[i & 0x1F] = pow = pow.multiply(pow); // & 0x1F eliminate bounds checks.
> 
>             FIVE_TO_2_TO_LEN = n + 1;
>         }
> 
>         return FIVE_TO_2_TO[n & 0x1F]; // & 0x1F eliminate bounds checks.
>     }

@wenshao I don't think it makes any practical difference in performance, and the code becomes a bit more convoluted. The need for comments to enlighten the reader is suspicious.

These tricks are great in time critical code, but IMO this is not the case here.

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

PR Comment: https://git.openjdk.org/jdk/pull/21323#issuecomment-2394076573

From mcimadamore at openjdk.org  Fri Oct  4 16:41:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Oct 2024 16:41:36 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v5]
In-Reply-To: <V1IPsW-mbDIBmFlyAM5Orycdsp9qrGOFcWJRaC_W1JY=.58042904-8e0a-40ab-b344-dfa7b162ca7f@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
 <5sDVx0XJrcqybukBtqIWjVtRowbOK1ssyRttAJ9vxaI=.38a0c9ff-cef2-4442-a1ec-364753271ef4@github.com>
 <V1IPsW-mbDIBmFlyAM5Orycdsp9qrGOFcWJRaC_W1JY=.58042904-8e0a-40ab-b344-dfa7b162ca7f@github.com>
Message-ID: <XISo3CxxiBxzpsGWCoFoHoezeOBm2AV_crKV4bC-tF4=.f3363bcc-b632-4327-8fac-29a69eb21adf@github.com>

On Fri, 4 Oct 2024 16:32:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> It will only be `@docRoot` in the JDK, but not in any other code base, and certainly not in that test.

Note: only JDK is allowed to have restricted methods. `@Restricted` is a non-exported JDK annotation. So 3rd party libraries cannot define restricted methods. So, how to render the javadoc for restricted methods is "our own" issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1787971401

From swen at openjdk.org  Fri Oct  4 16:53:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 16:53:50 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v4]
In-Reply-To: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
Message-ID: <xRdJYn2wpcpaPceGf_PoQzJH7-JQnCrwtdlF9egaoBg=.5f0fa775-c45b-4efa-93e2-baf30f46e8ad@github.com>

> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20767/files
  - new: https://git.openjdk.org/jdk/pull/20767/files/8b3c67da..f8cdfa77

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

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

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

From duke at openjdk.org  Fri Oct  4 17:06:41 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 17:06:41 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
Message-ID: <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>

On Thu, 3 Oct 2024 17:15:34 GMT, Archie Cobbs <acobbs 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 5238:
> 
>> 5236:             BigInteger pow = FIVE_TO_2_TO[FIVE_TO_2_TO_LEN - 1];
>> 5237:             for (int i = FIVE_TO_2_TO_LEN; i <= n; i++)
>> 5238:                 FIVE_TO_2_TO[i] = pow = pow.multiply(pow);
> 
> Drive-by comment... apologies if I'm missing some subtle context. Doesn't this raciness create a bug? The field `FIVE_TO_2_TO_LEN` is read multiple times, and other threads could be incrementing it while this code executes, which would lead to an incorrect value for `pow`, etc.

@archiecobbs AFAIK, the documentation of `BigDecimal` does not specify that the class is thread-safe, but I could be wrong...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788012854

From swen at openjdk.org  Fri Oct  4 17:06:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 17:06:50 GMT
Subject: RFR: 8341548: More concise use of classfile API
Message-ID: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>

java.base should provide best practices for Class File API

1. Use fluent coding style
2. Use aconst_null instead of oadConstant(null)
3. use astore intead of 'storeLocal(REFERENCE'
4. use aload instead of 'loadLocal(REFERENCE'
5. 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(LONG)'

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

Commit messages:
 - Update src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java
 - remove empty line
 - 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(LONG)''
 - MethodHandleProxies More concise use of classfile API
 - InnerClassLambdaMetafactory More concise use of classfile API
 - BindingSpecializer More concise use of classfile API
 - SwitchBootstraps more concise use of classfile API
 - More concise use of classfile API

Changes: https://git.openjdk.org/jdk/pull/21355/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21355&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341548
  Stats: 326 lines in 5 files changed: 1 ins; 21 del; 304 mod
  Patch: https://git.openjdk.org/jdk/pull/21355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21355/head:pull/21355

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

From swen at openjdk.org  Fri Oct  4 17:06:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 17:06:50 GMT
Subject: RFR: 8341548: More concise use of classfile API
In-Reply-To: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
References: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
Message-ID: <kt-C5wulKJebeHPduQbFSsaGiNyHwWUGvg_20ZBefN8=.9f2c5c6f-5fde-4440-97b7-1cbdfe6171f5@github.com>

On Fri, 4 Oct 2024 12:05:02 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> java.base should provide best practices for Class File API
> 
> 1. Use fluent coding style
> 2. Use aconst_null instead of oadConstant(null)
> 3. use astore intead of 'storeLocal(REFERENCE'
> 4. use aload instead of 'loadLocal(REFERENCE'
> 5. 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(LONG)'

Using a fluent coding style can reduce the code size, such as the following code


import java.lang.classfile.CodeBuilder;

public class Demo {
   public static void f0(CodeBuilder cb) {
      cb.aload(0);
      cb.aload(1);
   }

   public static void f1(CodeBuilder cb) {
      cb.aload(0)
        .aload(1);
   }
}


Compile Java code and view bytecode

javac --enable-preview --release 24 Demo.java
javap -c Demo 


The bytecode is as follows


public class Demo {
  public Demo();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void f0(java.lang.classfile.CodeBuilder);
    Code:
       0: aload_0
       1: iconst_0
       2: invokeinterface #7,  2            // InterfaceMethod java/lang/classfile/CodeBuilder.aload:(I)Ljava/lang/classfile/CodeBuilder;
       7: pop
       8: aload_0
       9: iconst_1
      10: invokeinterface #7,  2            // InterfaceMethod java/lang/classfile/CodeBuilder.aload:(I)Ljava/lang/classfile/CodeBuilder;
      15: pop
      16: return

  public static void f1(java.lang.classfile.CodeBuilder);
    Code:
       0: aload_0
       1: iconst_0
       2: invokeinterface #7,  2            // InterfaceMethod java/lang/classfile/CodeBuilder.aload:(I)Ljava/lang/classfile/CodeBuilder;
       7: iconst_1
       8: invokeinterface #7,  2            // InterfaceMethod java/lang/classfile/CodeBuilder.aload:(I)Ljava/lang/classfile/CodeBuilder;
      13: pop
      14: return
}


We can see that method `f0` does not use the fluent code style, and the generated bytecode has redundant pop and aload_0 operations.

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

PR Comment: https://git.openjdk.org/jdk/pull/21355#issuecomment-2393963891

From duke at openjdk.org  Fri Oct  4 17:06:50 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 4 Oct 2024 17:06:50 GMT
Subject: RFR: 8341548: More concise use of classfile API
In-Reply-To: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
References: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
Message-ID: <O7_38bMPuPiPEJ2zuN4Bgiqm4oupbiwYF0EWXSNTFuc=.f0b3e03f-0302-45e5-bfaf-74f632a7de8a@github.com>

On Fri, 4 Oct 2024 12:05:02 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> java.base should provide best practices for Class File API
> 
> 1. Use fluent coding style
> 2. Use aconst_null instead of oadConstant(null)
> 3. use astore intead of 'storeLocal(REFERENCE'
> 4. use aload instead of 'loadLocal(REFERENCE'
> 5. 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(LONG)'

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 399:

> 397:                    // call ensureOriginalLookup to verify the given Lookup has access
> 398:                    .aload(1)
> 399:                    .invokestatic(proxyDesc, "ensureOriginalLookup", MTD_void_Lookup)

Since this?class?has the?`ENSURE_ORIGINAL_LOOKUP` constant, it?might be?better to?use?it?here:

Suggestion:

                   .invokestatic(proxyDesc, ENSURE_ORIGINAL_LOOKUP, MTD_void_Lookup)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21355#discussion_r1787778114

From duke at openjdk.org  Fri Oct  4 17:09:37 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 17:09:37 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v18]
In-Reply-To: <MMhrPmfaAf2-xuFf7fZNLTrddOW1DYnJ3BE9eEFTj9k=.5ac42e70-92a5-47d0-ac79-4e4d9898374f@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <AYqkYLJG4r9fi2x1HvLLpiL_mHKyLRIhOhYr0qiCmm4=.d615b64f-3017-43a5-9a1a-b5b423bae64f@github.com>
 <MMhrPmfaAf2-xuFf7fZNLTrddOW1DYnJ3BE9eEFTj9k=.5ac42e70-92a5-47d0-ac79-4e4d9898374f@github.com>
Message-ID: <-TplPXugefbykAI0yA9Z1CkFgx_w6sThiuEYYIBJKOg=.98776409-81b7-4738-8829-8f0faa7c8df7@github.com>

On Fri, 4 Oct 2024 16:09:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'patchStripTrailingZeros' of https://github.com/fabioromano1/jdk into patchStripTrailingZeros
>>  - Added benchmark tests
>
> Expand the length of FIVE_TO_2_TO to 32 and use `& 0x1F` when accessing the array to eliminate bounds checks.
> 
> private static final BigInteger[] FIVE_TO_2_TO = new BigInteger[32];  // 30 -> 32
> 
> 
>     private static BigInteger fiveToTwoToThe(int n) {
>         if (n >= FIVE_TO_2_TO_LEN) {
>             BigInteger pow = FIVE_TO_2_TO[(FIVE_TO_2_TO_LEN - 1) & 0x1F]; // & 0x1F eliminate bounds checks.
>             for (int i = FIVE_TO_2_TO_LEN; i <= n; i++)
>                 FIVE_TO_2_TO[i & 0x1F] = pow = pow.multiply(pow); // & 0x1F eliminate bounds checks.
> 
>             FIVE_TO_2_TO_LEN = n + 1;
>         }
> 
>         return FIVE_TO_2_TO[n & 0x1F]; // & 0x1F eliminate bounds checks.
>     }

@wenshao The method `fiveToTwoToThe(int n)` assumes that the value of `n` is correct, so the bounds checks are left to the caller anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/21323#issuecomment-2394169443

From acobbs at openjdk.org  Fri Oct  4 17:14:36 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 4 Oct 2024 17:14:36 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
Message-ID: <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>

On Fri, 4 Oct 2024 17:03:38 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 5238:
>> 
>>> 5236:             BigInteger pow = FIVE_TO_2_TO[FIVE_TO_2_TO_LEN - 1];
>>> 5237:             for (int i = FIVE_TO_2_TO_LEN; i <= n; i++)
>>> 5238:                 FIVE_TO_2_TO[i] = pow = pow.multiply(pow);
>> 
>> Drive-by comment... apologies if I'm missing some subtle context. Doesn't this raciness create a bug? The field `FIVE_TO_2_TO_LEN` is read multiple times, and other threads could be incrementing it while this code executes, which would lead to an incorrect value for `pow`, etc.
>
> @archiecobbs AFAIK, the documentation of `BigDecimal` does not specify that the class is thread-safe, but I could be wrong...

@fabioromano1, this is a static method manipulating static fields that are shared by all instances; whether individual instances are thread safe is a separate and unrelated issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788027181

From hannesw at openjdk.org  Fri Oct  4 17:14:37 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Oct 2024 17:14:37 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v6]
In-Reply-To: <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
Message-ID: <eiZXDoIEB_Rb6uyPfSQFX3nyewuHlGRGQafv7RXBLi4=.a129f774-849b-48d5-85b3-28b1d3c3f4f9@github.com>

On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix paths to links

The JavaDoc parts mostly look good, but a few details about how the doc file path is created can be improved. Since I'm more familiar with the code I could contribute the changes. Alternatively, I can help with any questions.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 427:

> 425: doclet.PreviewTrailingNote1=Programs can only use {0} when preview features are enabled.
> 426: doclet.PreviewTrailingNote2=Preview features may be removed in a future release, or upgraded to permanent features of the Java platform.
> 427: doclet.Restricted.url={@docRoot}/java.base/java/lang/doc-files/RestrictedMethods.html

There is no reason to add the path to the properties, as it will not be internationalized. The place to put this would be `jdk.javadoc.internal.doclets.toolkit.util.DocPaths`, but I would only define the file name `RestrictedMethods.html` there as the rest of the path can be resolved as a doc-file relative to the `java.lang` package.

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

Changes requested by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21067#pullrequestreview-2348525063
PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1787990067

From hannesw at openjdk.org  Fri Oct  4 17:14:39 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Oct 2024 17:14:39 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v5]
In-Reply-To: <V1IPsW-mbDIBmFlyAM5Orycdsp9qrGOFcWJRaC_W1JY=.58042904-8e0a-40ab-b344-dfa7b162ca7f@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <4bjJIoZYVmhLTfiPbF10-xL2uQGQDNsWQTVySTrqTFI=.79885190-436d-49b5-83d9-324eca653211@github.com>
 <5sDVx0XJrcqybukBtqIWjVtRowbOK1ssyRttAJ9vxaI=.38a0c9ff-cef2-4442-a1ec-364753271ef4@github.com>
 <V1IPsW-mbDIBmFlyAM5Orycdsp9qrGOFcWJRaC_W1JY=.58042904-8e0a-40ab-b344-dfa7b162ca7f@github.com>
Message-ID: <G0wSjTHduPHiwWjVBbKsHyzi46coyz1h84NL6AIKT-M=.3a62788e-d667-4d7e-8fde-980f6b605893@github.com>

On Fri, 4 Oct 2024 16:32:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testRestricted/TestRestricted.java line 45:
>> 
>>> 43:     public static void main(String... args) throws Exception {
>>> 44:         var tester = new TestRestricted();
>>> 45:         tester.setAutomaticCheckLinks(false);
>> 
>> @hns I had to disable this check because otherwise the test framework will attempt (and fail) to resolve `../java.base/java/lang/doc-files/RestrictedMethods.html`. Is there a better way to do this w/o disabling the link checks?
>
> I'm not Hannes, but to my mind, the fact that you had to disable that check to make the test pass hints that it's a real problem rather than a minor inconvenience.
> 
> Basing this URL off `{@docRoot}` seems an incorrect thing to do:
> 
>     doclet.Restricted.url={@docRoot}/java.base/java/lang/doc-files/RestrictedMethods.html
> 
> It will only be `@docRoot` in the JDK, but not in any other code base, and certainly not in that test.
> 
> I don't know if restricted methods is a JDK-only feature, but for javadoc's sake, we should treat it like it's not. So the link should go to the same place where `{@link Object}` goes.

Sorry for missing the mention. I agree with @pavelrappo that this doesn't look quite right. It's true that it is not usually an issue as the feature will not be used outside of Java SE APIs. But it's conceivable that builds API docs for JDK or Java SE modules without including `java.base`. I think the right solution would be to create the link only if `java.base`/`java.lang` is included in the documentation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1788005180

From rgiulietti at openjdk.org  Fri Oct  4 17:18:39 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 17:18:39 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
Message-ID: <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>

On Fri, 4 Oct 2024 17:11:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> @archiecobbs AFAIK, the documentation of `BigDecimal` does not specify that the class is thread-safe, but I could be wrong...
>
> @fabioromano1, this is a static method manipulating static fields that are shared by all instances; whether individual instances are thread safe is a separate and unrelated issue.

The real problem here is the maximal size this table can reach and the time it takes to be filled in the worst case: around 300 MB and several minutes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788033193

From darcy at openjdk.org  Fri Oct  4 17:24:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 17:24:06 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
Message-ID: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>

Fix broken links.

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

Commit messages:
 - JDK-8341541: Wrong anchor in wrapper classes links

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

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

From duke at openjdk.org  Fri Oct  4 17:25:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 17:25:36 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
Message-ID: <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>

On Fri, 4 Oct 2024 17:15:54 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @fabioromano1, this is a static method manipulating static fields that are shared by all instances; whether individual instances are thread safe is a separate and unrelated issue.
>
> The real problem here is the maximal size this table can reach and the time it takes to be filled in the worst case: around 300 MB and several minutes.

@rgiulietti Which means, however, wanting to work with a precision of billions of decimal digits, and therefore taking on the consequences...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788043406

From jlu at openjdk.org  Fri Oct  4 17:36:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 4 Oct 2024 17:36:41 GMT
Subject: RFR: 8340326: Remove references to Applet in core-libs/security
 tests [v8]
In-Reply-To: <4y81EJSqbylcEsEo-KkBu14tGWB4R0ysQsT9wHmiqjo=.593642c8-1e39-4410-a3cc-2f52b634ae2e@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
 <4y81EJSqbylcEsEo-KkBu14tGWB4R0ysQsT9wHmiqjo=.593642c8-1e39-4410-a3cc-2f52b634ae2e@github.com>
Message-ID: <JlkyPoDVpRDjP51suarXDl03E1psdM6WIYw6V7koYV4=.9bd63577-05c0-4146-9b3f-952b368e825b@github.com>

On Thu, 3 Oct 2024 18:15:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes usages of Applet within the corelibs tests.
>> 
>> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
>> 
>> The following files were removed,
>> 
>> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>>   - Test runner is no longer an Applet, so not needed
>> - test/jdk/java/net/Socket/SocketImplTest.java
>>   - An old Applet test missing Jtreg tags.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect Phil's review: build tag for PassFailJFrame

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/21096#issuecomment-2394212552

From jlu at openjdk.org  Fri Oct  4 17:36:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 4 Oct 2024 17:36:41 GMT
Subject: Integrated: 8340326: Remove references to Applet in core-libs/security
 tests
In-Reply-To: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
References: <614RLDGoUbOmXywu1yiCq8EoJ4LxMNtDZjNySkJusqE=.75dab7f4-0255-432d-840f-49bd2c27d845@github.com>
Message-ID: <H6HDokDXPD7D2Q1HAK56PGeUwwZ9nS7ajDUMi62QhYw=.49f4f2a2-32ca-4d50-835b-10147ac1cf6a@github.com>

On Thu, 19 Sep 2024 22:25:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes usages of Applet within the corelibs tests.
> 
> Most changes are removed comments/updated var names. The JBS issue lists more files than the ones included in this pull request, please see the comment on the JBS issue for the reason why they were not included.
> 
> The following files were removed,
> 
> - test/jdk/java/util/TimeZone/DefaultTimeZoneTest.html
>   - Test runner is no longer an Applet, so not needed
> - test/jdk/java/net/Socket/SocketImplTest.java
>   - An old Applet test missing Jtreg tags.

This pull request has now been integrated.

Changeset: 2e5b420f
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e5b420f81cf714fe66871c4b426a460b4714b28
Stats:     394 lines in 11 files changed: 44 ins; 295 del; 55 mod

8340326: Remove references to Applet in core-libs/security tests

Reviewed-by: prr, naoto, dfuchs

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

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

From duke at openjdk.org  Fri Oct  4 17:44:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 17:44:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v19]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <996sbA2KzyYnzLLPVHxyr3_UPBt_XX3yKrN4hVYFNhc=.a0a19a11-628a-450c-8084-15a6545e803d@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Solving thread-safe issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/305c3f5e..16763772

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=17-18

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

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

From duke at openjdk.org  Fri Oct  4 17:48:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 17:48:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v20]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <rw-4mXgSOReERpu4uX44EPorjTRJoRdcyTfn4w6xRW8=.3da9096e-a684-43ef-b99d-edc485466c40@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Minor formatting change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/16763772..6351d30e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=18-19

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

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

From hannesw at openjdk.org  Fri Oct  4 17:43:48 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Oct 2024 17:43:48 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
Message-ID: <sCxDcii_QwciFhgXgz0vXaiQtBiyl_xN6qzMcmJysuk=.3eb2cf7d-3253-40b8-8001-425cb55ee954@github.com>

Please review a doc change to fix the target anchor for the "wrapper class" links added in #21215. 

In addition to changing the anchor to "wrapperClass" (singular) I also moved the id attribute to the `<p>` tag so that browser view is positioned over the whole paragraph instead of just the term "wrapper classes".

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

Commit messages:
 - JDK-8341541: Wrong anchor in wrapper classes links

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

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

From rgiulietti at openjdk.org  Fri Oct  4 17:50:34 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 17:50:34 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
Message-ID: <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>

On Fri, 4 Oct 2024 17:22:32 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The real problem here is the maximal size this table can reach and the time it takes to be filled in the worst case: around 300 MB and several minutes.
>
> @rgiulietti Which means, however, wanting to work with a precision of billions of decimal digits, and therefore taking on the consequences...

It takes around 100 ms and less than 1 MB to build a table up to 20 rather than 29.
It can be fully constructed in `static { ... }`, avoiding races.

IMO, this would cover the vast majority of the cases encountered in practice.
Other, way less common usages with multi-millions or billions of digits would then impact running time but not _persistent_ memory footprint.

WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788083966

From duke at openjdk.org  Fri Oct  4 17:54:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 17:54:36 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
Message-ID: <EqvYCtAZDHatB7-ujN2NbQy26R2kQyiOobRV2udZenU=.ec020f16-bc69-4bc6-b3c9-6d54fdd1d650@github.com>

On Fri, 4 Oct 2024 17:48:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti Which means, however, wanting to work with a precision of billions of decimal digits, and therefore taking on the consequences...
>
> It takes around 100 ms and less than 1 MB to build a table up to 20 rather than 29.
> It can be fully constructed in `static { ... }`, avoiding races.
> 
> IMO, this would cover the vast majority of the cases encountered in practice.
> Other, way less common usages with multi-millions or billions of digits would then impact running time but not _persistent_ memory footprint.
> 
> WDYT?

@rgiulietti It can be a good compromise between memory and running time...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788087580

From mchung at openjdk.org  Fri Oct  4 17:54:39 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 4 Oct 2024 17:54:39 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v6]
In-Reply-To: <6yC3rrWKvUxQrkbcSKb9F8Oc4sXYMS-TIE3E034CgUY=.c0988c2e-e337-4379-a0cb-74c1f0a80e47@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
 <6yC3rrWKvUxQrkbcSKb9F8Oc4sXYMS-TIE3E034CgUY=.c0988c2e-e337-4379-a0cb-74c1f0a80e47@github.com>
Message-ID: <k0azoZm8wbCDxETda3DCD833ZZUzrlg77Ab0iZUpkNs=.edb156d3-e605-42ce-9337-c117a29e6b69@github.com>

On Wed, 2 Oct 2024 05:15:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> 3. I will just note that the description for this issue  is "Clarify handling of restricted and caller-sensitive methods" but there is nothing in the proposed changes that relate to CS methods, and I think we have agreed that any documentation that may be lacking for pre-existing CS methods should also be handled outside this PR.

https://download.java.net/java/early_access/jdk24/docs/specs/jni/design.html#calling-caller-sensitive-methods is the documentation about the invocation of a caller-sensitive method via JNI when there is no Java caller on the stack.  CS methods do not behave in the same way, for example [some API throws NPE ](https://bugs.openjdk.org/browse/JDK-8281765) or [a default behavior ](https://bugs.openjdk.org/browse/JDK-8221618).

We examined all CS methods and the API specification specifies the behavior (see [JDK-8177155](https://bugs.openjdk.org/browse/JDK-8177155)) when a CS method is invoked via JNI but no Java caller on the stack.   I think the documentation is clear enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2394275395

From henryjen at openjdk.org  Fri Oct  4 17:59:00 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 4 Oct 2024 17:59:00 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v4]
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: <Z1v9FAEBN41Htn50j_yRhcIdNLInESMGfKgYypTrJpU=.9728162e-2bf7-4f80-9e64-d69e8dd6a446@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:

  Fix typo and add comments based on review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21022/files
  - new: https://git.openjdk.org/jdk/pull/21022/files/858703ee..b2794018

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

  Stats: 52 lines in 1 file changed: 15 ins; 22 del; 15 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 duke at openjdk.org  Fri Oct  4 18:04:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 4 Oct 2024 18:04:36 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
Message-ID: <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>

On Fri, 4 Oct 2024 17:48:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti Which means, however, wanting to work with a precision of billions of decimal digits, and therefore taking on the consequences...
>
> It takes around 100 ms and less than 1 MB to build a table up to 20 rather than 29.
> It can be fully constructed in `static { ... }`, avoiding races.
> 
> IMO, this would cover the vast majority of the cases encountered in practice.
> Other, way less common usages with multi-millions or billions of digits would then impact running time but not _persistent_ memory footprint.
> 
> WDYT?

@rgiulietti Though, it's also true that if I want to do astronomical calculations, I probably have a machine that allows me to do so, and so I'd like to be able to make the most of it...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788103481

From henryjen at openjdk.org  Fri Oct  4 18:15:37 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 4 Oct 2024 18:15:37 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v3]
In-Reply-To: <FxFQRTod7Kmx3VZKmz5XX_B_-JXXnxKLKVtChP3PE24=.4e768077-e4e9-497b-8e1e-1eced6a38666@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
 <HvB3n3NzkjFR2uY4TxwxZGwd8ZzsrK2voEI-Q-3QKhM=.307efa67-8944-4e5c-81ab-3ab603b7672c@github.com>
 <FxFQRTod7Kmx3VZKmz5XX_B_-JXXnxKLKVtChP3PE24=.4e768077-e4e9-497b-8e1e-1eced6a38666@github.com>
Message-ID: <euxZpZJzDlJ3QdWqCDzkfGDYuSmQSwOA94xEMXtfPrA=.1147f777-7646-4fd7-9b02-f3545dd1e7e3@github.com>

On Wed, 2 Oct 2024 00:20:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing from last commit
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 1714:
> 
>> 1712:             }
>> 1713: 
>> 1714:             class SetReference<T extends Comparable<T>> implements Comparable<SetReference<T>> {
> 
> The class name `SetReference` is not obvious what it does.   A comment would be helpful.

Added, please let me know any suggestions or questions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21022#discussion_r1788117665

From jvernee at openjdk.org  Fri Oct  4 18:11:40 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 4 Oct 2024 18:11:40 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <N1OgqEd8yYslRfcJah8ARN45mCGOLPFMKsbJ_oF6FV0=.5748000c-f279-418a-96de-a32fc0fc480c@github.com>

On Wed, 21 Aug 2024 20:25:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Nice cleanup! I'm just not really sure about the new subtype relationship (see inline comment)

src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 116:

> 114:         sb.append(componentDesc);
> 115:         return sb.toString();
> 116:     }

Is there really that much benefit in lazily computing the descriptor? `ReferenceClassDescImpl` doesn't do this either... Maybe we can keep things simple and initialize the descriptor in the constructor?

src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 126:

> 124:         Class<?> clazz = element.resolveConstantDesc(lookup);
> 125:         for (int i = 0; i < rank; i++)
> 126:             clazz = clazz.arrayType();

Looking at the implementation of `arrayType`, it reflectively creates an array and then returns its class. Just makes me think we need a better we to look up an array class directly in the JDK :D

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 89:

> 87: 
> 88:     private static ClassDesc validateArgument(ClassDesc arg) {
> 89:         if (requireNonNull(arg) == CD_void)

Is it safe to make this change? Are instances of `PrimitveClassDescImpl` canonicalized now? (not in this patch, but it looks that way in the source code).

src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java line 58:

> 56:         if (descriptor.charAt(0) == '[') {
> 57:             return ArrayClassDescImpl.ofValidatedDescriptor(descriptor);
> 58:         }

I think arrays should be handled separately by the caller, or `ArrayClassDescImpl` should be made a sub-type of  `ReferenceClassDescImpl`. This factory in `ReferenceClassDescImpl` handling a sibling seems a bit confusing.

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

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2348740185
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788073751
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788084532
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788090312
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788110720

From liach at openjdk.org  Fri Oct  4 18:27:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 18:27:37 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <N1OgqEd8yYslRfcJah8ARN45mCGOLPFMKsbJ_oF6FV0=.5748000c-f279-418a-96de-a32fc0fc480c@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <N1OgqEd8yYslRfcJah8ARN45mCGOLPFMKsbJ_oF6FV0=.5748000c-f279-418a-96de-a32fc0fc480c@github.com>
Message-ID: <CIc5WrC-mRhaOkpn7sEACSgMsiMHzYB1T6gc2vGsNyU=.ffd58f05-a8fd-48b9-abe4-5661b9c21d17@github.com>

On Fri, 4 Oct 2024 17:38:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 116:
> 
>> 114:         sb.append(componentDesc);
>> 115:         return sb.toString();
>> 116:     }
> 
> Is there really that much benefit in lazily computing the descriptor? `ReferenceClassDescImpl` doesn't do this either... Maybe we can keep things simple and initialize the descriptor in the constructor?

This laziness is actually the main reason I had this implementation: In stack map generation, we need to compute the array descriptors of many types yet not using them in the end; the string computation involved a lot of allocations, especially with frequent `arrayType()` and `componentType()` calls.

> src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 126:
> 
>> 124:         Class<?> clazz = element.resolveConstantDesc(lookup);
>> 125:         for (int i = 0; i < rank; i++)
>> 126:             clazz = clazz.arrayType();
> 
> Looking at the implementation of `arrayType`, it reflectively creates an array and then returns its class. Just makes me think we need a better we to look up an array class directly in the JDK :D

Indeed; and it's more alarming that `Class.forName("[[[[[Ljava.lang.Object;")` is slower than `Object.class.arrayType().arrayType().arrayType().arrayType().arrayType()`.

> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 89:
> 
>> 87: 
>> 88:     private static ClassDesc validateArgument(ClassDesc arg) {
>> 89:         if (requireNonNull(arg) == CD_void)
> 
> Is it safe to make this change? Are instances of `PrimitveClassDescImpl` canonicalized now? (not in this patch, but it looks that way in the source code).

Yes, they are canonicalized now for performance. `PrimitiveClassDescImpl` extends `DynamicConstantDesc` so creation and comparison of non-unique instances was costly.

> src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java line 58:
> 
>> 56:         if (descriptor.charAt(0) == '[') {
>> 57:             return ArrayClassDescImpl.ofValidatedDescriptor(descriptor);
>> 58:         }
> 
> I think arrays should be handled separately by the caller, or `ArrayClassDescImpl` should be made a sub-type of  `ReferenceClassDescImpl`. This factory in `ReferenceClassDescImpl` handling a sibling type seems a bit confusing.

Indeed, since the factory usages are widespread, I only did a hotfix migration. This class should now be called `ClassOrInterfaceDescImpl` (or "type klass" in hotspot terms or "declared types" in javac terms)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788128649
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788125022
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788126100
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788127459

From liach at openjdk.org  Fri Oct  4 18:49:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 18:49:34 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <sCxDcii_QwciFhgXgz0vXaiQtBiyl_xN6qzMcmJysuk=.3eb2cf7d-3253-40b8-8001-425cb55ee954@github.com>
References: <sCxDcii_QwciFhgXgz0vXaiQtBiyl_xN6qzMcmJysuk=.3eb2cf7d-3253-40b8-8001-425cb55ee954@github.com>
Message-ID: <z6pnu6uUTl4xMM30OmimMk4bYIQceVKg7XEBCnL76mM=.f8d6e1f5-2a6a-4f81-a016-b4a73f46ab80@github.com>

On Fri, 4 Oct 2024 17:37:09 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc change to fix the target anchor for the "wrapper class" links added in #21215. 
> 
> In addition to changing the anchor to "wrapperClass" (singular) I also moved the id attribute to the `<p>` tag so that browser view is positioned over the whole paragraph instead of just the term "wrapper classes".

Please update this site

https://github.com/openjdk/jdk/blob/86e3d52c70a611975da3abdebd2e1f14c7a1d019/src/java.compiler/share/classes/javax/lang/model/util/Types.java#L209

to use `wrapperClass` instead of `wrapperClasses`.

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

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21361#pullrequestreview-2348878760

From smarks at openjdk.org  Fri Oct  4 19:00:44 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 4 Oct 2024 19:00:44 GMT
Subject: RFR: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists [v2]
In-Reply-To: <ePXbun_E1H4dUToSlLN9cyBBcA83a_8IWcQI0cF1VW8=.b8c7da5e-6bf1-4cbb-9771-03de25caffae@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
 <ePXbun_E1H4dUToSlLN9cyBBcA83a_8IWcQI0cF1VW8=.b8c7da5e-6bf1-4cbb-9771-03de25caffae@github.com>
Message-ID: <lDvFxpPb9O-6jbTYI2oq1Km9Djg8K-VNKK205vbTfrk=.70fece1a-34d4-4fff-87c9-b9815f5e7cf7@github.com>

On Thu, 3 Oct 2024 19:31:06 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
>> 
>> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.
>
> Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Rename test to more descriptive
>   - Add a test case for whole list sorting

Thanks for the updates! I've run these changes through our internal testing system and the results look good.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21250#pullrequestreview-2348901655

From darcy at openjdk.org  Fri Oct  4 19:10:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 19:10:36 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <sCxDcii_QwciFhgXgz0vXaiQtBiyl_xN6qzMcmJysuk=.3eb2cf7d-3253-40b8-8001-425cb55ee954@github.com>
References: <sCxDcii_QwciFhgXgz0vXaiQtBiyl_xN6qzMcmJysuk=.3eb2cf7d-3253-40b8-8001-425cb55ee954@github.com>
Message-ID: <DeoCxKblj1IqB5CJy9pP6YLBrwSh3ypJa9qFAYQLk7k=.a0a33cc2-6e9c-4e93-ad5b-873735b8925c@github.com>

On Fri, 4 Oct 2024 17:37:09 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc change to fix the target anchor for the "wrapper class" links added in #21215. 
> 
> In addition to changing the anchor to "wrapperClass" (singular) I also moved the id attribute to the `<p>` tag so that browser view is positioned over the whole paragraph instead of just the term "wrapper classes".

Note only one of this PR and https://git.openjdk.org/jdk/pull/21360 should get pushed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21361#issuecomment-2394396444

From bpb at openjdk.org  Fri Oct  4 19:06:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 4 Oct 2024 19:06:37 GMT
Subject: RFR: 8339699: Optimize DataOutputStream writeUTF [v6]
In-Reply-To: <r9skwi26EuGlQR8LniR4cwBL4DCkcNQHwjZSPiq0EAs=.5d8123bf-9fe0-46da-862d-31343134a661@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
 <r9skwi26EuGlQR8LniR4cwBL4DCkcNQHwjZSPiq0EAs=.5d8123bf-9fe0-46da-862d-31343134a661@github.com>
Message-ID: <2_UyBylMKfxGDPgiiN3N1kFi-t6OHvg5CashgnPBUv0=.bd57b7d5-33f1-4cfd-82dc-29b3472ad8b6@github.com>

On Fri, 20 Sep 2024 05:09:19 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix for write long utf

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20886#pullrequestreview-2348909768

From hannesw at openjdk.org  Fri Oct  4 19:20:35 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Oct 2024 19:20:35 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
References: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
Message-ID: <7kax833PYl8WKYdCMBzMIpjAQb5eKpkrrcP-JM_pv50=.8eeaeda9-d7eb-42ba-9258-bedfebdd9951@github.com>

On Fri, 4 Oct 2024 17:17:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix broken links.

I hadn't caught the use of the plural form anchor in `Types.java`. Looks good.

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21360#pullrequestreview-2348949061

From hannesw at openjdk.org  Fri Oct  4 19:22:38 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Oct 2024 19:22:38 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <DeoCxKblj1IqB5CJy9pP6YLBrwSh3ypJa9qFAYQLk7k=.a0a33cc2-6e9c-4e93-ad5b-873735b8925c@github.com>
References: <sCxDcii_QwciFhgXgz0vXaiQtBiyl_xN6qzMcmJysuk=.3eb2cf7d-3253-40b8-8001-425cb55ee954@github.com>
 <DeoCxKblj1IqB5CJy9pP6YLBrwSh3ypJa9qFAYQLk7k=.a0a33cc2-6e9c-4e93-ad5b-873735b8925c@github.com>
Message-ID: <bysWbyAmZlr_RRNNmDaDRTnFUujK4U6g-WA85XewCVc=.9b94acd5-7c0a-48cf-b90d-700d3a569d2a@github.com>

On Fri, 4 Oct 2024 19:07:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review a doc change to fix the target anchor for the "wrapper class" links added in #21215. 
>> 
>> In addition to changing the anchor to "wrapperClass" (singular) I also moved the id attribute to the `<p>` tag so that browser view is positioned over the whole paragraph instead of just the term "wrapper classes".
>
> Note only one of this PR and https://git.openjdk.org/jdk/pull/21360 should get pushed.

@jddarcy I closed this and approved yours.

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

PR Comment: https://git.openjdk.org/jdk/pull/21361#issuecomment-2394422298

From hannesw at openjdk.org  Fri Oct  4 19:22:39 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 4 Oct 2024 19:22:39 GMT
Subject: Withdrawn: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <sCxDcii_QwciFhgXgz0vXaiQtBiyl_xN6qzMcmJysuk=.3eb2cf7d-3253-40b8-8001-425cb55ee954@github.com>
References: <sCxDcii_QwciFhgXgz0vXaiQtBiyl_xN6qzMcmJysuk=.3eb2cf7d-3253-40b8-8001-425cb55ee954@github.com>
Message-ID: <0y2aa7uVSvMT3_-CGb3ck1ZFEiC-f1C_qxNYm9KMyeg=.047d6605-ddad-473c-8a96-cfaf10588f0c@github.com>

On Fri, 4 Oct 2024 17:37:09 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc change to fix the target anchor for the "wrapper class" links added in #21215. 
> 
> In addition to changing the anchor to "wrapperClass" (singular) I also moved the id attribute to the `<p>` tag so that browser view is positioned over the whole paragraph instead of just the term "wrapper classes".

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Fri Oct  4 19:25:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 19:25:34 GMT
Subject: RFR: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
References: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
Message-ID: <6-vPTk4_HOoFZnZnwMX9ZgSrlWvuPcww-ihZhcctHAM=.32ca16da-52cd-4934-baae-cfca1d089174@github.com>

On Fri, 4 Oct 2024 17:17:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix broken links.

Thanks, hannes' pr popped up first in the PR list so I omitted this one.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21360#pullrequestreview-2348973542

From liach at openjdk.org  Fri Oct  4 19:29:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 19:29:36 GMT
Subject: RFR: 8341512: Optimize
 StackMapGenerator::processInvokeInstructions [v2]
In-Reply-To: <73JIkxy7m8dCQUrJFIqCOmI1R059BlDTntNHkVTJQc8=.7acce97f-805e-4708-a827-ea29455cf6f4@github.com>
References: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
 <73JIkxy7m8dCQUrJFIqCOmI1R059BlDTntNHkVTJQc8=.7acce97f-805e-4708-a827-ea29455cf6f4@github.com>
Message-ID: <GEI6e04Z1jev11suueZbPzTR5QeNUbcYzcAWgGIyS9Q=.3d3ebeef-5e8c-48ff-af3d-b5193e409b4c@github.com>

On Fri, 4 Oct 2024 14:25:09 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization for StackMapGenerator::processInvokeInstructions.
>> 
>> 1. Use local currentFrame to avoid multiple getfields
>> 2. remove Util.methodTypeSymbol(NameAndTypeEntry)
>> 3. Use decStack instead of popStack to reduce array access in popStack
>> 4. codeSize reduced from 277 to 262
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/classfile/attribute/EnclosingMethodAttribute.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21344#pullrequestreview-2348988189

From darcy at openjdk.org  Fri Oct  4 19:28:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 19:28:40 GMT
Subject: Integrated: 8341541: Wrong anchor in wrapper classes links
In-Reply-To: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
References: <u9QxQJd5Hxkto2cZKwcjHbIgwCv_hgVg-Ver4_GDnR4=.aeb4a886-917d-4d40-80c2-f6d74746d4a7@github.com>
Message-ID: <TvBAO9E2bIG2QAM3lVMEkUe7zIOnleOq7nWDqHg4eGE=.b557ac6f-a716-4d3e-bf78-04d2086c8249@github.com>

On Fri, 4 Oct 2024 17:17:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix broken links.

This pull request has now been integrated.

Changeset: e70cbcfd
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e70cbcfd0c07c0334bf3d5fe20da806129d7565e
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8341541: Wrong anchor in wrapper classes links

Reviewed-by: hannesw, liach

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

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

From duke at openjdk.org  Fri Oct  4 19:47:38 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 4 Oct 2024 19:47:38 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
Message-ID: <dq5DbMcq3fGQ-fQ0_VMPnKYu5FxclxDOYe82S0GxB4o=.a07a1952-e1c4-42c0-91c7-5f6da49dd8e9@github.com>

On Fri, 27 Sep 2024 14:21:57 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 incrementally with three additional commits since the last revision:
> 
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - Revert "Switch movl to movq"
>    
>    This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
>  - Revert "Fix format of assembly for the movl to movq switch"
>    
>    This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

test/micro/org/openjdk/bench/java/lang/MinMaxLoopBench.java line 107:

> 105:     @Benchmark
> 106:     public int[] intLoopMin() {
> 107:         final int[] result = new int[size];

it would be better to not have this allocation here unless is what you want to measure 
i.e. allocation and assignment in a fresh new array which would escape.
The optimization still kicks-in if you reuse the same `result` saved as an instance field?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1788235692

From jvernee at openjdk.org  Fri Oct  4 19:50:37 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 4 Oct 2024 19:50:37 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <CIc5WrC-mRhaOkpn7sEACSgMsiMHzYB1T6gc2vGsNyU=.ffd58f05-a8fd-48b9-abe4-5661b9c21d17@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <N1OgqEd8yYslRfcJah8ARN45mCGOLPFMKsbJ_oF6FV0=.5748000c-f279-418a-96de-a32fc0fc480c@github.com>
 <CIc5WrC-mRhaOkpn7sEACSgMsiMHzYB1T6gc2vGsNyU=.ffd58f05-a8fd-48b9-abe4-5661b9c21d17@github.com>
Message-ID: <xhMjoC2nB4UOnqrLTPxXuyl6YuDhpIcdQNYB5FPJGVE=.34ebd1c4-7ef1-4ee8-b097-043b7e240601@github.com>

On Fri, 4 Oct 2024 18:24:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 116:
>> 
>>> 114:         sb.append(componentDesc);
>>> 115:         return sb.toString();
>>> 116:     }
>> 
>> Is there really that much benefit in lazily computing the descriptor? `ReferenceClassDescImpl` doesn't do this either... Maybe we can keep things simple and initialize the descriptor in the constructor?
>
> This laziness is actually the main reason I had this implementation: In stack map generation, we need to compute the array descriptors of many types yet not using them in the end; the string computation involved a lot of allocations, especially with frequent `arrayType()` and `componentType()` calls.

Ok, thanks. That's useful information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1788238762

From duke at openjdk.org  Fri Oct  4 19:54:36 2024
From: duke at openjdk.org (duke)
Date: Fri, 4 Oct 2024 19:54:36 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications [v3]
In-Reply-To: <6PltJ5oj9C3FSBM4-pdQJJgrk11xiJS_SI8aQvn-1Do=.bd5af85b-7015-4b09-8c52-6d492bc19a4b@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
 <6PltJ5oj9C3FSBM4-pdQJJgrk11xiJS_SI8aQvn-1Do=.bd5af85b-7015-4b09-8c52-6d492bc19a4b@github.com>
Message-ID: <pOkqKZu2T7VpHOPDUV_Flh8f3fH8pVc08cdOwnNHsBA=.320e618e-94e8-4092-b840-4428c2795363@github.com>

On Mon, 30 Sep 2024 14:59:12 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

@dmlloyd 
Your change (at version c95a0e2c1b94cf87807305e50bf8c32eb11a48c1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20796#issuecomment-2394473226

From mcimadamore at openjdk.org  Fri Oct  4 21:21:41 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 4 Oct 2024 21:21:41 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
Message-ID: <b2WyTwOZlFjE40IU4oC1Lf56HICOO4Pue1IwYXd-BtQ=.31135381-9033-48f0-92d5-43629ed41e88@github.com>

On Mon, 23 Sep 2024 16:35:18 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:
> 
>   Reword doce

Following a discussion offline, we reached consensus around the following javadoc text:


* <li>{@code L} is a group layout {@code G} and all the following conditions hold:
 * <ol>
 * <li>the alignment constraint of {@code G} is set to its
 *     <a href="MemoryLayout.html#layout-align">natural alignment</a>;</li>
 * <li>the size of {@code G} is a multiple of its alignment constraint;</li>
 * <li>each member layout in {@code G.memberLayouts()} is either a padding layout or
 *     a layout supported by {@code NL}</li>
 * <li>each padding member layout in {@code G} is naturaly aligned</li>
 * <li>{@code G} contains at least a non-padding member layout, and</li>
 * <li>{@code G} contains the least amount of padding members required to align
 *      its non-padding layout elements, or to satisfy (2).</li>
 ```
 
This should clarify that padding inside structs should be "normalized". Meaning no consecutive padding layouts, and no padding nested in sequence layouts, or only-padding structs/unions. The implementation should also be tweaked accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2394685349

From almatvee at openjdk.org  Fri Oct  4 21:24:43 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 4 Oct 2024 21:24:43 GMT
Subject: Integrated: 8341443: [macos] AppContentTest and SigningOptionsTest
 failed due to "codesign" does not fails with "--app-content" on macOS 15
In-Reply-To: <hju35Q4minf8idhGVHExjUethcw84gj0taEC4rBgKp0=.89a83513-53f6-411e-9579-1747b75e042c@github.com>
References: <hju35Q4minf8idhGVHExjUethcw84gj0taEC4rBgKp0=.89a83513-53f6-411e-9579-1747b75e042c@github.com>
Message-ID: <_PXsCpuT2T8IzH8_Mu4NaC15iaqbt2IjAGOkVAnabHU=.a14a98b8-8642-4756-8054-6de7505b4979@github.com>

On Wed, 2 Oct 2024 20:32:57 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - `AppContentTest` and `SigningOptionsTest` failed on macOS 15 due to `codesign` no longer fails if additional content is added to app image.
> - `SigningOptionsTest` fixed by failing `codesign` due to missing identity, since we only need to check that warning message is displayed when codesign fails and `--app-content` is specified.
> - `AppContentTest` is fixed by setting expected exit code based on macOS version.

This pull request has now been integrated.

Changeset: 85e0e645
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85e0e6452d167db2fadd60543f875a6375339604
Stats:     27 lines in 2 files changed: 22 ins; 2 del; 3 mod

8341443: [macos] AppContentTest and SigningOptionsTest failed due to "codesign" does not fails with "--app-content" on macOS 15

Reviewed-by: asemenyuk

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

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

From liach at openjdk.org  Fri Oct  4 21:32:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 4 Oct 2024 21:32:44 GMT
Subject: RFR: 8341510: Optimize StackMapGenerator::processFieldInstructions
In-Reply-To: <zRQGSq0guyPStgS-gGxFQVnXPeR3_3UrKYa9cy5S1Nw=.5c0aaf70-1f35-4173-a03d-a98dff8caf98@github.com>
References: <zRQGSq0guyPStgS-gGxFQVnXPeR3_3UrKYa9cy5S1Nw=.5c0aaf70-1f35-4173-a03d-a98dff8caf98@github.com>
Message-ID: <x_Xmbj2-6KMVUaK9_izqM39S2cw4qUliHXTANHiNUYU=.7de4dc46-ed19-4fc4-9878-14d17b60380d@github.com>

On Fri, 4 Oct 2024 02:47:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce CodeSize, codeSize reduced from 164 to 140.
> 
> 1. Use local currentFrame to avoid multiple getfields
> 2. Use decStack instead of popStack to reduce array access in popStack
> 3. Call Util.fieldTypeSymbol to pass in type instead of nameAndType

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21345#pullrequestreview-2349290148

From kcr at openjdk.org  Fri Oct  4 21:45:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 4 Oct 2024 21:45:53 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal [v2]
In-Reply-To: <Sgi1WKvchV1LRS-hPO7eUZIaCWXjfCDLCLidsn1kYts=.944d041e-24f0-4938-877c-7cd95641506e@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
 <Sgi1WKvchV1LRS-hPO7eUZIaCWXjfCDLCLidsn1kYts=.944d041e-24f0-4938-877c-7cd95641506e@github.com>
Message-ID: <B3AcJ2WEFe4FEZkZdE6ussuNMCx9lgipVXJ2FP6vpIM=.917e08fb-15d7-4084-ad41-66b2112d232c@github.com>

On Mon, 23 Sep 2024 16:32:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
>> 
>> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
>> 
>> This PR does two things:
>> 
>> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
>> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.
>
> Kevin Rushforth 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 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Update javadoc
>  - Update copyright years
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test
>  - 8311530: Deprecate jdk.jsobject module for removal

I've created the CSRs for both the this PR and openjdk/jfx#1529.

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

PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2394709080

From swen at openjdk.org  Fri Oct  4 22:37:41 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 22:37:41 GMT
Subject: Integrated: 8339699: Optimize DataOutputStream writeUTF
In-Reply-To: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
References: <bagfWhS4ao8jlNkW1O5-iq5347P86qRF43YfLrUsBtk=.6c955a40-d233-418f-ae8e-837a245758a4@github.com>
Message-ID: <IwQYAfpPiZDfnvSIb_kA60In6-uV30fxrDE4sxCFNvo=.f9ced3fa-06ed-49d8-b7f9-b6829119c3b8@github.com>

On Fri, 6 Sep 2024 09:58:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> PR #20772 introduced an optimization for writeUTF, which can also be used in DataOutputStream::writeUTF.

This pull request has now been integrated.

Changeset: b42fbf43
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b42fbf43dfd62ae64973ff0e406b6609cd8e1aa6
Stats:     409 lines in 5 files changed: 227 ins; 157 del; 25 mod

8339699: Optimize DataOutputStream writeUTF

Reviewed-by: liach, bpb

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

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

From swen at openjdk.org  Fri Oct  4 22:39:09 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 4 Oct 2024 22:39:09 GMT
Subject: RFR: 8341548: More concise use of classfile API [v2]
In-Reply-To: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
References: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
Message-ID: <5DZ0kHxTPgznPwGE7pKWkOmatnMgn4QN4sZXHhR22nk=.9fa79a64-2b82-4643-8ecc-234e56a9c912@github.com>

> java.base should provide best practices for Class File API
> 
> 1. Use fluent coding style
> 2. Use aconst_null instead of oadConstant(null)
> 3. use astore intead of 'storeLocal(REFERENCE'
> 4. use aload instead of 'loadLocal(REFERENCE'
> 5. 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(LONG)'

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  more fluent coding style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21355/files
  - new: https://git.openjdk.org/jdk/pull/21355/files/8b2fa4d0..4d895f45

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

  Stats: 21 lines in 2 files changed: 5 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21355/head:pull/21355

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

From rgiulietti at openjdk.org  Fri Oct  4 22:44:35 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 22:44:35 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
Message-ID: <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>

On Fri, 4 Oct 2024 18:02:21 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> It takes around 100 ms and less than 1 MB to build a table up to 20 rather than 29.
>> It can be fully constructed in `static { ... }`, avoiding races.
>> 
>> IMO, this would cover the vast majority of the cases encountered in practice.
>> Other, way less common usages with multi-millions or billions of digits would then impact running time but not _persistent_ memory footprint.
>> 
>> WDYT?
>
> @rgiulietti Though, it's also true that if I want to do astronomical calculations, I probably have a machine that allows me to do so, and so I'd like to be able to make the most of it...

`BigDecimal` was not designed to do astronomical computations. One would probably use other libraries for that, e.g., [GMP](https://gmplib.org/) and would not be interested too much in "stripping trailing zeros".
The focus of this class is mainly commercial applications, where decimal arithmetic is sometimes mandated by regulators.

So I'd expect that most usages, for example SQL or commercial application workloads, will process numbers with a few dozens of digits, maybe sometimes some hundreds digits for intermediate results. So I think that accelerating for these sizes makes the most practical sense.

With modest memory and CPU costs, I think even one million digits or so might be processed reasonably fast.
My point is that there's room for improvement in these range of sizes, but perhaps not for larger ones.

More importantly, though, I'd like to avoid one single computation to affect the resident memory footprint of a JVM instance for its entire lifetime.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1788393701

From swen at openjdk.org  Sat Oct  5 01:27:18 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 01:27:18 GMT
Subject: RFR: 8341512: Optimize
 StackMapGenerator::processInvokeInstructions [v3]
In-Reply-To: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
References: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
Message-ID: <kmRgC8HIxyuB4bRFa68q0QPBPyYdvFqjJjLe3JU8d2Y=.0744fd46-7f97-4e9b-8df3-a4e55b5a3c41@github.com>

> A small optimization for StackMapGenerator::processInvokeInstructions.
> 
> 1. Use local currentFrame to avoid multiple getfields
> 2. remove Util.methodTypeSymbol(NameAndTypeEntry)
> 3. Use decStack instead of popStack to reduce array access in popStack
> 4. codeSize reduced from 277 to 262

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into optim_classfile_stack_map_process_invoke_202410
 - Update src/java.base/share/classes/java/lang/classfile/attribute/EnclosingMethodAttribute.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - use decStack instead of popStack
 - remove Util.methodTypeSymbol(NameAndTypeEntry)
 - optimize processInvokeInstructions

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

Changes: https://git.openjdk.org/jdk/pull/21344/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21344&range=02
  Stats: 20 lines in 10 files changed: 1 ins; 7 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21344.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21344/head:pull/21344

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

From swen at openjdk.org  Sat Oct  5 01:24:46 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 01:24:46 GMT
Subject: Integrated: 8341510: Optimize
 StackMapGenerator::processFieldInstructions
In-Reply-To: <zRQGSq0guyPStgS-gGxFQVnXPeR3_3UrKYa9cy5S1Nw=.5c0aaf70-1f35-4173-a03d-a98dff8caf98@github.com>
References: <zRQGSq0guyPStgS-gGxFQVnXPeR3_3UrKYa9cy5S1Nw=.5c0aaf70-1f35-4173-a03d-a98dff8caf98@github.com>
Message-ID: <JT_MO7iExYZJkqSqxHLK8kwWN__cbh39DN_9OH74lfY=.d7bcdae2-ca2f-41a6-9e88-d9c19948dc62@github.com>

On Fri, 4 Oct 2024 02:47:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce CodeSize, codeSize reduced from 164 to 140.
> 
> 1. Use local currentFrame to avoid multiple getfields
> 2. Use decStack instead of popStack to reduce array access in popStack
> 3. Call Util.fieldTypeSymbol to pass in type instead of nameAndType

This pull request has now been integrated.

Changeset: f8db3a83
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8db3a831b61bb585c5494a7a8657e37000892b4
Stats:     14 lines in 4 files changed: 1 ins; 7 del; 6 mod

8341510: Optimize StackMapGenerator::processFieldInstructions

Reviewed-by: liach

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

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

From swen at openjdk.org  Sat Oct  5 01:32:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 01:32:17 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v3]
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <kdZXL26HlIX6LpBVi7haKSys3roVzmFhTrvasu2lrzI=.45fe54ac-909a-4f56-8948-001d2bedec51@github.com>

> Reduce code size by combining calls and defining local variables

Shaojin Wen 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 optim_stack_map_gen_202408
 - reduce codeSize
 - reduce codeSize
 - decStack & stackUnderflow
 - fix merge error
 - Merge branch 'master' into optim_stack_map_gen_202408
 - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - fix merge error
 - Merge remote-tracking branch 'origin/optim_stack_map_gen_202408' into optim_stack_map_gen_202408
 - ... and 4 more: https://git.openjdk.org/jdk/compare/f8db3a83...a321f9a3

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

Changes: https://git.openjdk.org/jdk/pull/20756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=02
  Stats: 358 lines in 2 files changed: 225 ins; 36 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/20756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20756/head:pull/20756

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

From swen at openjdk.org  Sat Oct  5 07:50:18 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 07:50:18 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v21]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <XowRVtYKoowtRWwP-Zqw4fzg37POQoqWT27YMs_9BJY=.8dac2334-9d7e-4984-8846-814f888971c0@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits:

 - Merge remote-tracking branch 'upstream/master' into optim_direct_code_builder_202409
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - fix merge error
 - Merge branch 'master' into optim_direct_code_builder_202409
 - optimize DirectClassBuilder::build
 - writeU2U2U2
 - optimization for powerOctal
 - label write clean
 - optimizer for codeSize
 - optimize MethodTypeDescImpl::descriptorString
 - ... and 70 more: https://git.openjdk.org/jdk/compare/f8db3a83...d75b7c23

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

Changes: https://git.openjdk.org/jdk/pull/21243/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=20
  Stats: 967 lines in 16 files changed: 585 ins; 119 del; 263 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

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

From duke at openjdk.org  Sat Oct  5 08:44:19 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 5 Oct 2024 08:44:19 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v21]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <A1dWduoWZ8mbdPXYY9IiwfamAQdG2nJhn2oVlVxLNWQ=.3c2427c4-19f2-4ddf-824b-e927cc25fa9d@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Changed caching of powers and removed superfluous condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/6351d30e..6e30724d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=19-20

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

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

From duke at openjdk.org  Sat Oct  5 09:06:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 5 Oct 2024 09:06:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v22]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <6eUedh5W7WnnUlcdYy1gta0k7hsEN_PScjZcYHCdgxs=.5a97106f-0c02-4102-8f1f-05521ae29da1@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

 - Correct documentation
 - Correct documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/6e30724d..13c934d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=20-21

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

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

From duke at openjdk.org  Sat Oct  5 09:23:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 5 Oct 2024 09:23:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v23]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <bVyyGvp6yi2zKKCYr7mEfbKyfZ-dt3G1MMCwJwmGxuw=.d1c71c92-a341-4fea-9de5-163040286b7f@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  An optimization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/13c934d1..42c45f34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=21-22

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

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

From duke at openjdk.org  Sat Oct  5 09:37:51 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 5 Oct 2024 09:37:51 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v24]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <-KgdcvF3xWcawgIqyYga5LhpirovlJvojRHkFLU1-gk=.4ad0e040-b48e-4cd5-be70-15fd1afca92d@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Optimization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/42c45f34..6c22c6ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=22-23

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

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

From duke at openjdk.org  Sat Oct  5 13:23:12 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 5 Oct 2024 13:23:12 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v25]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <-UU-ULA7c9ogWUVfLK-tVdzQxO5kH6cGK82spg_QDAo=.0df80e9f-252d-469d-92bf-e9a40b892d31@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Minor change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/6c22c6ae..0fd671fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=23-24

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

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

From core-libs-dev at io7m.com  Sat Oct  5 14:15:58 2024
From: core-libs-dev at io7m.com (Mark Raynsford)
Date: Sat, 5 Oct 2024 14:15:58 +0000
Subject: Running a jpackage app-image inside Flatpak
Message-ID: <06d87ce2-30be-4bd7-a1c9-4fc276ad7acf@io7m.com>

Hello!

I've been working on some tools to produce Flatpaks[1].

My thinking was that I could use jpackage to produce an app-image and
then simply copy that app-image into a Flatpak and run it that way.

This almost works, except that it seems that the actual executable
produced by jpackage doesn't work, although running (ostensibly) the
same thing the executable _would_ run via the "java" executable does
work. So for example, inside the Flatpak:

$ /app/bin/example

... Fails silently, returning a 1 exit code. But:

$ /app/lib/runtime/bin/java -p /app/lib/app/mods -m
com.io7m.example/com.io7m.example.Main

... Runs the application without issue.

Running the application with strace doesn't show anything that looks
obviously wrong to me.

I feel like the only difference between those two invocations is that
the executable goes through libapplauncher.so to load the application
.cfg file produced by jpackage.

I did notice something slightly suspicious on the libapplauncher.so
binary itself:

$ ldd /app/lib/libapplauncher.so
/app/lib/libapplauncher.so: /usr/lib/x86_64-linux-gnu/libstdc++.so.6:
version `CXXABI_1.3.15' not found (required by /app/lib/libapplauncher.so)
...

Would this be enough to cause an otherwise silent failure?

[1] https://www.flatpak.org/

-- 
Mark Raynsford | https://www.io7m.com


From liach at openjdk.org  Sat Oct  5 15:32:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 5 Oct 2024 15:32:40 GMT
Subject: RFR: 8341512: Optimize
 StackMapGenerator::processInvokeInstructions [v3]
In-Reply-To: <kmRgC8HIxyuB4bRFa68q0QPBPyYdvFqjJjLe3JU8d2Y=.0744fd46-7f97-4e9b-8df3-a4e55b5a3c41@github.com>
References: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
 <kmRgC8HIxyuB4bRFa68q0QPBPyYdvFqjJjLe3JU8d2Y=.0744fd46-7f97-4e9b-8df3-a4e55b5a3c41@github.com>
Message-ID: <1W07ifryFgSzx_X0mZ9QH0B-SEkbPCWpaCwTzvDgEMM=.c925be0d-fde1-4208-aa40-44df2e3217bf@github.com>

On Sat, 5 Oct 2024 01:27:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A small optimization for StackMapGenerator::processInvokeInstructions.
>> 
>> 1. Use local currentFrame to avoid multiple getfields
>> 2. remove Util.methodTypeSymbol(NameAndTypeEntry)
>> 3. Use decStack instead of popStack to reduce array access in popStack
>> 4. codeSize reduced from 277 to 262
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into optim_classfile_stack_map_process_invoke_202410
>  - Update src/java.base/share/classes/java/lang/classfile/attribute/EnclosingMethodAttribute.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - use decStack instead of popStack
>  - remove Util.methodTypeSymbol(NameAndTypeEntry)
>  - optimize processInvokeInstructions

Util method removal fix conflict looks good

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21344#pullrequestreview-2349649471

From swen at openjdk.org  Sat Oct  5 15:40:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 15:40:38 GMT
Subject: Integrated: 8341512: Optimize
 StackMapGenerator::processInvokeInstructions
In-Reply-To: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
References: <mqI9sIME84HsP4zI24hGE1OTyvqwjBpoRjCqcuh2Rls=.e288433d-0d16-40a6-8d19-0eacd290371c@github.com>
Message-ID: <Zz1cobsUPNgYtiwhlnRbBgLKW-OAtTzqPE4eAhwiGa8=.b028d3e9-99c1-47ad-a4fc-bea5be518dbc@github.com>

On Fri, 4 Oct 2024 02:15:51 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization for StackMapGenerator::processInvokeInstructions.
> 
> 1. Use local currentFrame to avoid multiple getfields
> 2. remove Util.methodTypeSymbol(NameAndTypeEntry)
> 3. Use decStack instead of popStack to reduce array access in popStack
> 4. codeSize reduced from 277 to 262

This pull request has now been integrated.

Changeset: 1c3e56c3
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c3e56c3e45be3626afec0461d4ae8059b0b577f
Stats:     20 lines in 10 files changed: 1 ins; 7 del; 12 mod

8341512: Optimize StackMapGenerator::processInvokeInstructions

Reviewed-by: liach

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

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

From swen at openjdk.org  Sat Oct  5 15:42:08 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 15:42:08 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v4]
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <p7zNX3w-EmhHoA_-y0tkaPUWif1iMB_-bJy_u_g6zbo=.1ccfa774-261b-4bc8-8fe5-19919366015f@github.com>

> Reduce code size by combining calls and defining local variables

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' into optim_stack_map_gen_202408
 - Merge branch 'master' into optim_stack_map_gen_202408
 - reduce codeSize
 - reduce codeSize
 - decStack & stackUnderflow
 - fix merge error
 - Merge branch 'master' into optim_stack_map_gen_202408
 - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - fix merge error
 - ... and 5 more: https://git.openjdk.org/jdk/compare/1c3e56c3...59102d50

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

Changes: https://git.openjdk.org/jdk/pull/20756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=03
  Stats: 353 lines in 2 files changed: 225 ins; 33 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/20756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20756/head:pull/20756

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

From swen at openjdk.org  Sat Oct  5 15:44:06 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 15:44:06 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v22]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <YVjs-8yv18wO7EwL40GYExtfNHf_EQ9600x2195L1As=.a3eec83d-5ee3-4acd-aa4d-d91aae282ab4@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 81 commits:

 - Merge branch 'master' into optim_direct_code_builder_202409
 - Merge remote-tracking branch 'upstream/master' into optim_direct_code_builder_202409
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AttributeHolder.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - fix merge error
 - Merge branch 'master' into optim_direct_code_builder_202409
 - optimize DirectClassBuilder::build
 - writeU2U2U2
 - optimization for powerOctal
 - label write clean
 - optimizer for codeSize
 - ... and 71 more: https://git.openjdk.org/jdk/compare/1c3e56c3...d4752d5f

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

Changes: https://git.openjdk.org/jdk/pull/21243/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=21
  Stats: 966 lines in 16 files changed: 585 ins; 119 del; 262 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

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

From swen at openjdk.org  Sat Oct  5 16:33:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 16:33:50 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v23]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <Zb4OZ-X15Gd4lNwrhxlxHabBzzMHdTIE8wjY97NpvaA=.fad1e101-b042-4190-9d71-2c66cf206557@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix merge error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/d4752d5f..0bcedf85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=21-22

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

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

From duke at openjdk.org  Sat Oct  5 16:37:50 2024
From: duke at openjdk.org (Markus KARG)
Date: Sat, 5 Oct 2024 16:37:50 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence Reader
Message-ID: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>

This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.

In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
* ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
* ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.

Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

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

Commit messages:
 - StringReader delegates to Reader.of(String)
 - Reader.of(String)

Changes: https://git.openjdk.org/jdk/pull/21371/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341566
  Stats: 458 lines in 3 files changed: 411 ins; 36 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

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

From duke at openjdk.org  Sat Oct  5 16:51:34 2024
From: duke at openjdk.org (Markus KARG)
Date: Sat, 5 Oct 2024 16:51:34 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>

On Sat, 5 Oct 2024 16:32:39 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

src/java.base/share/classes/java/io/Reader.java line 341:

> 339:             public void close() {
> 340:                 cs = null;
> 341:             }

@AlanBateman I need to confess that I did not understand what you had in mind when you wrote this on the mailing list:
> That doesn't excuse you completely from thinking about concurrent use as Readers have a close method so you'll need to think about how close is specified for when it is called while another thread is reading chars from a custom CS.

As this new implementation explicitly is for single-threaded use only, there is no such other thread that could call `close` concurrently.

Maybe I am missing something here, so I would kindly ask for an outline of a scenario where -despite the explicit single-thread note- a second thread *does* exist?

src/java.base/share/classes/java/io/StringReader.java line 183:

> 181:                 r.close();
> 182:             } catch (IOException e) {
> 183:                 throw new UncheckedIOException(e);

In fact, the implementation of `close` in the original class will never throw `IOException`, but unfortunately `Reader.close()` declares `throws IOException`.

test/jdk/java/io/Reader/Of.java line 51:

> 49:     public static Reader[] readers() {
> 50:         return new Reader[] {
> 51:             new StringReader(CONTENT),

Explicitly including that original class here (even if it has nothing to do with the `of` method) to be sure that we did not modify it in an incompatible way. Unfortunately there is no full test coverage for `StringReader`, and it does not make much sense to duplicate the tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1788644851
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1788644490
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1788644282

From eirbjo at openjdk.org  Sat Oct  5 17:15:59 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 5 Oct 2024 17:15:59 GMT
Subject: RFR: 8340887: Add micro benchmark comparing input stream
 performance of ZipFile vs ZipInputStream [v2]
In-Reply-To: <yrTkspfd60XRlM8J2fdlf55HuooLh9vfqw_p9AMRFIY=.75bf052d-3086-4f79-8441-c84b514e7260@github.com>
References: <yrTkspfd60XRlM8J2fdlf55HuooLh9vfqw_p9AMRFIY=.75bf052d-3086-4f79-8441-c84b514e7260@github.com>
Message-ID: <Pbe3JmKJ60sXiuToLvlHytYJMmsdvR-thJmtRmDKoYU=.75b66e09-e1c7-4225-b3ca-6d8bec0d437e@github.com>

> 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

Eirik Bj?rsn?s 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:

 - Reduce benchmark allocation during reads by not using InputStream::transferTo. Usee data with a more representative compression rate.
 - Merge branch 'master' into zipstream-read-benchmark
 - Add micro benchmark comparing input stream performance of ZipFile vs ZipInputStream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21178/files
  - new: https://git.openjdk.org/jdk/pull/21178/files/fc0f8c7b..0f1e873b

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

  Stats: 173659 lines in 1069 files changed: 163363 ins; 5158 del; 5138 mod
  Patch: https://git.openjdk.org/jdk/pull/21178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21178/head:pull/21178

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

From swen at openjdk.org  Sat Oct  5 17:36:02 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 5 Oct 2024 17:36:02 GMT
Subject: RFR: 8341581: Optimize BytecodeHelpers validate slot
Message-ID: <N4SW9Z6F7Ea0KnaCQcx_heBeEdbwBu8P0MWY6uBkEu8=.8f26f859-71c6-4f91-84a2-be63ea6f238a@github.com>

Use `slot & ~0xFF == 0` instead of `(slot & 0xFF) == slot` to reduce codeSize.

The following is a comparison of the bytecode before and after the modification. It can be seen that using `slot & ~0xFF == 0` will reduce one iload operation.


// (slot & 0xFF) == slot
56: iload_0
57: sipush        255
60: iand
61: iload_0
62: if_icmpne     71

// slot & ~0xFF == 0
56: iload_0
57: sipush        -256
60: iand
61: ifne          70

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

Commit messages:
 - optimize validate slot
 - optimize validate slot

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

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

From redestad at openjdk.org  Sat Oct  5 21:12:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 5 Oct 2024 21:12:40 GMT
Subject: Withdrawn: 8340571: Outline code from the loop in
 ZipFile.Source.initCen
In-Reply-To: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>
References: <nIcT8SY4ZirNuSyQG6M8_kLIfugMsJ3vddYnEVZCmUI=.851ab139-1a42-4c32-bd53-a00dc4917819@github.com>
Message-ID: <ZAoEO8E_lTpom8ydERo96Ny9iERBh17zn25z1ekbNHQ=.5ab392f1-7720-40e3-8cab-99c9a49d1754@github.com>

On Mon, 23 Sep 2024 09:44:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR suggests refactoring `ZipFile.Source.initCEN` to move as much logic as possible into the per-entry method processor. This inner method will be called often and JIT optimized earlier in the bootstrap sequence.
> 
> Startup tests using the OpenJDK benchmarks.jar show a ~1ms improvement on both my M1 macbook and my x64 wokstation, while we also improve on relevant throughput microbenchmarks:
> 
> 
> Name               (size) Cnt       Base      Error        Test      Error  Unit  Change
> openCloseZipFile      512  15  61372.449 ? 1197.432   58081.423 ? 1751.988 ns/op   1.06x (p = 0.000*)
> openCloseZipFile     1024  15 117953.727 ? 3202.274  112548.875 ? 5126.665 ns/op   1.05x (p = 0.001*)
> openCloseZipFilex2    512  15  62141.795 ?  674.121   60520.017 ? 2438.346 ns/op   1.03x (p = 0.017 )
> openCloseZipFilex2   1024  15 117959.071 ? 1528.426  111773.937 ? 1604.412 ns/op   1.06x (p = 0.000*)
>   * = significant

This pull request has been closed without being integrated.

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

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

From attila at openjdk.org  Sat Oct  5 21:17:46 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Sat, 5 Oct 2024 21:17:46 GMT
Subject: Integrated: 8340572: ConcurrentModificationException when sorting
 ArrayList sublists
In-Reply-To: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
References: <J7WClMzIfdKewDpU30iPZAq_tZf4afdJj_ZP8NDiMvE=.3b6ee1de-701a-4102-a139-3381be03af3e@github.com>
Message-ID: <CfJDTl622UsfQjAL-enEllDGh-Wymhcq8T3uFBFeNvg=.fe091eb6-9c08-465c-ac0e-899ccd0506fe@github.com>

On Sun, 29 Sep 2024 17:44:30 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> Fixes a regression with #17818 where `ArrayList.subList(?).sort()` started incrementing `ArrayList.modCount` resulting in some cases throwing a `ConcurrentModificationException` where none was thrown before.
> 
> This change keeps the optimization from #17818 but restores the behavior where only sorting the `ArrayList` changes the mod count, but sorting its sublists does not.

This pull request has now been integrated.

Changeset: 260d4658
Author:    Attila Szegedi <attila at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/260d4658aefe370d8994574c20057de07fd6f197
Stats:     61 lines in 2 files changed: 60 ins; 1 del; 0 mod

8340572: ConcurrentModificationException when sorting ArrayList sublists

Reviewed-by: smarks

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

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

From syan at openjdk.org  Sun Oct  6 02:41:38 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 6 Oct 2024 02:41:38 GMT
Subject: RFR: 8341585: Test java/foreign/TestUpcallStress.java should mark as
 /native
Message-ID: <1wdAhGmXZSblEkHkYVZYImVRhvaMUklYV0Tba2-RxFs=.42420c1b-6975-488a-af3a-602f4354c851@github.com>

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.

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

Commit messages:
 - 8341585: Test java/foreign/TestUpcallStress.java should mark as /native

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

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

From qamai at openjdk.org  Sun Oct  6 08:32:20 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 6 Oct 2024 08:32:20 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

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

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

Changes: https://git.openjdk.org/jdk/pull/21042/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=01
  Stats: 5013 lines in 64 files changed: 2737 ins; 1068 del; 1208 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

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

From syan at openjdk.org  Sun Oct  6 09:27:10 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 6 Oct 2024 09:27:10 GMT
Subject: RFR: 8341593: Problemlist java/foreign/TestUpcallStress.java in Xcomp
 mode
Message-ID: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>

A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp mode.

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

Commit messages:
 - 8341593: Problemlist java/foreign/TestUpcallStress.java in Xcomp mode

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

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

From qamai at openjdk.org  Sun Oct  6 10:27:35 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sun, 6 Oct 2024 10:27:35 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
Message-ID: <tRYnC7MXtHxubnaDjsOXXR0kG_FHp-c_IcQeXRvhtuQ=.6372a187-4698-4505-88c4-0392b28ce3fa@github.com>

On Sun, 6 Oct 2024 08:32:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> 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.

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

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2395383093

From alanb at openjdk.org  Sun Oct  6 13:17:34 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 6 Oct 2024 13:17:34 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>

On Sat, 5 Oct 2024 16:32:39 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Reader.of(CharSequence) looks much better than introducing CharSequenceReader. It won't have an equivalent on Writer but I think that is okay. Also it means that the user will need to deal with close throwing IOException but anything using Reader has to do this already.

I think it would be better to drop "API compatible with StringReader" from the method description. An apiNote in StringReader can direct readers to the static factory method.

Also I think drop the  "lock" field as it's a protected field and only interesting to subclasses.  The Reader class does not specify if Reader is thread-safe so the method description doesn't need to say too much. For clarify then it could just say something like "the resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization".

The parameter name is currently "c", maybe you mean "cs"? The method will need to specify NPE for the of(null) case.

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

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2395436600

From redestad at openjdk.org  Sun Oct  6 14:23:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 14:23:12 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in java.util.zip.ZipUtils
Message-ID: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>

#14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 

In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):


make test TEST=micro:java.util.zip.ZipFile

Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
  * = significant


This PR also address some code duplication in `ZipUtils`.

An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zipfs has some duplicate code that is left untouched) and reduce the need for `Unsafe` trickery. This enhancement and the microbenchmarks could then be used as verification and the `Unsafe` code backed out.

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

Commit messages:
 - Add main method to ZipFileOpen, enabling use as a startup benchmark
 - Remove ForceInline after verification it's not needed
 - Use Unsafe to coalesce reads in java.util.zip.ZipUtils

Changes: https://git.openjdk.org/jdk/pull/21377/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21377&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341594
  Stats: 96 lines in 3 files changed: 16 ins; 22 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/21377.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21377/head:pull/21377

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

From liach at openjdk.org  Sun Oct  6 14:39:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 14:39:41 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>

On Sat, 5 Oct 2024 16:32:39 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

src/java.base/share/classes/java/io/Reader.java line 152:

> 150:      * reader was being used by a single thread (as is generally the case).
> 151:      * Where possible, it is recommended that this class be used in preference
> 152:      * to {@code StringReader} as it will be faster under most implementations.

I believe this paragraph is redundant, now that `StringReader` is a somewhat-deprecated API that we aim to migrate away from. We can note these differences in the API notes of `StringReader`.

src/java.base/share/classes/java/io/Reader.java line 161:

> 159:      * {@code read(char[])}, {@code read(char[], int, int)},
> 160:      * {@code read(CharBuffer)}, {@code ready()}, {@code skip(long)}, and
> 161:      * {@code transferTo()} methods all throw {@code IOException}.

I believe these 2 paragraphs are all redundant besides the initial `The returned stream is initially open.` sentence: those are duplicating information already available from `Reader::close` specification.

Closing `StringReader` is optional but its specification doesn't mention this. I think we don't need to mention if closing is optional, so that one sentence is sufficient.

src/java.base/share/classes/java/io/Reader.java line 163:

> 161:      * {@code transferTo()} methods all throw {@code IOException}.
> 162:      *
> 163:      * <p> The {@code markSupported()} method returns {@code true}.

Suggestion:

     * <p>The returned reader supports the {@link #mark mark()} operation.

src/java.base/share/classes/java/io/Reader.java line 174:

> 172:      * @since 24
> 173:      */
> 174:     public static Reader of(CharSequence c) {

Should we give this factory a more specific name so we don't clash in the future? For example, if we add another factory `of(A a)` for interface `A`, then it would be confusing to have an instance of `interface C extends CharSequence, A` to be passed to `of`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789107588
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789111313
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789108008
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789104510

From liach at openjdk.org  Sun Oct  6 14:39:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 14:39:42 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>
Message-ID: <uTvJ0m5if6QDC0fn_e-HLeTxUJ_DSOkl1iTwkdNnXAY=.1e282f4d-c5b1-47f6-8af5-480f5796f1ab@github.com>

On Sat, 5 Oct 2024 16:48:56 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> src/java.base/share/classes/java/io/Reader.java line 341:
> 
>> 339:             public void close() {
>> 340:                 cs = null;
>> 341:             }
> 
> @AlanBateman I need to confess that I did not understand what you had in mind when you wrote this on the mailing list:
>> That doesn't excuse you completely from thinking about concurrent use as Readers have a close method so you'll need to think about how close is specified for when it is called while another thread is reading chars from a custom CS.
> 
> As this new implementation explicitly is for single-threaded use only, there is no such other thread that could call `close` concurrently.
> 
> Maybe I am missing something here, so I would kindly ask for an outline of a scenario where -despite the explicit single-thread note- a second thread *does* exist?

A scenario would be that this reader is shared by multiple threads in an argument to `Runnable`, like create 100 runnables, 50 are trying to close while 50 are reading to char arrays. There will be scenarios where some reading thread is reading while some closing thread invokes `close` and completes before the reading thread completes.

I think the key takeaway here is that `close` does not block until other threads finish reading, does not affect already-begun reading operations, and the closed state might not be immediately observed by other threads (as we do not release-write and acquire-read the cs clearing state). However, I don't know which of these attributes should be explicitly specified in our API specification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789113952

From shade at openjdk.org  Sun Oct  6 14:43:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Sun, 6 Oct 2024 14:43:09 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v8]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  More precise bit-unmasks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20139/files
  - new: https://git.openjdk.org/jdk/pull/20139/files/c3338302..cf808b9a

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

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

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

From liach at openjdk.org  Sun Oct  6 14:43:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 14:43:40 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils
In-Reply-To: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
Message-ID: <9beFzspMmChICPbJNINP-P19GuA5aEkGGOq65QiZwRw=.4982e4c8-d792-40ed-a341-0a6856cff62b@github.com>

On Sun, 6 Oct 2024 14:16:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
> 
> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
> 
> 
> make test TEST=micro:java.util.zip.ZipFile
> 
> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>   * = significant
> 
> 
> This PR also address some code duplication in `ZipUtils`.
> 
> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zipfs has some duplicate code that is left untouched) ...

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/util/zip/ZipUtils.java line 175:

> 173:     public static final int get16(byte[] b, int off) {
> 174:         Preconditions.checkIndex(off, b.length, Preconditions.AIOOBE_FORMATTER);
> 175:         Preconditions.checkIndex(off + 1, b.length, Preconditions.AIOOBE_FORMATTER);

Please use `Preconditions.checkFromIndexSize`, which should be less overhead:
Suggestion:

        Preconditions.checkFromIndexSize(off, 2, b.length, Preconditions.AIOOBE_FORMATTER);

Similarly for other methods.

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

PR Review: https://git.openjdk.org/jdk/pull/21377#pullrequestreview-2350546885
PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789116076

From eirbjo at openjdk.org  Sun Oct  6 14:48:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 6 Oct 2024 14:48:35 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils
In-Reply-To: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
Message-ID: <ltnncnIaPjtk1YkliDqnoDdooGNmIIXsWusKhnuXVqo=.c2088028-3ab1-4b95-ab39-b19daa256f9a@github.com>

On Sun, 6 Oct 2024 14:16:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
> 
> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
> 
> 
> make test TEST=micro:java.util.zip.ZipFile
> 
> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>   * = significant
> 
> 
> This PR also address some code duplication in `ZipUtils`.
> 
> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zipfs has some duplicate code that is left untouched) ...

test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 1:

> 1: /*

This file needs a copyright update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789118115

From duke at openjdk.org  Sun Oct  6 14:53:38 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 14:53:38 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
Message-ID: <5mL72m7q6LN2GB3ut_Ps8bB4FIM6W__2TZEnmgq9oQM=.232c5973-3e30-4161-90e2-7fae8a39cb27@github.com>

On Sun, 6 Oct 2024 14:20:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> src/java.base/share/classes/java/io/Reader.java line 152:
> 
>> 150:      * reader was being used by a single thread (as is generally the case).
>> 151:      * Where possible, it is recommended that this class be used in preference
>> 152:      * to {@code StringReader} as it will be faster under most implementations.
> 
> I believe this paragraph is redundant, now that `StringReader` is a somewhat-deprecated API that we aim to migrate away from. We can note these differences in the API notes of `StringReader`.

As Alan already proposed, I am just removing it in this very minute.

> src/java.base/share/classes/java/io/Reader.java line 174:
> 
>> 172:      * @since 24
>> 173:      */
>> 174:     public static Reader of(CharSequence c) {
> 
> Should we give this factory a more specific name so we don't clash in the future? For example, if we add another factory `of(A a)` for interface `A`, then it would be confusing to have an instance of `interface C extends CharSequence, A` to be passed to `of`.

I do not see what is "confusing" in that case, as the caller still gets what he intends: a reader for the passed source. I also wonder how likely that case actually is. Anyways, I may be biased as I proposed `of`.

@AlanBateman WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789120245
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789119975

From duke at openjdk.org  Sun Oct  6 14:56:37 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 14:56:37 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
Message-ID: <6ldzKUI3h9PGaHwA67VYyha6LNjNw9T_sOp_G56OXOw=.d20df34a-1fbd-417a-b625-b5c419c4d37d@github.com>

On Sun, 6 Oct 2024 14:21:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> src/java.base/share/classes/java/io/Reader.java line 163:
> 
>> 161:      * {@code transferTo()} methods all throw {@code IOException}.
>> 162:      *
>> 163:      * <p> The {@code markSupported()} method returns {@code true}.
> 
> Suggestion:
> 
>      * <p>The returned reader supports the {@link #mark mark()} operation.

This is not wrong. This style is used all over the place already within `Reader.java`, so it would be strange to change it *just here*.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789121226

From duke at openjdk.org  Sun Oct  6 15:00:34 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 15:00:34 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
Message-ID: <ro42GRalbSzHJG50rTBHzVYpLg0ZwVCAWJ6dZkdeDuo=.02250f13-cc02-439b-88f2-870fe3839d1c@github.com>

On Sun, 6 Oct 2024 14:29:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> src/java.base/share/classes/java/io/Reader.java line 161:
> 
>> 159:      * {@code read(char[])}, {@code read(char[], int, int)},
>> 160:      * {@code read(CharBuffer)}, {@code ready()}, {@code skip(long)}, and
>> 161:      * {@code transferTo()} methods all throw {@code IOException}.
> 
> I believe these 2 paragraphs are all redundant besides the initial `The returned stream is initially open.` sentence: those are duplicating information already available from `Reader::close` specification.
> 
> Closing `StringReader` is optional but its specification doesn't mention this. I think we don't need to mention if closing is optional, so that one sentence is sufficient.

This text already exists in this very file, it is a 1:1 copy from `nullReader()`. It cannot be wrong for `of()` if it was correct for `nullReader()`. To stay consistent with existing JavaDocs in this very same file, we should not have different texts for the same cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789122833

From duke at openjdk.org  Sun Oct  6 15:06:33 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 15:06:33 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <uTvJ0m5if6QDC0fn_e-HLeTxUJ_DSOkl1iTwkdNnXAY=.1e282f4d-c5b1-47f6-8af5-480f5796f1ab@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>
 <uTvJ0m5if6QDC0fn_e-HLeTxUJ_DSOkl1iTwkdNnXAY=.1e282f4d-c5b1-47f6-8af5-480f5796f1ab@github.com>
Message-ID: <dVyzjNDdzHTT1_jM5PzVD2sYfBeuhVDt1sJbaMPh2-o=.84d59144-8d8a-4005-beca-cefb254b11f5@github.com>

On Sun, 6 Oct 2024 14:35:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 341:
>> 
>>> 339:             public void close() {
>>> 340:                 cs = null;
>>> 341:             }
>> 
>> @AlanBateman I need to confess that I did not understand what you had in mind when you wrote this on the mailing list:
>>> That doesn't excuse you completely from thinking about concurrent use as Readers have a close method so you'll need to think about how close is specified for when it is called while another thread is reading chars from a custom CS.
>> 
>> As this new implementation explicitly is for single-threaded use only, there is no such other thread that could call `close` concurrently.
>> 
>> Maybe I am missing something here, so I would kindly ask for an outline of a scenario where -despite the explicit single-thread note- a second thread *does* exist?
>
> A scenario would be that this reader is shared by multiple threads in an argument to `Runnable`, like create 100 runnables, 50 are trying to close while 50 are reading to char arrays. There will be scenarios where some reading thread is reading while some closing thread invokes `close` and completes before the reading thread completes.
> 
> I think the key takeaway here is that `close` does not block until other threads finish reading, does not affect already-begun reading operations, and the closed state might not be immediately observed by other threads (as we do not release-write and acquire-read the cs clearing state). However, I don't know which of these attributes should be explicitly specified in our API specification.

As Alan suggested, I just now in this very minute have added a more clear statement about the fact that it is invalid to share this Reader instance among multiple threads without *external* synchronization. That will prevent the scenario you mention.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789124884

From redestad at openjdk.org  Sun Oct  6 15:14:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 15:14:05 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
Message-ID: <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>

> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
> 
> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
> 
> 
> make test TEST=micro:java.util.zip.ZipFile
> 
> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>   * = significant
> 
> 
> This PR also address some code duplication in `ZipUtils`.
> 
> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zipfs has some duplicate code that is left untouched) ...

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21377/files
  - new: https://git.openjdk.org/jdk/pull/21377/files/32010f66..d904ce64

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

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

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

From redestad at openjdk.org  Sun Oct  6 15:14:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 15:14:06 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <9beFzspMmChICPbJNINP-P19GuA5aEkGGOq65QiZwRw=.4982e4c8-d792-40ed-a341-0a6856cff62b@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <9beFzspMmChICPbJNINP-P19GuA5aEkGGOq65QiZwRw=.4982e4c8-d792-40ed-a341-0a6856cff62b@github.com>
Message-ID: <S1kBX1Ty4Rg_PuymhT5zfzET0lzOgTsK2bSjdYon2ag=.f501e20e-4bff-4829-8de5-74c263108943@github.com>

On Sun, 6 Oct 2024 14:40:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 175:
> 
>> 173:     public static final int get16(byte[] b, int off) {
>> 174:         Preconditions.checkIndex(off, b.length, Preconditions.AIOOBE_FORMATTER);
>> 175:         Preconditions.checkIndex(off + 1, b.length, Preconditions.AIOOBE_FORMATTER);
> 
> Please use `Preconditions.checkFromIndexSize`, which should be less overhead:
> Suggestion:
> 
>         Preconditions.checkFromIndexSize(off, 2, b.length, Preconditions.AIOOBE_FORMATTER);
> 
> Similarly for other methods.

It's actually not less overhead in my tests, since `checkIndex` is intrinsic and mostly disappears, while with `checkFromIndexSize` performance gets significantly worse (on par with baseline). It's on my todo to investigate this in-depth but I think `checkFromIndexSize` needs to be given similar intrinsification treatment as `checkIndex`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789126101

From liach at openjdk.org  Sun Oct  6 15:14:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 15:14:06 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <S1kBX1Ty4Rg_PuymhT5zfzET0lzOgTsK2bSjdYon2ag=.f501e20e-4bff-4829-8de5-74c263108943@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <9beFzspMmChICPbJNINP-P19GuA5aEkGGOq65QiZwRw=.4982e4c8-d792-40ed-a341-0a6856cff62b@github.com>
 <S1kBX1Ty4Rg_PuymhT5zfzET0lzOgTsK2bSjdYon2ag=.f501e20e-4bff-4829-8de5-74c263108943@github.com>
Message-ID: <hcwc_Hw0KvbTTjmgUgfx5p8x6OE7UFH7OT2UYj27fM8=.e21b6aaf-971c-4312-82a3-fab346ba4d88@github.com>

On Sun, 6 Oct 2024 15:07:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipUtils.java line 175:
>> 
>>> 173:     public static final int get16(byte[] b, int off) {
>>> 174:         Preconditions.checkIndex(off, b.length, Preconditions.AIOOBE_FORMATTER);
>>> 175:         Preconditions.checkIndex(off + 1, b.length, Preconditions.AIOOBE_FORMATTER);
>> 
>> Please use `Preconditions.checkFromIndexSize`, which should be less overhead:
>> Suggestion:
>> 
>>         Preconditions.checkFromIndexSize(off, 2, b.length, Preconditions.AIOOBE_FORMATTER);
>> 
>> Similarly for other methods.
>
> It's actually not less overhead in my tests, since `checkIndex` is intrinsic and mostly disappears, while with `checkFromIndexSize` performance gets significantly worse (on par with baseline). It's on my todo to investigate this in-depth but I think `checkFromIndexSize` needs to be given similar intrinsification treatment as `checkIndex`.

Actually if we trust the input index to be nonnegative, we can just check our end index for out of bounds too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789127887

From duke at openjdk.org  Sun Oct  6 15:23:15 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 15:23:15 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  fixup! Reader.of(String)
  
  Updated JavaDocs according to Alan Bateman's review comments:
  * Dropped "API compatible with StringReader" from description
  * @apiNote in StringReader refers to static factory method
  * Dropped "lock" field from API docs
  * Added "The resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization"
  * Deviating from your proposal, I renamed parameter "c" to "source" for clarity as the name "cs" already exists as an internal variable
  * Method specifies NPE for `of(null)` case
  
  I addition, JavaDocs now says "reader", not "stream" anymore.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/dc7dc814..7b83e407

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

  Stats: 19 lines in 2 files changed: 3 ins; 5 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

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

From duke at openjdk.org  Sun Oct  6 15:25:35 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 15:25:35 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
Message-ID: <-3gy6rcM3A_IZOqzxPour0WIFAwmyg8lf0lA1Dk4ZFE=.179a53ad-ab34-4cdc-b9d3-555e0e6b29c1@github.com>

On Sun, 6 Oct 2024 15:23:15 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Updated JavaDocs according to Alan Bateman's review comments:
>   * Dropped "API compatible with StringReader" from description
>   * @apiNote in StringReader refers to static factory method
>   * Dropped "lock" field from API docs
>   * Added "The resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization"
>   * Deviating from your proposal, I renamed parameter "c" to "source" for clarity as the name "cs" already exists as an internal variable
>   * Method specifies NPE for `of(null)` case
>   
>   I addition, JavaDocs now says "reader", not "stream" anymore.

Thank you, Alan! I have updated the JavaDocs according to your comments:
* Dropped "API compatible with StringReader" from description
* @apiNote in StringReader refers to static factory method
* Dropped "lock" field from API docs
* Added "The resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization"
* Deviating from your proposal, I renamed parameter "c" to "source" for clarity as the name "cs" already exists as an internal variable
* Method specifies NPE for `of(null)` case

I addition, JavaDocs now says "reader", not "stream" anymore.

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

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2395477698

From eirbjo at openjdk.org  Sun Oct  6 15:39:36 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 6 Oct 2024 15:39:36 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
Message-ID: <TzPmh6u1ToUS8Mg1JAYQ0k3nTAde4hFLzR-iqVkckPs=.7608afd5-4b23-4d9e-aaed-ab7be47a8f4d@github.com>

On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
>> 
>> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
>> 
>> 
>> make test TEST=micro:java.util.zip.ZipFile
>> 
>> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
>> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
>> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
>> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
>> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
>> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
>> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
>> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
>> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>>   * = significant
>> 
>> 
>> This PR also address some code duplication in `ZipUtils`.
>> 
>> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zi...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

Changes requested by eirbjo (Committer).

src/java.base/share/classes/java/util/zip/ZipFile.java line 1644:

> 1642:                 // Now scan the block backwards for END header signature
> 1643:                 for (int i = buf.length - ENDHDR; i >= 0; i--) {
> 1644:                     if (get32(buf, i) == ENDSIG) {

Maybe a matter of personal preference, but I think `GETSIG(buf, i) == ENDSIG` reads better than `get32(buf, i) == ENDSIG`.

The fact that it's 32 bits is kind of a detail and it doesn't reveal as well that we intend to read a signature.

So could we keep GETSIG, but add an index? There are places in `ZipInputStream` as well which could make use of that for signature checking. (But maybe not for this PR)

Alternatively, `ENDSIG(buf, i) == ENDSIG` would be consistent with `CENSIG(buf, i)` uses. 

Same applies to the other GETSIG replacements in this file.

src/java.base/share/classes/java/util/zip/ZipUtils.java line 258:

> 256:     static final long CENSIG(byte[] b, int pos) { return get32(b, pos + 0); }
> 257:     static final int  CENVEM(byte[] b, int pos) { return get16(b, pos + 4); }
> 258:     static final int  CENVEM_FA(byte[] b, int pos) { return Byte.toUnsignedInt(b[pos + 5]); } // file attribute compatibility

Did you consider introducing `get8` for consistency here? As it stands, this looks like the odd one out.

test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 110:

> 108:         zf2.close();
> 109:     }
> 110: 

A short comment stating the purpose of the main method would not hurt.

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

PR Review: https://git.openjdk.org/jdk/pull/21377#pullrequestreview-2350549495
PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789122069
PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789134874
PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789134125

From redestad at openjdk.org  Sun Oct  6 15:39:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 15:39:37 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <hcwc_Hw0KvbTTjmgUgfx5p8x6OE7UFH7OT2UYj27fM8=.e21b6aaf-971c-4312-82a3-fab346ba4d88@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <9beFzspMmChICPbJNINP-P19GuA5aEkGGOq65QiZwRw=.4982e4c8-d792-40ed-a341-0a6856cff62b@github.com>
 <S1kBX1Ty4Rg_PuymhT5zfzET0lzOgTsK2bSjdYon2ag=.f501e20e-4bff-4829-8de5-74c263108943@github.com>
 <hcwc_Hw0KvbTTjmgUgfx5p8x6OE7UFH7OT2UYj27fM8=.e21b6aaf-971c-4312-82a3-fab346ba4d88@github.com>
Message-ID: <_zx1n73JdcyWUrcJb3ONkBZ_ZWyDSLIhcOJhBBk1BRI=.90fb6d29-40db-4d54-8088-23e573832297@github.com>

On Sun, 6 Oct 2024 15:11:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> It's actually not less overhead in my tests, since `checkIndex` is intrinsic and mostly disappears, while with `checkFromIndexSize` performance gets significantly worse (on par with baseline). It's on my todo to investigate this in-depth but I think `checkFromIndexSize` needs to be given similar intrinsification treatment as `checkIndex`.
>
> Actually if we trust the input index to be nonnegative, we can just check our end index for out of bounds too.

Sure, I think the JIT is pretty good at eliminating the (intrinsic) `checkIndex` calls when they are redundant though. Performance with and without these `checkIndex`es are the same in my testing, so we can eat and have the cake on this one.

FWIW I wouldn't mind giving similar treatment to `ByteArray(-LittleEndian)` and avoid the `VarHandles` dependency in those utility classes, but I have no urge to get into the sort of discussions that were spawned in #19616

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789137335

From eirbjo at openjdk.org  Sun Oct  6 15:45:34 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 6 Oct 2024 15:45:34 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
Message-ID: <L9oCESQLK0SJVS58IJAAD9gRKMh2QxT152VHhUMs-SI=.7bb65a43-f0c0-4e06-9675-84a0ca510bd7@github.com>

On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
>> 
>> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
>> 
>> 
>> make test TEST=micro:java.util.zip.ZipFile
>> 
>> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
>> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
>> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
>> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
>> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
>> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
>> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
>> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
>> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>>   * = significant
>> 
>> 
>> This PR also address some code duplication in `ZipUtils`.
>> 
>> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zi...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

src/java.base/share/classes/java/util/zip/ZipUtils.java line 248:

> 246:     static final int  ENDCOM(byte[] b, int off) { return get16(b, off + 20);}
> 247: 
> 248:     // zip64 end of central directory recoder fields

Suggestion:

    // zip64 end of central directory record fields

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789139692

From redestad at openjdk.org  Sun Oct  6 15:45:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 15:45:35 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <TzPmh6u1ToUS8Mg1JAYQ0k3nTAde4hFLzR-iqVkckPs=.7608afd5-4b23-4d9e-aaed-ab7be47a8f4d@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
 <TzPmh6u1ToUS8Mg1JAYQ0k3nTAde4hFLzR-iqVkckPs=.7608afd5-4b23-4d9e-aaed-ab7be47a8f4d@github.com>
Message-ID: <pYpKal_gXrTcYCdTokE3JBhkN6O1aL_Wgg3nUgtgcYc=.a37e9691-4067-4e9c-86ba-ea0da8556896@github.com>

On Sun, 6 Oct 2024 15:29:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 258:
> 
>> 256:     static final long CENSIG(byte[] b, int pos) { return get32(b, pos + 0); }
>> 257:     static final int  CENVEM(byte[] b, int pos) { return get16(b, pos + 4); }
>> 258:     static final int  CENVEM_FA(byte[] b, int pos) { return Byte.toUnsignedInt(b[pos + 5]); } // file attribute compatibility
> 
> Did you consider introducing `get8` for consistency here? As it stands, this looks like the odd one out.

I considered it, but since `get8` would basically just delegate to or do exactly what `Byte.toUnsignedInt` does I opted to cut out the middle man.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789139614

From eirbjo at openjdk.org  Sun Oct  6 15:51:34 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 6 Oct 2024 15:51:34 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <_zx1n73JdcyWUrcJb3ONkBZ_ZWyDSLIhcOJhBBk1BRI=.90fb6d29-40db-4d54-8088-23e573832297@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <9beFzspMmChICPbJNINP-P19GuA5aEkGGOq65QiZwRw=.4982e4c8-d792-40ed-a341-0a6856cff62b@github.com>
 <S1kBX1Ty4Rg_PuymhT5zfzET0lzOgTsK2bSjdYon2ag=.f501e20e-4bff-4829-8de5-74c263108943@github.com>
 <hcwc_Hw0KvbTTjmgUgfx5p8x6OE7UFH7OT2UYj27fM8=.e21b6aaf-971c-4312-82a3-fab346ba4d88@github.com>
 <_zx1n73JdcyWUrcJb3ONkBZ_ZWyDSLIhcOJhBBk1BRI=.90fb6d29-40db-4d54-8088-23e573832297@github.com>
Message-ID: <6fCaBlFrmbxZA7NIKBH_pzu20k7o4GAVk_r855LAqxA=.eb70357f-2fa8-4b92-8742-24dcc51f46ae@github.com>

On Sun, 6 Oct 2024 15:35:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Actually if we trust the input index to be nonnegative, we can just check our end index for out of bounds too.
>
> Sure, I think the JIT is pretty good at eliminating the (intrinsic) `checkIndex` calls when they are redundant though. Performance with and without these `checkIndex`es are the same in my testing, so we can eat and have the cake on this one.
> 
> FWIW I wouldn't mind giving similar treatment to `ByteArray(-LittleEndian)` and avoid the `VarHandles` dependency in those utility classes, but I have no urge to get into the sort of discussions that were spawned in #19616

> Actually if we trust the input index to be nonnegative, we can just check our end index for out of bounds too.

I would not trust that. Perhaps for well-formed ZIP files, but trust me, not all ZIPs are well-formed ;-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789142344

From eirbjo at openjdk.org  Sun Oct  6 15:56:34 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 6 Oct 2024 15:56:34 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
Message-ID: <k-S9nKpxa3RLlPhQjPz34FlJ7j_5KrcvGT-FupyzAjk=.371705c2-c60a-4414-8323-20c95fea67d3@github.com>

On Sun, 6 Oct 2024 15:14:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
>> 
>> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
>> 
>> 
>> make test TEST=micro:java.util.zip.ZipFile
>> 
>> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
>> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
>> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
>> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
>> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
>> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
>> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
>> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
>> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>>   * = significant
>> 
>> 
>> This PR also address some code duplication in `ZipUtils`.
>> 
>> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zi...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

src/java.base/share/classes/java/util/zip/ZipUtils.java line 195:

> 193:      * The bytes are assumed to be in Intel (little-endian) byte order.
> 194:      */
> 195:     public static final long get64(byte[] b, int off) {

This method returns a signed 64 bit value, which I think is not what some of its call sites expect. It should in any case be renamed to `get64S` to align with `get32S`. A new method `get64` should be introduced and any call site expecting unsigned numbers (most?) should use that instead.

If you don't want to deal with this in this PR, I could file an issue and suggest a PR for this. Let me know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789144124

From liach at openjdk.org  Sun Oct  6 16:01:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 16:01:34 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <6fCaBlFrmbxZA7NIKBH_pzu20k7o4GAVk_r855LAqxA=.eb70357f-2fa8-4b92-8742-24dcc51f46ae@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <9beFzspMmChICPbJNINP-P19GuA5aEkGGOq65QiZwRw=.4982e4c8-d792-40ed-a341-0a6856cff62b@github.com>
 <S1kBX1Ty4Rg_PuymhT5zfzET0lzOgTsK2bSjdYon2ag=.f501e20e-4bff-4829-8de5-74c263108943@github.com>
 <hcwc_Hw0KvbTTjmgUgfx5p8x6OE7UFH7OT2UYj27fM8=.e21b6aaf-971c-4312-82a3-fab346ba4d88@github.com>
 <_zx1n73JdcyWUrcJb3ONkBZ_ZWyDSLIhcOJhBBk1BRI=.90fb6d29-40db-4d54-8088-23e573832297@github.com>
 <6fCaBlFrmbxZA7NIKBH_pzu20k7o4GAVk_r855LAqxA=.eb70357f-2fa8-4b92-8742-24dcc51f46ae@github.com>
Message-ID: <7FvDWxnj7vd8fRyX6gQ3Fzflkhb7e7Ji8gZ7P1LUY2w=.37769098-9d4f-4560-8dcf-a2dcd74d5ae9@github.com>

On Sun, 6 Oct 2024 15:48:57 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Sure, I think the JIT is pretty good at eliminating the (intrinsic) `checkIndex` calls when they are redundant though. Performance with and without these `checkIndex`es are the same in my testing, so we can eat and have the cake on this one.
>> 
>> FWIW I wouldn't mind giving similar treatment to `ByteArray(-LittleEndian)` and avoid the `VarHandles` dependency in those utility classes, but I have no urge to get into the sort of discussions that were spawned in #19616
>
>> Actually if we trust the input index to be nonnegative, we can just check our end index for out of bounds too.
> 
> I would not trust that. Perhaps for well-formed ZIP files, but trust me, not all ZIPs are well-formed ;-)

Yep, that requires you to pre-validate the input argument as a fixed position after already-read content, which is not always the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789146112

From redestad at openjdk.org  Sun Oct  6 16:15:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 16:15:36 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <TzPmh6u1ToUS8Mg1JAYQ0k3nTAde4hFLzR-iqVkckPs=.7608afd5-4b23-4d9e-aaed-ab7be47a8f4d@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
 <TzPmh6u1ToUS8Mg1JAYQ0k3nTAde4hFLzR-iqVkckPs=.7608afd5-4b23-4d9e-aaed-ab7be47a8f4d@github.com>
Message-ID: <qtuX1h-zn-TFEFRSMTIHGgwQHHAuVp8BBMajjsrsE3E=.142ace04-b1e9-41ad-b325-57274acdb3c3@github.com>

On Sun, 6 Oct 2024 14:56:27 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1644:
> 
>> 1642:                 // Now scan the block backwards for END header signature
>> 1643:                 for (int i = buf.length - ENDHDR; i >= 0; i--) {
>> 1644:                     if (get32(buf, i) == ENDSIG) {
> 
> Maybe a matter of personal preference, but I think `GETSIG(buf, i) == ENDSIG` reads better than `get32(buf, i) == ENDSIG`.
> 
> The fact that it's 32 bits is kind of a detail and it doesn't reveal as well that we intend to read a signature.
> 
> So could we keep GETSIG, but add an index? There are places in `ZipInputStream` as well which could make use of that for signature checking. (But maybe not for this PR)
> 
> Alternatively, `ENDSIG(buf, i) == ENDSIG` would be consistent with `CENSIG(buf, i)` uses. 
> 
> Same applies to the other GETSIG replacements in this file.

I think all the `GETSIG(byte[])` methods are quite nasty, and it's all used very inconsistently. I wouldn't mind going the other way and removing _all_ the `CENSIG`, `LOCNAM` etc methods and just call `get16/32/32S/64(buf, <field name>)` as appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789151311

From liach at openjdk.org  Sun Oct  6 16:29:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 16:29:40 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications [v3]
In-Reply-To: <6PltJ5oj9C3FSBM4-pdQJJgrk11xiJS_SI8aQvn-1Do=.bd5af85b-7015-4b09-8c52-6d492bc19a4b@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
 <6PltJ5oj9C3FSBM4-pdQJJgrk11xiJS_SI8aQvn-1Do=.bd5af85b-7015-4b09-8c52-6d492bc19a4b@github.com>
Message-ID: <XrsbbNdFg24_VnCZdhK4OfazF2bXqcYjbdhUWcC2EC8=.18522832-ecc9-41ff-949f-28380f271409@github.com>

On Mon, 30 Sep 2024 14:59:12 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

This time the github ci builds pass, hope things are fine...

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

PR Comment: https://git.openjdk.org/jdk/pull/20796#issuecomment-2395497754

From duke at openjdk.org  Sun Oct  6 16:29:40 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Sun, 6 Oct 2024 16:29:40 GMT
Subject: Integrated: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications
In-Reply-To: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
Message-ID: <Hz771NQCg5puzD5_dAGbglqixsT2R0TgHZ4IzdopfZQ=.469e35c0-2fd2-458e-9780-c1027232ba54@github.com>

On Fri, 30 Aug 2024 15:08:20 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.

This pull request has now been integrated.

Changeset: 20f36c66
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20f36c666c30e50c446d09cca4ea52395317a7eb
Stats:     8 lines in 2 files changed: 4 ins; 0 del; 4 mod

8339329: ConstantPoolBuilder#constantValueEntry method doc typo and clarifications

Reviewed-by: liach

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

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

From liach at openjdk.org  Sun Oct  6 16:30:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 16:30:36 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <TzPmh6u1ToUS8Mg1JAYQ0k3nTAde4hFLzR-iqVkckPs=.7608afd5-4b23-4d9e-aaed-ab7be47a8f4d@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
 <TzPmh6u1ToUS8Mg1JAYQ0k3nTAde4hFLzR-iqVkckPs=.7608afd5-4b23-4d9e-aaed-ab7be47a8f4d@github.com>
Message-ID: <E4lC3nc1G7SgxaD9lz11Ih0_DEa-g4ziKeFhEk4BMHE=.19fe674f-4689-4862-b6ac-aac6d18794a4@github.com>

On Sun, 6 Oct 2024 15:27:07 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 110:
> 
>> 108:         zf2.close();
>> 109:     }
>> 110: 
> 
> A short comment stating the purpose of the main method would not hurt.

https://github.com/openjdk/jdk/pull/19477#discussion_r1725802115

This applies to many benchmarks, so I wonder where is the best place for such a note.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789156614

From liach at openjdk.org  Sun Oct  6 16:44:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 16:44:34 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <ro42GRalbSzHJG50rTBHzVYpLg0ZwVCAWJ6dZkdeDuo=.02250f13-cc02-439b-88f2-870fe3839d1c@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
 <ro42GRalbSzHJG50rTBHzVYpLg0ZwVCAWJ6dZkdeDuo=.02250f13-cc02-439b-88f2-870fe3839d1c@github.com>
Message-ID: <vTTJuvu_Lu2Pip4XMHuxTtdT7YkbZnusGlpUimvMuMI=.24bc014b-70f9-4ae2-99d0-b071f06f6e02@github.com>

On Sun, 6 Oct 2024 14:58:23 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 161:
>> 
>>> 159:      * {@code read(char[])}, {@code read(char[], int, int)},
>>> 160:      * {@code read(CharBuffer)}, {@code ready()}, {@code skip(long)}, and
>>> 161:      * {@code transferTo()} methods all throw {@code IOException}.
>> 
>> I believe these 2 paragraphs are all redundant besides the initial `The returned stream is initially open.` sentence: those are duplicating information already available from `Reader::close` specification.
>> 
>> Closing `StringReader` is optional but its specification doesn't mention this. I think we don't need to mention if closing is optional, so that one sentence is sufficient.
>
> This text already exists in this very file, it is a 1:1 copy from `nullReader()`. It cannot be wrong for `of()` if it was correct for `nullReader()`. To stay consistent with existing JavaDocs in this very same file, we should not have different texts for the same cases.

`nullReader` needs this because it specifies the open behavior of these methods. This API does not have to; we can check out how others think in the CSR review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789158447

From liach at openjdk.org  Sun Oct  6 16:44:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 16:44:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
Message-ID: <odqOItnwT466uvC-KfooM2cZ9WqlHNqSL3_d6wQOJQI=.0a483584-d6a0-4a81-824f-23b8e9205106@github.com>

On Sun, 6 Oct 2024 15:23:15 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Updated JavaDocs according to Alan Bateman's review comments:
>   * Dropped "API compatible with StringReader" from description
>   * @apiNote in StringReader refers to static factory method
>   * Dropped "lock" field from API docs
>   * Added "The resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization"
>   * Deviating from your proposal, I renamed parameter "c" to "source" for clarity as the name "cs" already exists as an internal variable
>   * Method specifies NPE for `of(null)` case
>   
>   I addition, JavaDocs now says "reader", not "stream" anymore.

src/java.base/share/classes/java/io/Reader.java line 174:

> 172:         return new Reader() {
> 173:             private final int length = source.length();
> 174:             private CharSequence cs = source;

Can we make this `cs` final and track the closed state either in a new boolean field or with a negative value in `next`? In fact, if we make `cs` final, we can just replace the `cs` field referenced with the captured `source`.

src/java.base/share/classes/java/io/Reader.java line 187:

> 185:              * Reads a single character.
> 186:              *
> 187:              * @return     The character read, or -1 if the end of the stream has been

Don't need these javadocs; this implementation class is not publicly visible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789160758
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789160971

From liach at openjdk.org  Sun Oct  6 16:44:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 6 Oct 2024 16:44:37 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>
Message-ID: <kWAQ_rylD-s6KOYHQTdM6uT_qcnTmQKM6rVbWh0dir4=.c8c24b58-7f46-44f8-8be5-dca7f58dcee9@github.com>

On Sat, 5 Oct 2024 16:45:01 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! Reader.of(String)
>>   
>>   Updated JavaDocs according to Alan Bateman's review comments:
>>   * Dropped "API compatible with StringReader" from description
>>   * @apiNote in StringReader refers to static factory method
>>   * Dropped "lock" field from API docs
>>   * Added "The resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization"
>>   * Deviating from your proposal, I renamed parameter "c" to "source" for clarity as the name "cs" already exists as an internal variable
>>   * Method specifies NPE for `of(null)` case
>>   
>>   I addition, JavaDocs now says "reader", not "stream" anymore.
>
> test/jdk/java/io/Reader/Of.java line 51:
> 
>> 49:     public static Reader[] readers() {
>> 50:         return new Reader[] {
>> 51:             new StringReader(CONTENT),
> 
> Explicitly including that original class here (even if it has nothing to do with the `of` method) to be sure that we did not modify it in an incompatible way. Unfortunately there is no full test coverage for `StringReader`, and it does not make much sense to duplicate the tests.

I recommend adding another test case against an ad-hoc `CharSequence` implementation wrapping a `char[]` in a record, to ensure the generic paths in `read(char[], int, int)` works as intended.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789161659

From duke at openjdk.org  Sun Oct  6 17:37:34 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 17:37:34 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <vTTJuvu_Lu2Pip4XMHuxTtdT7YkbZnusGlpUimvMuMI=.24bc014b-70f9-4ae2-99d0-b071f06f6e02@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
 <ro42GRalbSzHJG50rTBHzVYpLg0ZwVCAWJ6dZkdeDuo=.02250f13-cc02-439b-88f2-870fe3839d1c@github.com>
 <vTTJuvu_Lu2Pip4XMHuxTtdT7YkbZnusGlpUimvMuMI=.24bc014b-70f9-4ae2-99d0-b071f06f6e02@github.com>
Message-ID: <ufTICA9iPepfHoRVw-uSgmm29mTrPQbCRvbsy029nt4=.8330c8d3-c2f8-4311-9e13-8440d1791366@github.com>

On Sun, 6 Oct 2024 16:32:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This text already exists in this very file, it is a 1:1 copy from `nullReader()`. It cannot be wrong for `of()` if it was correct for `nullReader()`. To stay consistent with existing JavaDocs in this very same file, we should not have different texts for the same cases.
>
> `nullReader` needs this because it specifies the open behavior of these methods. This API does not have to; we can check out how others think in the CSR review.

I have forwarded the current proposal as-is to the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789174531

From duke at openjdk.org  Sun Oct  6 17:37:35 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 17:37:35 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <odqOItnwT466uvC-KfooM2cZ9WqlHNqSL3_d6wQOJQI=.0a483584-d6a0-4a81-824f-23b8e9205106@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
 <odqOItnwT466uvC-KfooM2cZ9WqlHNqSL3_d6wQOJQI=.0a483584-d6a0-4a81-824f-23b8e9205106@github.com>
Message-ID: <Z8u0xGwDAZ2Wwh-ahLTVdgo4rstXVEhwZisWGi90Chs=.f63b1419-c32d-4f62-b390-db85fcbc67bd@github.com>

On Sun, 6 Oct 2024 16:39:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! Reader.of(String)
>>   
>>   Updated JavaDocs according to Alan Bateman's review comments:
>>   * Dropped "API compatible with StringReader" from description
>>   * @apiNote in StringReader refers to static factory method
>>   * Dropped "lock" field from API docs
>>   * Added "The resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization"
>>   * Deviating from your proposal, I renamed parameter "c" to "source" for clarity as the name "cs" already exists as an internal variable
>>   * Method specifies NPE for `of(null)` case
>>   
>>   I addition, JavaDocs now says "reader", not "stream" anymore.
>
> src/java.base/share/classes/java/io/Reader.java line 174:
> 
>> 172:         return new Reader() {
>> 173:             private final int length = source.length();
>> 174:             private CharSequence cs = source;
> 
> Can we make this `cs` final and track the closed state either in a new boolean field or with a negative value in `next`? In fact, if we make `cs` final, we can just replace the `cs` field referenced with the captured `source`.

This is correct, but then we would keep the reference to the char sequence "forever", without any good reason. This content could be *huge* (and often it is, as `CharSequence` most often is a `StringBuilder` just because the application *wants* to create huge content, and `String`-concatenation would be too costly with *huge* content). In fact, I see this scenario as the top use case for this new API.

Having said that, I would really like to have this field non-final to unlink the reference to the source as soon as possible, implicitly allowing GC to free this unused memory.

> src/java.base/share/classes/java/io/Reader.java line 187:
> 
>> 185:              * Reads a single character.
>> 186:              *
>> 187:              * @return     The character read, or -1 if the end of the stream has been
> 
> Don't need these javadocs; this implementation class is not publicly visible.

Correct. If everybody is fine with that, I will drop it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789176596
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789177381

From duke at openjdk.org  Sun Oct  6 17:37:36 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 17:37:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <kWAQ_rylD-s6KOYHQTdM6uT_qcnTmQKM6rVbWh0dir4=.c8c24b58-7f46-44f8-8be5-dca7f58dcee9@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>
 <kWAQ_rylD-s6KOYHQTdM6uT_qcnTmQKM6rVbWh0dir4=.c8c24b58-7f46-44f8-8be5-dca7f58dcee9@github.com>
Message-ID: <pT_K6-FjqOsV9TEp75t3B-_WkT3H6vGYxT7VJzAYuvs=.d186b40a-bd4f-4c5e-b3e9-68609c27de76@github.com>

On Sun, 6 Oct 2024 16:41:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/jdk/java/io/Reader/Of.java line 51:
>> 
>>> 49:     public static Reader[] readers() {
>>> 50:         return new Reader[] {
>>> 51:             new StringReader(CONTENT),
>> 
>> Explicitly including that original class here (even if it has nothing to do with the `of` method) to be sure that we did not modify it in an incompatible way. Unfortunately there is no full test coverage for `StringReader`, and it does not make much sense to duplicate the tests.
>
> I recommend adding another test case against an ad-hoc `CharSequence` implementation wrapping a `char[]` in a record, to ensure the generic paths in `read(char[], int, int)` works as intended.

Good idea. But instead, we could also add a new API `CharSequence.of(char[])` and test *that* class? WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789179234

From duke at openjdk.org  Sun Oct  6 17:44:53 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 17:44:53 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  fixup! Reader.of(String)
  
  Dropping non-public JavaDocs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/7b83e407..ae9f5845

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

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

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

From duke at openjdk.org  Sun Oct  6 17:44:53 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 17:44:53 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <Z8u0xGwDAZ2Wwh-ahLTVdgo4rstXVEhwZisWGi90Chs=.f63b1419-c32d-4f62-b390-db85fcbc67bd@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
 <odqOItnwT466uvC-KfooM2cZ9WqlHNqSL3_d6wQOJQI=.0a483584-d6a0-4a81-824f-23b8e9205106@github.com>
 <Z8u0xGwDAZ2Wwh-ahLTVdgo4rstXVEhwZisWGi90Chs=.f63b1419-c32d-4f62-b390-db85fcbc67bd@github.com>
Message-ID: <hvfw1xkU-ECY43RbEeDIqtXUJv_J-MaRVbk9FCNgB-c=.18d80126-17d0-46a6-ad4c-b1bcb598845c@github.com>

On Sun, 6 Oct 2024 17:25:55 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 187:
>> 
>>> 185:              * Reads a single character.
>>> 186:              *
>>> 187:              * @return     The character read, or -1 if the end of the stream has been
>> 
>> Don't need these javadocs; this implementation class is not publicly visible.
>
> Correct. If everybody is fine with that, I will drop it.

Dropped it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789182924

From duke at openjdk.org  Sun Oct  6 17:47:35 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 6 Oct 2024 17:47:35 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
Message-ID: <g_dUnA-gKu17Q_BDo98oxK6Gh6SnIAuqS8qpVBmubAw=.c7bef064-2610-461b-845b-95d290885688@github.com>

On Sun, 6 Oct 2024 15:23:15 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Updated JavaDocs according to Alan Bateman's review comments:
>   * Dropped "API compatible with StringReader" from description
>   * @apiNote in StringReader refers to static factory method
>   * Dropped "lock" field from API docs
>   * Added "The resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization"
>   * Deviating from your proposal, I renamed parameter "c" to "source" for clarity as the name "cs" already exists as an internal variable
>   * Method specifies NPE for `of(null)` case
>   
>   I addition, JavaDocs now says "reader", not "stream" anymore.

> /csr

@AlanBateman Can you please review [the CSR request](https://bugs.openjdk.org/browse/JDK-8341596) so I can finish it? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2395522316

From rafael.wth at gmail.com  Sun Oct  6 17:48:08 2024
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Sun, 6 Oct 2024 19:48:08 +0200
Subject: ClassLoader API to look up class files
In-Reply-To: <7f1294fb-0191-4b4a-8e2e-2307bb589c55@oracle.com>
References: <CA+DM0AkCN8YF18rnxb=skNZ_HJ3aTAyG5xpm0imM_R0tOQq3AA@mail.gmail.com>
 <CA+pBWhueM8=XueKLXE72vnnGG0C_ueuubWFbaCrXHgD3KPU0Aw@mail.gmail.com>
 <CA+DM0Am+Zh7t5D3c2vVv0Jo36ps4i8BB+5hZghaEK+9=m0Dn8g@mail.gmail.com>
 <ebf64903-6967-4c8c-9a98-a1646b3114da@oracle.com>
 <CA+DM0A=DQJe2iNJFt8yNEiga=U2LNFYAnqJfUjac0N8BtbFc1w@mail.gmail.com>
 <9a384b05-9283-413c-91db-3cd6a5ef31b9@oracle.com>
 <CA+DM0A=CwxA_7Mb+2o++JVBMFRM8-mivC=xiDGA=Bvtcn0J0Ng@mail.gmail.com>
 <1df40152-d011-4629-a5b3-aeed667d9761@oracle.com>
 <CA+DM0AkVn0b=q=D=3+mKF+F6cNO4UHY-FvdC55wsKv1p85kcYQ@mail.gmail.com>
 <7f1294fb-0191-4b4a-8e2e-2307bb589c55@oracle.com>
Message-ID: <CA+DM0AkgMcytZ9aVmW_sk+eOJVtK4dKF+LZ=HizoG_DpB-jk5A@mail.gmail.com>

This would likely work for those cases. The Byte Buddy plugins for Gradle
and Maven discover today what release version is configured in the compile
step, and uses that version for configuring the class file locators that it
can configure. If a release version is for example set to Java 17, the
class file locators would discover MR class files for Java 17 on both a
version 17 and a version 21 VM, where possible. Jar files are then
initialized using this version, and the same goes for reading from folders.
If I could supply a version to a URLClassLoader, too, I would also set that
version and could supply URLs to it as it is done today. To some degree,
those who implement their custom class loaders would anyways be responsible
to implement such a mechanism for those. Mainly I was wondering if the API
should be standardized via a method, but your suggested approach would of
course work, too, in practice.

Am Di., 24. Sept. 2024 um 20:11 Uhr schrieb Alan Bateman <
alan.bateman at oracle.com>:

>
>
> On 24/09/2024 17:47, Rafael Winterhalter wrote:
> > Byte Buddy attempts to avoid class loading during build
> > instrumentation, as this might have side-effects when types are
> > loaded, and described, using the reflection API. Therefore Byte Buddy
> > parses class files itself and offers its own representation. 99.9% of
> > users will be able to provide all relevant class files by pointing to
> > a jar file or a folder with classes, and Byte Buddy will treat this as
> > a form of class path to describe the dependency tree to the build time
> > instrumentation, without loading any classes. As an option for the
> > reminding 0.1%, dependencies can also be provided using a ClassLoader.
> > A case I have encountered more than once is that a custom ClassLoader
> > generates classes on demand if queried. To support this, Byte Buddy
> > then queries the ClassLoader for ".class" files also, without
> > processing a jar file or folder directly.
> >
> > As of today, I have no way to tell the class loader that the target
> > version of the build plugin is for example Java 17, and that I want
> > the Java 17 version of a class file. I can query for META-INF/versions
> > 8-17 to see if there is a class file for that name (rather
> > inefficient). But if the build is run on a Java 21 JVM and there is a
> > META-INF/versions/21 version of a class, the Java 17 "original" class
> > file is not available to me. This is why I was wondering if there
> > should be a method to query a resource "as if" it was requested for a
> > particular version that is not the current JVM (or
> > JarFile-constructor-supplied) version.
> >
> > Does this describe my problem better? I understand that this really is
> > an edge case. Then again I think this is a legitimate problem that
> > should be solvable. And with a shift towards build-time
> > instrumentation and likely growing adoption of MR JAR files, I would
> > of course want to solve this in Byte Buddy, if given the opportunity.
> >
> Thanks, I think the scenario is a much clearer now but I don't think
> adding a method to ClassLoader to aid this scenario is the right thing
> to do.
>
> Instead, this feels like a ClassLoader implementation that is created
> with a Runtime.Version and excels at serving up resources. That's
> effectively what you get with using JDK tools like jdeps with the
> --multi-release N option. That ClassLoader implementation would create
> JarFiles with the Runtime.Version so it will locate the resources in MR
> JARs for that version. If you had such a ClassLoader implementation,
> could you fit into the build steps?
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241006/e9bd026c/attachment-0001.htm>

From duke at openjdk.org  Sun Oct  6 17:58:36 2024
From: duke at openjdk.org (Bernd)
Date: Sun, 6 Oct 2024 17:58:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <6ldzKUI3h9PGaHwA67VYyha6LNjNw9T_sOp_G56OXOw=.d20df34a-1fbd-417a-b625-b5c419c4d37d@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
 <6ldzKUI3h9PGaHwA67VYyha6LNjNw9T_sOp_G56OXOw=.d20df34a-1fbd-417a-b625-b5c419c4d37d@github.com>
Message-ID: <Jxilv7cTmgx8_mCRfRclli7KnX1ulnXEAkxhXLHypRc=.212411b3-6aca-4d35-aba6-8ebf9bbb7786@github.com>

On Sun, 6 Oct 2024 14:54:22 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 163:
>> 
>>> 161:      * {@code transferTo()} methods all throw {@code IOException}.
>>> 162:      *
>>> 163:      * <p> The {@code markSupported()} method returns {@code true}.
>> 
>> Suggestion:
>> 
>>      * <p>The returned reader supports the {@link #mark mark()} operation.
>
> This is not wrong. This exact wording is already used in `Reader.java`, so it would be strange to change it *just here*.

You can ?elaborately? the close and mark protocol in the Reader interface and then only mention itnadgeres to it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789187627

From duke at openjdk.org  Sun Oct  6 18:08:36 2024
From: duke at openjdk.org (Bernd)
Date: Sun, 6 Oct 2024 18:08:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
Message-ID: <sPBzh8qERLoHb-zhlcwqmTxQJHRgF-CIXMGqJnGMBGg=.75ccbf48-f7ad-4f35-b67f-8b31fe224d60@github.com>

On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Dropping non-public JavaDocs

src/java.base/share/classes/java/io/Reader.java line 231:

> 229:             public boolean ready() throws IOException {
> 230:                 ensureOpen();
> 231:                 return true;

I guess it?s not wrong, but can this be false when end of source is reached? Related to this you already described it is not synchronized but should we also describe it does not support changes to the length during ?iteration? (could be in the same thread).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789190894

From duke at openjdk.org  Sun Oct  6 18:15:35 2024
From: duke at openjdk.org (Bernd)
Date: Sun, 6 Oct 2024 18:15:35 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <pT_K6-FjqOsV9TEp75t3B-_WkT3H6vGYxT7VJzAYuvs=.d186b40a-bd4f-4c5e-b3e9-68609c27de76@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>
 <kWAQ_rylD-s6KOYHQTdM6uT_qcnTmQKM6rVbWh0dir4=.c8c24b58-7f46-44f8-8be5-dca7f58dcee9@github.com>
 <pT_K6-FjqOsV9TEp75t3B-_WkT3H6vGYxT7VJzAYuvs=.d186b40a-bd4f-4c5e-b3e9-68609c27de76@github.com>
Message-ID: <4NhYHpnhVsaWgmz2u4vf2DP0ojj-jbOV7vtgxycmb1g=.93654fbb-bcca-4af9-84c8-f13155ddbefa@github.com>

On Sun, 6 Oct 2024 17:31:42 GMT, Markus KARG <duke at openjdk.org> wrote:

>> I recommend adding another test case against an ad-hoc `CharSequence` implementation wrapping a `char[]` in a record, to ensure the generic paths in `read(char[], int, int)` works as intended.
>
> Good idea. But instead, we could also add a new API `CharSequence.of(char[])` and test *that* class? WDYT?

> Good idea. But instead, we could also add a new API `CharSequence.of(char[])` and test _that_ class? WDYT?

Both you need to test the generic case anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789192905

From duke at openjdk.org  Sun Oct  6 18:15:36 2024
From: duke at openjdk.org (Bernd)
Date: Sun, 6 Oct 2024 18:15:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
Message-ID: <58-cunZZhUAeoGtIRxxaGHIwfe1ib0ysT3FhHrdgtxM=.72ff4faf-347b-4246-a190-17d47dbf78d9@github.com>

On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Dropping non-public JavaDocs

test/jdk/java/io/Reader/Of.java line 63:

> 61:     @Test(dataProvider = "readers")
> 62:     public void testOpen(Reader reader) {
> 63:         assertNotNull(reader, "Reader.of(String) returned null");

This does not look like a useful test and the assert is misleading (no String)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789193686

From eirbjo at openjdk.org  Sun Oct  6 18:20:44 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 6 Oct 2024 18:20:44 GMT
Subject: RFR: 8341597: ZipFileInflaterInputStream input buffer size uses
 uncompressed size
Message-ID: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>

Please review this PR which proposes to change the input buffer size of `ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP entry instead of the _uncompressed_ size. This saves allocation since buffers will no longer be oversized:

* The `size` parameter passed to the `ZipFileInflaterInputStream` constructor is passed on to the superclass `InflaterInputStream` where it determines the size of the input buffer. This buffer is used to read compressed data and pass it on to the `Inflater`.
* `ZipFile:getInputStream` currently looks at the _uncompressed_ size when determining the input buffer size. It should instead use the _compressed_ size, since this buffer is used for compressed, not uncompressed data.
* The current implementation somewhat mysteriously adds 2 to the uncompressed size. My guess is that this is to allow fitting a two-byte DEFLATE header for empty files (where the uncompressed size is 0 and the compressed size is 2).
* There is a check for `size <= 0`. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be `>= 2`. I propose we remove this check.

Performance: A benchmark which measures the cost of opening and closing input streams using `ZipFile::getInputStream` shows a modest improvement of ~5%, consistent with less allocation of unused buffer space.

Testing: No tests are added in this PR. The `noreg-cleanup` label is added in JBS. GHA testing is currently pending.

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

Commit messages:
 - Use compressed size instead of uncompressed size when determining the ZipFileInflaterInputStream input buffer size

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

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

From alanb at openjdk.org  Sun Oct  6 18:22:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 6 Oct 2024 18:22:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
Message-ID: <znZFF_2o9nmCUx_20Rf4RVVjAfCvEfaT-PvNvaso16k=.af8a0bab-4cc3-4bb7-8dfa-0a39654c2b63@github.com>

On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Dropping non-public JavaDocs

src/java.base/share/classes/java/io/Reader.java line 144:

> 142: 
> 143:     /**
> 144:      * Returns a new {@code Reader} whose source is a {@link CharSequence}.

Probably better to more this more precise, e.g.  Returns a {@code Reader} that reads characters from a {@code CharSequence}, starting at the first character in the sequence.

src/java.base/share/classes/java/io/Reader.java line 154:

> 152:      * have no effect.
> 153:      *
> 154:      * <p> After the reader has been closed, the {@code read()},

This paragraph is okay but the Reader methods shouldn't specify this (doing so after 25+ years of being unspecified would require being confident wouldn't invalidate any existing Readers).

src/java.base/share/classes/java/io/Reader.java line 159:

> 157:      * {@code transferTo()} methods all throw {@code IOException}.
> 158:      *
> 159:      * <p> The {@code markSupported()} method returns {@code true}.

Chen's suggestion to say that it supports the mark operation would be clearer than the legacy wording.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789193444
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789194414
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789195170

From duke at openjdk.org  Sun Oct  6 18:22:37 2024
From: duke at openjdk.org (Bernd)
Date: Sun, 6 Oct 2024 18:22:37 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
Message-ID: <NyQQAAxBxGzcpLntNNpLv8jtdlmcs_TaGfldR8g2MHA=.d5797df4-4d0a-490f-9123-13a0e764e3a5@github.com>

On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Dropping non-public JavaDocs

test/jdk/java/io/Reader/Of.java line 145:

> 143:         assertEquals(reader.transferTo(sw), 16, "transferTo() != 16");
> 144:         assertEquals(reader.transferTo(sw), 0,
> 145:                 "transferTo() does not resect empty stream");

Typo respect (I also wonder if ?empty stream? (used multiple times) should be ?end of stream? or ?exhausted stream?. The test never get an empty stream to test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789195757

From duke at openjdk.org  Sun Oct  6 18:27:35 2024
From: duke at openjdk.org (Bernd)
Date: Sun, 6 Oct 2024 18:27:35 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <sPBzh8qERLoHb-zhlcwqmTxQJHRgF-CIXMGqJnGMBGg=.75ccbf48-f7ad-4f35-b67f-8b31fe224d60@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <sPBzh8qERLoHb-zhlcwqmTxQJHRgF-CIXMGqJnGMBGg=.75ccbf48-f7ad-4f35-b67f-8b31fe224d60@github.com>
Message-ID: <Z6ZHUcp2HYmXS4LHrEQRS7lFGsbo4Lg_vPhi4iXulqs=.e594f802-f9bf-4a36-aed1-65abe08f7bf6@github.com>

On Sun, 6 Oct 2024 18:05:28 GMT, Bernd <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! Reader.of(String)
>>   
>>   Dropping non-public JavaDocs
>
> src/java.base/share/classes/java/io/Reader.java line 231:
> 
>> 229:             public boolean ready() throws IOException {
>> 230:                 ensureOpen();
>> 231:                 return true;
> 
> I guess it?s not wrong, but can this be false when end of source is reached? Related to this you already described it is not synchronized but should we also describe it does not support changes to the length during ?iteration? (could be in the same thread).

Ignore my ?thinko?/comment. of course it needs to return true for the EOD.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789197653

From eirbjo at openjdk.org  Sun Oct  6 19:19:36 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 6 Oct 2024 19:19:36 GMT
Subject: RFR: 8341597: ZipFileInflaterInputStream input buffer size uses
 uncompressed size
In-Reply-To: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>
References: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>
Message-ID: <tx97I6WJ5GzGy45wd839HPHoLYXbdydJ1wfZ6cy64V0=.8a03b938-1465-4a39-96d4-707c5ffa4739@github.com>

On Sun, 6 Oct 2024 18:02:58 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which proposes to change the input buffer size of `ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP entry instead of the _uncompressed_ size. This saves allocation since buffers will no longer be oversized:
> 
> * The `size` parameter passed to the `ZipFileInflaterInputStream` constructor is passed on to the superclass `InflaterInputStream` where it determines the size of the input buffer. This buffer is used to read compressed data and pass it on to the `Inflater`.
> * `ZipFile:getInputStream` currently looks at the _uncompressed_ size when determining the input buffer size. It should instead use the _compressed_ size, since this buffer is used for compressed, not uncompressed data.
> * The current implementation somewhat mysteriously adds 2 to the uncompressed size. My guess is that this is to allow fitting a two-byte DEFLATE header for empty files (where the uncompressed size is 0 and the compressed size is 2).
> * There is a check for `size <= 0`. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be `>= 2`. I propose we remove this check.
> 
> Performance: A benchmark which measures the cost of opening and closing input streams using `ZipFile::getInputStream` shows a modest improvement of ~5%, consistent with less allocation of unused buffer space.
> 
> Testing: No tests are added in this PR. The `noreg-cleanup` label is added in JBS. GHA testing is currently pending.

src/java.base/share/classes/java/util/zip/ZipFile.java line 417:

> 415:                     if (size > 65536) {
> 416:                         size = 8192;
> 417:                     }

Not sure if this clamping makes sense? We clamp the size at 8192, but only when size is larger than 65536?

Wondering if we should simply clamp to 8192 instead:


Suggestion:

                   int size = Math.clamp(CENSIZ(zsrc.cen, pos), 2, 8192);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21379#discussion_r1789215300

From redestad at openjdk.org  Sun Oct  6 19:24:48 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 19:24:48 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v3]
In-Reply-To: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
Message-ID: <QLk5av6_aadCmSQmChS6N3mmvmKuOOXylFmFa1pKBI4=.4bc24cc6-696c-4753-9787-fd457e67a664@github.com>

> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
> 
> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
> 
> 
> make test TEST=micro:java.util.zip.ZipFile
> 
> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>   * = significant
> 
> 
> This PR also address some code duplication in `ZipUtils`.
> 
> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zipfs has some duplicate code that is left untouched) ...

Claes Redestad 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/21377/files
  - new: https://git.openjdk.org/jdk/pull/21377/files/d904ce64..23f0c8e1

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

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

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

From redestad at openjdk.org  Sun Oct  6 19:24:49 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 19:24:49 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <k-S9nKpxa3RLlPhQjPz34FlJ7j_5KrcvGT-FupyzAjk=.371705c2-c60a-4414-8323-20c95fea67d3@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
 <k-S9nKpxa3RLlPhQjPz34FlJ7j_5KrcvGT-FupyzAjk=.371705c2-c60a-4414-8323-20c95fea67d3@github.com>
Message-ID: <G9j5IUeHQcGbN-nEwD3102afQS8K-Kp12Ma0heZba-A=.e16fac17-4f83-41b8-9cd8-d411025dc9dd@github.com>

On Sun, 6 Oct 2024 15:53:55 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 195:
> 
>> 193:      * The bytes are assumed to be in Intel (little-endian) byte order.
>> 194:      */
>> 195:     public static final long get64(byte[] b, int off) {
> 
> This method returns a signed 64 bit value, which I think is not what some of its call sites expect. It should in any case be renamed to `get64S` to align with `get32S`. A new method `get64` should be introduced and any call site expecting unsigned numbers (most?) should use that instead.
> 
> If you don't want to deal with this in this PR, I could file an issue and suggest a PR for this. Let me know.

As it's a pre-existing issue I'd prefer to keep this one focused on the switch-over. How would you model unsigned long values here, though? Sure we could read into a `BigInteger` or accept negative values, but to really support such overflows we might have to rework a lot of things. 

FWIW we already cap some values even lower in practice:

                            end.centot = (int)centot64; // assume total < 2g

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789215898

From redestad at openjdk.org  Sun Oct  6 19:24:49 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 19:24:49 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v3]
In-Reply-To: <E4lC3nc1G7SgxaD9lz11Ih0_DEa-g4ziKeFhEk4BMHE=.19fe674f-4689-4862-b6ac-aac6d18794a4@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
 <TzPmh6u1ToUS8Mg1JAYQ0k3nTAde4hFLzR-iqVkckPs=.7608afd5-4b23-4d9e-aaed-ab7be47a8f4d@github.com>
 <E4lC3nc1G7SgxaD9lz11Ih0_DEa-g4ziKeFhEk4BMHE=.19fe674f-4689-4862-b6ac-aac6d18794a4@github.com>
Message-ID: <l9SW_-4fXIugWMEuncWS21lOUFyxSjaflOuFnTFya4Y=.76fe74e7-88ae-41e9-a232-547da920e9fe@github.com>

On Sun, 6 Oct 2024 16:27:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 110:
>> 
>>> 108:         zf2.close();
>>> 109:     }
>>> 110: 
>> 
>> A short comment stating the purpose of the main method would not hurt.
>
> https://github.com/openjdk/jdk/pull/19477#discussion_r1725802115
> 
> This applies to many benchmarks, so I wonder where is the best place for such a note.

I think it's fair to add a descriptive comment individually.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789216833

From redestad at openjdk.org  Sun Oct  6 19:27:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 19:27:33 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v3]
In-Reply-To: <6fCaBlFrmbxZA7NIKBH_pzu20k7o4GAVk_r855LAqxA=.eb70357f-2fa8-4b92-8742-24dcc51f46ae@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <9beFzspMmChICPbJNINP-P19GuA5aEkGGOq65QiZwRw=.4982e4c8-d792-40ed-a341-0a6856cff62b@github.com>
 <S1kBX1Ty4Rg_PuymhT5zfzET0lzOgTsK2bSjdYon2ag=.f501e20e-4bff-4829-8de5-74c263108943@github.com>
 <hcwc_Hw0KvbTTjmgUgfx5p8x6OE7UFH7OT2UYj27fM8=.e21b6aaf-971c-4312-82a3-fab346ba4d88@github.com>
 <_zx1n73JdcyWUrcJb3ONkBZ_ZWyDSLIhcOJhBBk1BRI=.90fb6d29-40db-4d54-8088-23e573832297@github.com>
 <6fCaBlFrmbxZA7NIKBH_pzu20k7o4GAVk_r855LAqxA=.eb70357f-2fa8-4b92-8742-24dcc51f46ae@github.com>
Message-ID: <bx8jKlZ3qKAyd0KqOiea5MoJhgbItkT7F7fNFrB1IJ8=.ee6f7efd-782e-411f-b070-8f2d271c5cd8@github.com>

On Sun, 6 Oct 2024 15:48:57 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Sure, I think the JIT is pretty good at eliminating the (intrinsic) `checkIndex` calls when they are redundant though. Performance with and without these `checkIndex`es are the same in my testing, so we can eat and have the cake on this one.
>> 
>> FWIW I wouldn't mind giving similar treatment to `ByteArray(-LittleEndian)` and avoid the `VarHandles` dependency in those utility classes, but I have no urge to get into the sort of discussions that were spawned in #19616
>
>> Actually if we trust the input index to be nonnegative, we can just check our end index for out of bounds too.
> 
> I would not trust that. Perhaps for well-formed ZIP files, but trust me, not all ZIPs are well-formed ;-)

Like @eirbjo suggests we'd have to put a lot of validation in other places if we went down this route. Regardless this is an academic discussion since the PR suggests the safe route and we don't pay much of a cost for that in microbenchmarks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789217693

From duke at openjdk.org  Sun Oct  6 19:27:37 2024
From: duke at openjdk.org (Brett Okken)
Date: Sun, 6 Oct 2024 19:27:37 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
Message-ID: <rmnOeQu8FeDwMXMOXz0U-KEVH9Tv9x_KRsenJDs6NEI=.183ecf47-c216-4ffe-b90d-6a02493a2623@github.com>

On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Dropping non-public JavaDocs

src/java.base/share/classes/java/io/Reader.java line 203:

> 201:                 int n = Math.min(length - next, len);
> 202:                 switch (cs) {
> 203:                     case String s -> s.getChars(next, next + n, cbuf, off);

There was some discussion on the mailing list of introducing a method to CharSequence for bulk getChars. Doing that would help both here and in Appendable/Writer implementations like StringWriter, PrintWriter, and OutputStreamWriter which currently convert to a String to then write.

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/Writer.java#L367

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/OutputStreamWriter.java#L253

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789217494

From eirbjo at openjdk.org  Sun Oct  6 19:36:34 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 6 Oct 2024 19:36:34 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <G9j5IUeHQcGbN-nEwD3102afQS8K-Kp12Ma0heZba-A=.e16fac17-4f83-41b8-9cd8-d411025dc9dd@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
 <k-S9nKpxa3RLlPhQjPz34FlJ7j_5KrcvGT-FupyzAjk=.371705c2-c60a-4414-8323-20c95fea67d3@github.com>
 <G9j5IUeHQcGbN-nEwD3102afQS8K-Kp12Ma0heZba-A=.e16fac17-4f83-41b8-9cd8-d411025dc9dd@github.com>
Message-ID: <wRsRHkY-RoqP9zhrbTNLRFhzvEGwn7npG8-jaLbD268=.63553593-380f-4b28-9ddb-326d14f0e424@github.com>

On Sun, 6 Oct 2024 19:19:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> How would you model unsigned long values here, though?

I don't think we should. `9223372036854775807 ` should be enough for everyone :-)

It may be worth renaming the method to `get64S` and add a `get64` variant which either clamps at `LONG.MAX_VALUE` or throws `IllegalArgumentException` for larger values. Call sites doing custom validation (like `checkZip64ExtraFieldValues`) could then call `get64S` and check for a negative long.

But that's food for another PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789220684

From redestad at openjdk.org  Sun Oct  6 21:45:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 21:45:08 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v4]
In-Reply-To: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
Message-ID: <X04m7EGiB5FqVOgVKofwuDFRFL7stUBdGC4Ism8blpg=.9e151c1b-f77f-429a-81ae-4fe210db9539@github.com>

> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
> 
> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
> 
> 
> make test TEST=micro:java.util.zip.ZipFile
> 
> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>   * = significant
> 
> 
> This PR also address some code duplication in `ZipUtils`.
> 
> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zipfs has some duplicate code that is left untouched) ...

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Rename get64 -> get64S

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21377/files
  - new: https://git.openjdk.org/jdk/pull/21377/files/23f0c8e1..360afeaa

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

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

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

From redestad at openjdk.org  Sun Oct  6 21:51:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 6 Oct 2024 21:51:34 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <wRsRHkY-RoqP9zhrbTNLRFhzvEGwn7npG8-jaLbD268=.63553593-380f-4b28-9ddb-326d14f0e424@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
 <k-S9nKpxa3RLlPhQjPz34FlJ7j_5KrcvGT-FupyzAjk=.371705c2-c60a-4414-8323-20c95fea67d3@github.com>
 <G9j5IUeHQcGbN-nEwD3102afQS8K-Kp12Ma0heZba-A=.e16fac17-4f83-41b8-9cd8-d411025dc9dd@github.com>
 <wRsRHkY-RoqP9zhrbTNLRFhzvEGwn7npG8-jaLbD268=.63553593-380f-4b28-9ddb-326d14f0e424@github.com>
Message-ID: <HgTsAnCSEJ_h2u1ml2PqGE23K7iqd0mrs5WwrWRSV4M=.6ee34c6f-a4cd-411d-89bb-019e1bfd35d2@github.com>

On Sun, 6 Oct 2024 19:33:49 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> As it's a pre-existing issue I'd prefer to keep this one focused on the switch-over. How would you model unsigned long values here, though? Sure we could read into a `BigInteger` or accept negative values, but to really support such overflows we might have to rework a lot of things. 
>> 
>> FWIW we already cap some values even lower in practice:
>> 
>>                             end.centot = (int)centot64; // assume total < 2g
>
>> How would you model unsigned long values here, though?
> 
> I don't think we should. `9223372036854775807 ` should be enough for everyone :-)
> 
> It may be worth renaming the method to `get64S` and add a `get64` variant which either clamps at `LONG.MAX_VALUE` or throws `IllegalArgumentException` for larger values. Call sites doing custom validation (like `checkZip64ExtraFieldValues`) could then call `get64S` and check for a negative long.
> 
> But that's food for another PR.

Renaming to `get64S` is reasonable to be internally consistent. Updated. Improving validation of data in such 64-bit fields I'll leave for the future. I think a reasonable stance is to throw in the `check` methods if any such field is negative, at least for some of these fields.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789266234

From darcy at openjdk.org  Sun Oct  6 22:42:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 6 Oct 2024 22:42:37 GMT
Subject: RFR: 8336043: Add quality of implementation discussion to
 Object.{equals, toString, hashCode} [v5]
In-Reply-To: <T74gyqtJGSAYb6eTF--Y0DdYH0ttSf_dT8ARVDizPi8=.d71f44d5-61c6-417f-be4d-4c699895f9ee@github.com>
References: <hpG3kh3HNwzo1X2DFDlPTh9OgBWkPqA_puJtYNhCV14=.16432251-e2bd-405a-aab3-f56a2c752ddb@github.com>
 <T74gyqtJGSAYb6eTF--Y0DdYH0ttSf_dT8ARVDizPi8=.d71f44d5-61c6-417f-be4d-4c699895f9ee@github.com>
Message-ID: <B6v8kYUiXqQzwhH37XjcMyZ_iO51fzQ8dsSU52rM-Ns=.e40cf234-6b7e-4f6e-a927-85079ab6c0ba@github.com>

On Wed, 7 Aug 2024 00:02:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> First pass at adding some quality of implementation discussions around the overridable methods of Object.
>
> 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}

Keep alive again.

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

PR Comment: https://git.openjdk.org/jdk/pull/20128#issuecomment-2395612222

From duke at openjdk.org  Mon Oct  7 00:07:36 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 7 Oct 2024 00:07:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
Message-ID: <YxZliiXoiN-Np51CvhnYFlqNwC-REI00Xvn0DXp6q6E=.f77b984b-8584-44a0-aab9-b30e1c91c7f2@github.com>

On Sun, 6 Oct 2024 17:44:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixup! Reader.of(String)
>   
>   Dropping non-public JavaDocs

src/java.base/share/classes/java/io/Reader.java line 172:

> 170:         Objects.requireNonNull(source);
> 171: 
> 172:         return new Reader() {

Maybe?make?this into?a?package?private `CharSequenceReader` so?that?[`StringReader?::close()`] doesn?t?have to?use a?try?catch.

[`StringReader?::close()`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/StringReader.html#close()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789311976

From swen at openjdk.org  Mon Oct  7 01:02:45 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 7 Oct 2024 01:02:45 GMT
Subject: RFR: 8339704: Refactor StringConcatHelper simpleConcat [v7]
In-Reply-To: <hCfPK6RKmGfpFgGwHjbQVBRKYGJ4M-pI97RvEFWXudU=.60bb1de8-e3d3-4808-ac0b-45552b184ce2@github.com>
References: <KcnUYgdAccUQ5PjcVtvLxcQG7QhneETmOdYhUToOvkQ=.81e88a96-871d-4e9e-b150-4eac29d93781@github.com>
 <hCfPK6RKmGfpFgGwHjbQVBRKYGJ4M-pI97RvEFWXudU=.60bb1de8-e3d3-4808-ac0b-45552b184ce2@github.com>
Message-ID: <-HOF6qLofGlDoJ6eDUlAx9Zt74P3oOJks3sJmp0jfY0=.e69500e5-3768-4dad-9f8c-0f362d0a6ad8@github.com>

On Tue, 10 Sep 2024 13:13:22 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The string concatenation of the java.base module is implemented using StringBuilder. By providing a series of concat methods in StringConcatHelper, it is used in the java.lang package to replace string concatenation.
>> 
>> These concat methods can also be exposed through JLA for use by other packages, such as java.lang.constant.
>> 
>> These concat methods can replace Concat1 and become part of StringConcatFactory#simpleConcat
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove 2 arguments simple concat

Similar to InnerClassLambdaMetafactory line 181

argNames[i] = "arg$" + (i + 1);

we need to provide concat(String, int) directly inside java.base, which is why I submitted this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20726#issuecomment-2395699499

From swen at openjdk.org  Mon Oct  7 01:25:31 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 7 Oct 2024 01:25:31 GMT
Subject: RFR: 8341548: More concise use of classfile API [v3]
In-Reply-To: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
References: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
Message-ID: <mXyMN_E7IPa7o0qpEItTWpXZAODEJ7qI5s0YamLud5c=.84264695-3119-475b-8c19-5b6309db6730@github.com>

> java.base should provide best practices for Class File API
> 
> 1. Use fluent coding style
> 2. Use aconst_null instead of oadConstant(null)
> 3. use astore intead of 'storeLocal(REFERENCE'
> 4. use aload instead of 'loadLocal(REFERENCE'
> 5. 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(LONG)'

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  more fluent coding style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21355/files
  - new: https://git.openjdk.org/jdk/pull/21355/files/4d895f45..18ef939c

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

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

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

From duke at openjdk.org  Mon Oct  7 01:56:40 2024
From: duke at openjdk.org (David Schlosnagle)
Date: Mon, 7 Oct 2024 01:56:40 GMT
Subject: RFR: 8341597: ZipFileInflaterInputStream input buffer size uses
 uncompressed size
In-Reply-To: <tx97I6WJ5GzGy45wd839HPHoLYXbdydJ1wfZ6cy64V0=.8a03b938-1465-4a39-96d4-707c5ffa4739@github.com>
References: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>
 <tx97I6WJ5GzGy45wd839HPHoLYXbdydJ1wfZ6cy64V0=.8a03b938-1465-4a39-96d4-707c5ffa4739@github.com>
Message-ID: <hrsB6qUCsbNRnQBZWPUw5W31eIx9k6wYlY08_UOYEFI=.11e86f7f-d4d6-414d-84e9-dc3a69b4aeea@github.com>

On Sun, 6 Oct 2024 19:17:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which proposes to change the input buffer size of `ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP entry instead of the _uncompressed_ size. This saves allocation since buffers will no longer be oversized:
>> 
>> * The `size` parameter passed to the `ZipFileInflaterInputStream` constructor is passed on to the superclass `InflaterInputStream` where it determines the size of the input buffer. This buffer is used to read compressed data and pass it on to the `Inflater`.
>> * `ZipFile:getInputStream` currently looks at the _uncompressed_ size when determining the input buffer size. It should instead use the _compressed_ size, since this buffer is used for compressed, not uncompressed data.
>> * The current implementation somewhat mysteriously adds 2 to the uncompressed size. My guess is that this is to allow fitting a two-byte DEFLATE header for empty files (where the uncompressed size is 0 and the compressed size is 2).
>> * There is a check for `size <= 0`. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be `>= 2`. I propose we remove this check.
>> 
>> Performance: A benchmark which measures the cost of opening and closing input streams using `ZipFile::getInputStream` shows a modest improvement of ~5%, consistent with less allocation of unused buffer space.
>> 
>> Testing: No tests are added in this PR. The `noreg-cleanup` label is added in JBS. GHA testing is currently pending.
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 417:
> 
>> 415:                     if (size > 65536) {
>> 416:                         size = 8192;
>> 417:                     }
> 
> Not sure if this clamping makes sense? We clamp the size at 8192, but only when size is larger than 65536?
> 
> Wondering if we should simply clamp to 8192 instead:
> 
> 
> Suggestion:
> 
>                    int size = Math.clamp(CENSIZ(zsrc.cen, pos), 2, 8192);

I'm curious if it would be beneficial to increase the max clamp size to 16384 bytes similar to https://bugs.openjdk.org/browse/JDK-8299336 / https://github.com/openjdk/jdk/pull/11783

Suggestion:

                    int size = Math.clamp(CENSIZ(zsrc.can, pos), 2, 16384);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21379#discussion_r1789364170

From jpai at openjdk.org  Mon Oct  7 04:34:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 04:34:14 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool
Message-ID: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>

Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?

The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:


$> jrunscript
script engine for language js can not be found


The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.

No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.

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

Commit messages:
 - 8341134: Deprecate for removal the jrunscript tool

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

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

From jpai at openjdk.org  Mon Oct  7 04:34:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 04:34:14 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool
In-Reply-To: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
Message-ID: <mRN_L6ZP4AmYXAXgv1482dWNYzIS507EXQl7Fo1aBZ8=.f7c75ea2-e806-4e6e-af0c-88aed2bdcfa7@github.com>

On Mon, 7 Oct 2024 04:23:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
> 
> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
> 
> 
> $> jrunscript
> script engine for language js can not be found
> 
> 
> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.

The `module-info` of `java.scripting` currently notes this:


 * <p> The JDK implementation of this module includes a language-independent
 * command-line script shell, <em>{@index jrunscript jrunscript tool}</em>,
 * that supports executing JavaScript and other languages if its corresponding
 * script engine is installed.
 *
 * @toolGuide jrunscript


As part of this current PR, should we be doing any changes to that documentation, noting the deprecation of that tool?

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

PR Comment: https://git.openjdk.org/jdk/pull/21380#issuecomment-2395865782

From liach at openjdk.org  Mon Oct  7 04:38:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 04:38:45 GMT
Subject: RFR: 8336043: Add quality of implementation discussion to
 Object.{equals, toString, hashCode} [v5]
In-Reply-To: <T74gyqtJGSAYb6eTF--Y0DdYH0ttSf_dT8ARVDizPi8=.d71f44d5-61c6-417f-be4d-4c699895f9ee@github.com>
References: <hpG3kh3HNwzo1X2DFDlPTh9OgBWkPqA_puJtYNhCV14=.16432251-e2bd-405a-aab3-f56a2c752ddb@github.com>
 <T74gyqtJGSAYb6eTF--Y0DdYH0ttSf_dT8ARVDizPi8=.d71f44d5-61c6-417f-be4d-4c699895f9ee@github.com>
Message-ID: <FlwWE7-b7CjTwMIOp9HsZMorcXwYb-5ZJaVmGcg8vko=.39984b8f-2157-4c76-94b2-4716f83c985f@github.com>

On Wed, 7 Aug 2024 00:02:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> First pass at adding some quality of implementation discussions around the overridable methods of Object.
>
> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1787103424

From liach at openjdk.org  Mon Oct  7 04:47:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 04:47:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <YxZliiXoiN-Np51CvhnYFlqNwC-REI00Xvn0DXp6q6E=.f77b984b-8584-44a0-aab9-b30e1c91c7f2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <YxZliiXoiN-Np51CvhnYFlqNwC-REI00Xvn0DXp6q6E=.f77b984b-8584-44a0-aab9-b30e1c91c7f2@github.com>
Message-ID: <Pgq6Ik_lhiHvnf9p00w6qHkeLoJqe8yAgCcnFBmf5hQ=.5cb5ff41-8560-4b76-b73c-5dfecd950fe1@github.com>

On Mon, 7 Oct 2024 00:04:40 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! Reader.of(String)
>>   
>>   Dropping non-public JavaDocs
>
> src/java.base/share/classes/java/io/Reader.java line 172:
> 
>> 170:         Objects.requireNonNull(source);
>> 171: 
>> 172:         return new Reader() {
> 
> Maybe?make?this into?a?package?private `CharSequenceReader` so?that?[`StringReader?::close()`] doesn?t?have to?use a?try?catch.
> 
> [`StringReader?::close()`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/StringReader.html#close()

I don't think that try-catch is too much of a bloat compared to the extra license header and imports from the explicit `CharSequenceReader.java` file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789479742

From liach at openjdk.org  Mon Oct  7 04:47:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 04:47:37 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <rmnOeQu8FeDwMXMOXz0U-KEVH9Tv9x_KRsenJDs6NEI=.183ecf47-c216-4ffe-b90d-6a02493a2623@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <rmnOeQu8FeDwMXMOXz0U-KEVH9Tv9x_KRsenJDs6NEI=.183ecf47-c216-4ffe-b90d-6a02493a2623@github.com>
Message-ID: <aS1igbav6qq6txb2AwzrbtnzZ-kYcW5vqj8gQXoLp_4=.f4cd2d6c-ac80-49aa-9f18-d5f6e0e03683@github.com>

On Sun, 6 Oct 2024 19:24:07 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! Reader.of(String)
>>   
>>   Dropping non-public JavaDocs
>
> src/java.base/share/classes/java/io/Reader.java line 203:
> 
>> 201:                 int n = Math.min(length - next, len);
>> 202:                 switch (cs) {
>> 203:                     case String s -> s.getChars(next, next + n, cbuf, off);
> 
> There was some discussion on the mailing list of introducing a method to CharSequence for bulk getChars. Doing that would help both here and in Appendable/Writer implementations like StringWriter, PrintWriter, and OutputStreamWriter which currently convert to a String to then write.
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/Writer.java#L367
> 
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/OutputStreamWriter.java#L253

I believe this batch operation would be a useful addition, but it is best reserved for another RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789479245

From sundar at openjdk.org  Mon Oct  7 04:53:33 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Mon, 7 Oct 2024 04:53:33 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool
In-Reply-To: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
Message-ID: <SdVmdis_QTLNYX5nGBe14ZEuUAPlzSIgg9pL0iREF8M=.3d40d8f2-0728-4933-b761-fd06ecd42eaf@github.com>

On Mon, 7 Oct 2024 04:23:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
> 
> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
> 
> 
> $> jrunscript
> script engine for language js can not be found
> 
> 
> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.

Marked as reviewed by sundar (Reviewer).

That documentation comment in module-info.java of java.scripting has to be updated for deprecation info of the tool (as you noted)

Other changes look good to me

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

PR Review: https://git.openjdk.org/jdk/pull/21380#pullrequestreview-2350841733
PR Comment: https://git.openjdk.org/jdk/pull/21380#issuecomment-2395891269

From jpai at openjdk.org  Mon Oct  7 05:06:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 05:06:23 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v12]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <KwAOxEn-drtOn2AXIrNyqSptpJBD7gseQjYWX4zSeMA=.fd36cd19-02c4-403f-9b94-1a4ea7c5a5dc@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Christian's suggestion - keep OTHER as the last enum value
 - 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
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - ... and 13 more: https://git.openjdk.org/jdk/compare/20f36c66...73f6d6e7

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

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=11
  Stats: 567 lines in 4 files changed: 558 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

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

From jpai at openjdk.org  Mon Oct  7 05:06:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 05:06:23 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v10]
In-Reply-To: <sc-iMOjzfOGiJEBtQYG2FOTR17IPNwA55xb_drW3dKM=.f36dc70e-9506-4cb8-b048-2981ef64fe60@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <m5NHM0OoJh8YRm0alAkkz3Ey9fXTzf5fKcuCRBiaEG0=.799b4e44-7e39-49f9-b788-24d51a71eae0@github.com>
 <sc-iMOjzfOGiJEBtQYG2FOTR17IPNwA55xb_drW3dKM=.f36dc70e-9506-4cb8-b048-2981ef64fe60@github.com>
Message-ID: <6n34SVdshg9MTQDQSbG6qGAN2QICPNFNCig2M7sffN8=.2e006bba-265e-4e5b-95c9-55164e544d89@github.com>

On Tue, 10 Sep 2024 05:36:17 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Jaikiran Pai 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 latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - cleanup testExtractNoDestDirWithPFlag() test
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - convert the new test to junit
>>  - merge latest from master branch
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/56387a09...129375da
>
> src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 268:
> 
>> 266:         CREATE_UPDATE_INDEX("create.update.index"),
>> 267:         OTHER("other"),
>> 268:         EXTRACT("extract");
> 
> Is the order number important in this non-public `enum`? If not, I would expect `OTHER` to remain the last/highest entry.

Hello Christian, I've now updated the PR to keep `OTHER` as the last enum value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/2752#discussion_r1789496446

From thartmann at openjdk.org  Mon Oct  7 05:52:41 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Oct 2024 05:52:41 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v6]
In-Reply-To: <MsPOYHq_-sRol1vs_8uBPp2b2DuCSHQRLzTPWH8V1mg=.bfbce9b8-c16c-46bc-90af-d9185255409e@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <fw611czOe2hKmptYjgX9T4dZgMexkl4ZljDs0XjYNiA=.7b2575ad-fcd0-45f3-b44e-871bb1ce2aa9@github.com>
 <V1ChvAolG5oJx4Y9AGbLAwmsYxcg2gmvMDGy6J2BHMU=.8a15d731-ba69-4cfa-9471-6b064feab70f@github.com>
 <MsPOYHq_-sRol1vs_8uBPp2b2DuCSHQRLzTPWH8V1mg=.bfbce9b8-c16c-46bc-90af-d9185255409e@github.com>
Message-ID: <xSCUM-L7cSdzEVpm1hfdTs03wHLUX_dIgPHUkwI-23A=.895766f0-4e78-4a2f-855c-13d0cde4e279@github.com>

On Thu, 3 Oct 2024 16:54:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java line 2:
>> 
>>> 1: //
>>> 2: // * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>> 
>> Drive-by comment: The `// *` format looks weird.
>
> Actually, this constellation of single-line comments should be replaced with a multi-line comment block. The fix is now in my (unpublished) patch queue, thanks.

Yes, that's what I meant. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1789539477

From jpai at openjdk.org  Mon Oct  7 05:58:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 05:58:53 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v13]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - use a fixed locale in the test to prevent failures on environments that are not en_US
 - add a test to verify extraction to a non-directory fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/2752/files
  - new: https://git.openjdk.org/jdk/pull/2752/files/73f6d6e7..0b8d5aaa

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

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

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

From jpai at openjdk.org  Mon Oct  7 06:26:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 06:26:09 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v2]
In-Reply-To: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
Message-ID: <qfClHGsf9zLV2jzgy7UCPGLj1nb13qE1esmfqjsV-II=.4cbf9f4b-7e8e-46bf-8f54-52ab8e710f77@github.com>

> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
> 
> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
> 
> 
> $> jrunscript
> script engine for language js can not be found
> 
> 
> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.

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

  update module-info of java.scripting to note about jrunscript tool deprecation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21380/files
  - new: https://git.openjdk.org/jdk/pull/21380/files/65c2ec8f..f68997e7

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

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

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

From jpai at openjdk.org  Mon Oct  7 06:26:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 06:26:09 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool
In-Reply-To: <SdVmdis_QTLNYX5nGBe14ZEuUAPlzSIgg9pL0iREF8M=.3d40d8f2-0728-4933-b761-fd06ecd42eaf@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <SdVmdis_QTLNYX5nGBe14ZEuUAPlzSIgg9pL0iREF8M=.3d40d8f2-0728-4933-b761-fd06ecd42eaf@github.com>
Message-ID: <o4f17N568HvXK-9XA5qOq7pXbMNre19vC6B8l14d7Vo=.258d487a-ce86-4d33-b64f-a2616ed3be26@github.com>

On Mon, 7 Oct 2024 04:49:45 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> That documentation comment in module-info.java of java.scripting has to be updated for deprecation info of the tool (as you noted)

I've now updated the PR to make a mention of the `jrunscript` tool being deprecated, in the module-info of `java.scripting` module.

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

PR Comment: https://git.openjdk.org/jdk/pull/21380#issuecomment-2396004272

From alanb at openjdk.org  Mon Oct  7 06:48:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Oct 2024 06:48:35 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v2]
In-Reply-To: <qfClHGsf9zLV2jzgy7UCPGLj1nb13qE1esmfqjsV-II=.4cbf9f4b-7e8e-46bf-8f54-52ab8e710f77@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <qfClHGsf9zLV2jzgy7UCPGLj1nb13qE1esmfqjsV-II=.4cbf9f4b-7e8e-46bf-8f54-52ab8e710f77@github.com>
Message-ID: <QUfZhR6gh0ZGMOsqY_dwbAr0YNy_i4HF82kq528KERg=.201aa603-8b0e-4c39-8273-bc8e4048ad27@github.com>

On Mon, 7 Oct 2024 06:26:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update module-info of java.scripting to note about jrunscript tool deprecation

src/java.scripting/share/classes/module-info.java line 31:

> 29:  * <p> The <em>{@index jrunscript jrunscript tool}</em> included in the JDK
> 30:  * implementation of this module, has been deprecated for removal since
> 31:  * JDK 24 and will be removed in a future release.

"included" is past sentence. I think it would be better to keep the original text and just add new a sentence to say that the tool has been deprecated for removal in a future release.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21380#discussion_r1789596630

From jpai at openjdk.org  Mon Oct  7 07:03:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 07:03:13 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v2]
In-Reply-To: <QUfZhR6gh0ZGMOsqY_dwbAr0YNy_i4HF82kq528KERg=.201aa603-8b0e-4c39-8273-bc8e4048ad27@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <qfClHGsf9zLV2jzgy7UCPGLj1nb13qE1esmfqjsV-II=.4cbf9f4b-7e8e-46bf-8f54-52ab8e710f77@github.com>
 <QUfZhR6gh0ZGMOsqY_dwbAr0YNy_i4HF82kq528KERg=.201aa603-8b0e-4c39-8273-bc8e4048ad27@github.com>
Message-ID: <-hLxcEAYfxNaYaT0txqBg3389xx-aMdTV9wWI61G7b8=.b26e4acb-e273-4291-a018-005076f174be@github.com>

On Mon, 7 Oct 2024 06:46:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update module-info of java.scripting to note about jrunscript tool deprecation
>
> src/java.scripting/share/classes/module-info.java line 31:
> 
>> 29:  * <p> The <em>{@index jrunscript jrunscript tool}</em> included in the JDK
>> 30:  * implementation of this module, has been deprecated for removal since
>> 31:  * JDK 24 and will be removed in a future release.
> 
> I think it would be better to keep the original text and just add new a sentence to say that the tool has been deprecated for removal in a future release.

Done, I've now updated the PR to retain the old text, plus add a new line noting about the deprecation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21380#discussion_r1789627816

From jpai at openjdk.org  Mon Oct  7 07:03:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 07:03:13 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v3]
In-Reply-To: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
Message-ID: <2xTd_J60NVwLjWFUeWL4AIrVSst8J04M2ObOHIvWd68=.feae34e2-67f2-4087-bbe3-3f11251c3795@github.com>

> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
> 
> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
> 
> 
> $> jrunscript
> script engine for language js can not be found
> 
> 
> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.

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

  Alan's suggestion - retain old text plus add a new deprecation note

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21380/files
  - new: https://git.openjdk.org/jdk/pull/21380/files/f68997e7..5f2c4a5f

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

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

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

From jpai at openjdk.org  Mon Oct  7 07:03:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Oct 2024 07:03:13 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v2]
In-Reply-To: <qfClHGsf9zLV2jzgy7UCPGLj1nb13qE1esmfqjsV-II=.4cbf9f4b-7e8e-46bf-8f54-52ab8e710f77@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <qfClHGsf9zLV2jzgy7UCPGLj1nb13qE1esmfqjsV-II=.4cbf9f4b-7e8e-46bf-8f54-52ab8e710f77@github.com>
Message-ID: <yUWRAHPoKCJPa_j6VnScntWv7MTXGHx25DzyNrb6EoA=.b19c18f3-4f66-4d54-8ef1-4123effa0cdd@github.com>

On Mon, 7 Oct 2024 06:26:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update module-info of java.scripting to note about jrunscript tool deprecation

The CSR is now ready for review at https://bugs.openjdk.org/browse/JDK-8341610

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

PR Comment: https://git.openjdk.org/jdk/pull/21380#issuecomment-2396072687

From shade at openjdk.org  Mon Oct  7 07:12:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Oct 2024 07:12:37 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v8]
In-Reply-To: <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
Message-ID: <U94RybBZYLr6lYZpwpLxegMOjzqHWz9rlhlcJQtcBYQ=.12f49b83-2966-4137-a09d-9e2480877787@github.com>

On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More precise bit-unmasks

Tests pass with the new change. I eyeballed G1 perfasm output on new benchmark, and there are no barriers in sight as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2396092920

From duke at openjdk.org  Mon Oct  7 07:34:11 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 7 Oct 2024 07:34:11 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v26]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <P-7u8snaOpPAJfY-G8QqWCZE7KtcdzAJGurh2KXZxJI=.a1381a61-bfe4-456b-bcf7-b63971a2ec0f@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

 - Correct indentation
 - Refine the estimate of remaining zeros

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/0fd671fa..71a3e6f3

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

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

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

From eirbjo at openjdk.org  Mon Oct  7 07:40:35 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 07:40:35 GMT
Subject: RFR: 8341597: ZipFileInflaterInputStream input buffer size uses
 uncompressed size
In-Reply-To: <hrsB6qUCsbNRnQBZWPUw5W31eIx9k6wYlY08_UOYEFI=.11e86f7f-d4d6-414d-84e9-dc3a69b4aeea@github.com>
References: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>
 <tx97I6WJ5GzGy45wd839HPHoLYXbdydJ1wfZ6cy64V0=.8a03b938-1465-4a39-96d4-707c5ffa4739@github.com>
 <hrsB6qUCsbNRnQBZWPUw5W31eIx9k6wYlY08_UOYEFI=.11e86f7f-d4d6-414d-84e9-dc3a69b4aeea@github.com>
Message-ID: <HWQGcyyN52GDEW_9mlGz4w151qCM_4G4VyfGyeBo268=.ad8c13fd-85a7-4dbd-a912-cc6a609924b6@github.com>

On Mon, 7 Oct 2024 01:52:59 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 417:
>> 
>>> 415:                     if (size > 65536) {
>>> 416:                         size = 8192;
>>> 417:                     }
>> 
>> Not sure if this clamping makes sense? We clamp the size at 8192, but only when size is larger than 65536?
>> 
>> Wondering if we should simply clamp to 8192 instead:
>> 
>> 
>> Suggestion:
>> 
>>                    int size = Math.clamp(CENSIZ(zsrc.cen, pos), 2, 8192);
>
> I'm curious if it would be beneficial to increase the max clamp size to 16384 bytes similar to https://bugs.openjdk.org/browse/JDK-8299336 / https://github.com/openjdk/jdk/pull/11783
> 
> Suggestion:
> 
>                     int size = Math.clamp(CENSIZ(zsrc.can, pos), 2, 16384);

Yes, there may be benefits in increasing this max buffer size for larger entries, but I think that requires a more extensive analysis and discussion than what want to do in this PR.

99 percent of classes in guava.jar have a compressed size less than ~6700 bytes. The average compressed size is ~1300 bytes.

So this does not seem to matter for class loading, which is probably what ZipFile is most optimized for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21379#discussion_r1789692897

From alanb at openjdk.org  Mon Oct  7 07:41:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Oct 2024 07:41:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <5mL72m7q6LN2GB3ut_Ps8bB4FIM6W__2TZEnmgq9oQM=.232c5973-3e30-4161-90e2-7fae8a39cb27@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
 <5mL72m7q6LN2GB3ut_Ps8bB4FIM6W__2TZEnmgq9oQM=.232c5973-3e30-4161-90e2-7fae8a39cb27@github.com>
Message-ID: <trsusRgdNOsDtaMIgryeTCApN4FHXa7VOvkd0mmA4Vg=.dffc8b68-5040-42b8-a7d7-2d95609d6b36@github.com>

On Sun, 6 Oct 2024 14:50:48 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 174:
>> 
>>> 172:      * @since 24
>>> 173:      */
>>> 174:     public static Reader of(CharSequence c) {
>> 
>> Should we give this factory a more specific name so we don't clash in the future? For example, if we add another factory `of(A a)` for interface `A`, then it would be confusing to have an instance of `interface C extends CharSequence, A` to be passed to `of`.
>
> I do not see what is "confusing" in that case, as the caller still gets what he intends: a reader for the passed source. I also wonder how likely that case actually is. Anyways, I may be biased as I proposed `of`.
> 
> @AlanBateman WDYT?

You'll get different opinions on naming, personally I think Reader.of(cs) is very readable at use-sites. There are several other static methods named "of" added in other areas in recent years.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1789694010

From duke at openjdk.org  Mon Oct  7 07:44:53 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 7 Oct 2024 07:44:53 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v27]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <oV3G0FeUcnoPuM4bnGAG-ae-a4xqEEWV0TCtbstg1B8=.e54f85bd-9ac4-4a8c-acdb-7d3e24ed133b@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  More explaining variable identificator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/71a3e6f3..1143fbc5

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

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

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

From duke at openjdk.org  Mon Oct  7 07:54:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 7 Oct 2024 07:54:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v28]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <JKtZfUans04_AXWOfSDLrjvrUBe-U5_D01ppAQdQx3o=.ee3437c7-2952-48e0-b0de-0b60ed6a3472@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Minor change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/1143fbc5..bef9f63e

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

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

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

From eosterlund at openjdk.org  Mon Oct  7 08:18:41 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 7 Oct 2024 08:18:41 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v8]
In-Reply-To: <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
Message-ID: <1wozINQzLtWk9n5DJDqTW_BBQgwmOGQpJAfOJR70uC0=.7668e905-c863-4e69-bca1-695de43cb80a@github.com>

On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More precise bit-unmasks

One last thing...

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 342:

> 340:   }
> 341:   if ((on_weak || on_phantom) && no_keepalive) {
> 342:     // Be extra paranoid around this path. Only accept null stores,

I think there might be some orthogonal stuff that is unnecessarily mixed up here. When no_keepalive is manually specified, then we shouldn't do the pre-write barrier, regardless of reference strength. Similarly, when the new value is null, we don't need to perform the post write barrier, regardless of reference strength. Roberto added some code in refine_barrier_by_new_val_type that already *should* take care of the latter part. It allows types to flow around a bit, and then checks if the type of the new value is provably null, and then removes the post write barrier. The existing logic for that should be strictly more powerful than the new check you added, I think.

Based on the above explanation, I think I'm proposing this block is replaced with this simpler condition:

if (no_keepalive) {
  access.set_barrier_data(access.barrier_data() & ~G1C2BarrierPre);
}

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

Changes requested by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2351232319
PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1789742277

From luhenry at openjdk.org  Mon Oct  7 08:24:40 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 7 Oct 2024 08:24:40 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: <Bw0ovX5nnjP7DZdogwh49sFfjMECiZBWwmz3qnC0zfg=.3c5451ba-db32-4ea3-a289-699f0eb0f186@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.

Marked as reviewed by luhenry (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21374#pullrequestreview-2351246219

From aefimov at openjdk.org  Mon Oct  7 09:00:28 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 7 Oct 2024 09:00:28 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v11]
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

Aleksei Efimov 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 16 additional commits since the last revision:

 - Merge remote-tracking branch 'origin' into JDK-8339538_DnsClient_nanoTime_And_InfiniteLoop
 - improve reporting for unrecoverable exceptions
 - Add comment suggested by Daniel
 - Track unfulfilled timeouts during UDP queries.
   Update exceptions handling.
   Update TCP client to use nano time source.
 - set min timeout to 0; set max allowed timeout to 2x expected timeout in tests
 -  set max allowed value for retries to 30
 - update tests to calculate allowed timeout range (max is updated to 75%), print it and use it for elapsed time check
 - remove redundant clamp from timeoutLeft calculation
 - clamp timeout and retries property values
 - Measure time the caller spent waiting. Simplify timeoutLeft computation
 - ... and 6 more: https://git.openjdk.org/jdk/compare/6a204ae6...c58e34cc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20892/files
  - new: https://git.openjdk.org/jdk/pull/20892/files/5177a885..c58e34cc

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

  Stats: 211149 lines in 1771 files changed: 189365 ins; 12465 del; 9319 mod
  Patch: https://git.openjdk.org/jdk/pull/20892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20892/head:pull/20892

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

From pkoppula at openjdk.org  Mon Oct  7 09:14:26 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Mon, 7 Oct 2024 09:14:26 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v3]
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: <Pt_VhdtTk6QpSKK5WRs7F0lu7jzI8f2g1ooW-8bKENE=.852fcf48-4b07-4bec-a402-f5f250558d92@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:

  JDK-8329251

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/e23a70d6..7b5dca17

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

  Stats: 132 lines in 10 files changed: 112 ins; 14 del; 6 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 duke at openjdk.org  Mon Oct  7 09:41:56 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 7 Oct 2024 09:41:56 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v29]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <AhhtVkcNMBPTGhZFpk-DecwsY2js5qGqE_m_kZWLrLY=.41f960be-9838-4fbb-888a-fa81bb62e8eb@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Speed up computation of shiftRight() and bitLength()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/bef9f63e..eb85b04e

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

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

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

From eirbjo at openjdk.org  Mon Oct  7 09:43:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 09:43:37 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v2]
In-Reply-To: <HgTsAnCSEJ_h2u1ml2PqGE23K7iqd0mrs5WwrWRSV4M=.6ee34c6f-a4cd-411d-89bb-019e1bfd35d2@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <pt9PTK6wJXLhOGDwdw_uoqx9v3977XX8qGj8CcmWf9E=.96b8bd35-4d72-4d79-bf2d-5a6c55e2a3cc@github.com>
 <k-S9nKpxa3RLlPhQjPz34FlJ7j_5KrcvGT-FupyzAjk=.371705c2-c60a-4414-8323-20c95fea67d3@github.com>
 <G9j5IUeHQcGbN-nEwD3102afQS8K-Kp12Ma0heZba-A=.e16fac17-4f83-41b8-9cd8-d411025dc9dd@github.com>
 <wRsRHkY-RoqP9zhrbTNLRFhzvEGwn7npG8-jaLbD268=.63553593-380f-4b28-9ddb-326d14f0e424@github.com>
 <HgTsAnCSEJ_h2u1ml2PqGE23K7iqd0mrs5WwrWRSV4M=.6ee34c6f-a4cd-411d-89bb-019e1bfd35d2@github.com>
Message-ID: <c7hSCknjNc16rOtv-dqBXP7aI88-LM3dCQrFFl2omeo=.f06c6bd5-4ec0-4712-86d1-2d86a98eb46a@github.com>

On Sun, 6 Oct 2024 21:49:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> How would you model unsigned long values here, though?
>> 
>> I don't think we should. `9223372036854775807 ` should be enough for everyone :-)
>> 
>> It may be worth renaming the method to `get64S` and add a `get64` variant which either clamps at `LONG.MAX_VALUE` or throws `IllegalArgumentException` for larger values. Call sites doing custom validation (like `checkZip64ExtraFieldValues`) could then call `get64S` and check for a negative long.
>> 
>> But that's food for another PR.
>
> Renaming to `get64S` is reasonable to be internally consistent. Updated. Improving validation of data in such 64-bit fields I'll leave for the future. I think a reasonable stance is to throw in the `check` methods if any such field is negative, at least for some of these fields.

> FWIW we already cap some values even lower in practice:
> 
> ```
>                             end.centot = (int)centot64; // assume total < 2g
> ```

I submitted #21384 which adds validation of end.centot and also eliminates this narrowing conversion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1789881954

From eirbjo at openjdk.org  Mon Oct  7 09:46:47 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 09:46:47 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header
Message-ID: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>

Please review this PR which adds validation of the 'total entries' value when fetched from the 'ZIP64 End of Central Directory' header.

We should reject this value under the following conditions:

1. It is too large to fit within the specified CEN size (considering each CEN header encodes as at least 46 bytes each)
2. It is too large to create the `int[] entries` array safely (max value is `ArraysSupport.SOFT_MAX_ARRAY_LENGTH / 3`)

I claim that condition 2 here is already implicitly validated by the current maximum CEN size validation. (A CEN encoding such a large number of entries would exceed the maximum CEN size a lot and would already be rejected)

This change aims to protect the integrity of the implementation against specially crafted ZIP files. No sane ZIP tool will produce such files. 

Testing:

This PR adds a test `EndOfCenValidation.shouldRejectBadTotalEntries` which exercises the first condition above.

ZIP tests run locally. GHA results pending.

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

Commit messages:
 - No need to check MAX_ENTRIES, since MAX_ENTRIES * 46 would exceed the MAX_CEN_SIZE anyhow
 - Test comment should be specific that this requires Zip64
 - Improve ZipFile validation of Zip64 END headers

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

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

From jvernee at openjdk.org  Mon Oct  7 10:46:38 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 7 Oct 2024 10:46:38 GMT
Subject: RFR: 8341593: Problemlist java/foreign/TestUpcallStress.java in
 Xcomp mode
In-Reply-To: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
References: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
Message-ID: <04hBO5fxLUw6677Xf2EhM-E-RwTtvaRcSBd4HddQa9o=.cec441f0-e7d0-4dae-9d76-4c5a0950171d@github.com>

On Sun, 6 Oct 2024 09:15:58 GMT, SendaoYan <syan at openjdk.org> wrote:

> A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp mode.

Marked as reviewed by jvernee (Reviewer).

FWIW, I think it would be okay to disable this test on -Xcomp altogether. It tests a very precise race, so -Xcomp probably will never trigger the problematic use-case.

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

PR Review: https://git.openjdk.org/jdk/pull/21375#pullrequestreview-2351570263
PR Comment: https://git.openjdk.org/jdk/pull/21375#issuecomment-2396566442

From eirbjo at openjdk.org  Mon Oct  7 11:12:15 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 11:12:15 GMT
Subject: RFR: 8341595: Clean up iteration of CEN headers in
 ZipFile.Source.initCEN
Message-ID: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>

Please review this PR which suggests we clean up iteration and validation logic in `ZipFile.Source::initCEN` and some related methods to use a simpler and more consistent style:

* The main loop in `ZipFile.Source::initCEN` currently updates two iteration variables (`pos` and `entryPos`), where `entryPos` is always just `pos + CENHDR`. One variable should be sufficient. `entryPos` can be moved to an effectively final local variable scoped inside the loop.
* The local variable `int limit = cen.length` no longer carries its weight and is inlined into its only use site
* Since `entryPos` is no longer in scope for the loop predicate, this is updated to `pos <= cen.length - CENHDR`, instead of the current `entryPos <= limit`
* The byte array passed to `countCENHeaders` contains only CEN data now, so the `size` parameter can be removed.
*  `countCENHeaders` is updated to loop on the same predicate as `initCEN`. Additionally, this method is updated to  throw early if a CEN entry exceeds the CEN size (for consistency with similar logic in `checkAndAddEntry`)
* The `headerSize` validation in `checkAndAddEntry` is updated to avoid widening conversion to `long` of a variable which can provably never exceed `Integer.MAX_VALUE` and to be consistent with  `countCENHeaders`.

Testing: 

A new test `CenSizeMaximum` is added:
* This produces a ZIP file with a CEN size of exactly `MAX_CEN_SIZE` and verifies that the iteration logic handles ZIP files where the CEN size is on or near the limit.
* This test also manipulates the END headers  'total number of entries' field, in order to exercise `countCENHeader`. 
* The test is a bit of a resource hog: It produces a  ~1.5GB ZIP file on disk, requires > 2GB heap and takes > 15 seconds to run on my laptop. Let me know if this should be made a manual test.

GHA tests are currently pending. I have run the following tests locally:


% make test TEST="test/jdk/java/util/zip" 
% make test TEST="test/jdk/java/util/jar"

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

Commit messages:
 - Run CenSizeMaximum with /othervm -Xmx2500M
 - Inline the only use of the `limit` local variable
 - Clean up iteration of CEN headers in ZipFile.Source.initCEN

Changes: https://git.openjdk.org/jdk/pull/21378/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21378&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341595
  Stats: 264 lines in 2 files changed: 251 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21378.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21378/head:pull/21378

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

From viktor.klang at oracle.com  Mon Oct  7 11:18:56 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 7 Oct 2024 11:18:56 +0000
Subject: Fw: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <70dd1271-09b2-424c-ac40-6228756a8c86@gmail.com>
References: <20240902175543.44781778E42@eggemoggin.niobe.net>
 <70dd1271-09b2-424c-ac40-6228756a8c86@gmail.com>
Message-ID: <MW4PR10MB57744C18ED9E38FC78701E55FF7D2@MW4PR10MB5774.namprd10.prod.outlook.com>

(Moving this to core-libs-dev)

Cay,

Regarding 1, Characteristics was a part of the Gatherers-contract for a very long time, alas it didn't end up worth its cost. There's a longer discussion on the topic here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/118138.html (and I'm sure that there were more, but that's the one which comes to mind)

Regarding 2, I did have a prototype which had a Downstream in the Combiner, but created a new dimension of complexity which made it even harder for people to move from sequential to parallelizable. The door isn't closed on it, but I remain unconvinced it's worth the surface area for performance reasons.

As a bit of a side-note, it's worth knowing that in the reference stream implementation, it is not unusual that parallel-capable stages are executed as "islands" which means that short-circuiting signals cannot travel across those islands. Since parallel-capable Gatherers can be fused to execute in the same "island" if we get to a place where "all" intermediate operations are parallel-capable Gatherers, there'd be a single end-to-end "island" and hence the ability to propagate the short-circuiting would be preserved in all modes of execution. Also worth knowing that a `gather(?)` immediately followed by a `collect(?)` can also be fused to run together.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: jdk-dev <jdk-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
Sent: Friday, 4 October 2024 19:58
To: jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: Re: New candidate JEP: 485: Stream Gatherers

Hi, I have some belated questions about the design choices in this API that I could not find addressed in the JEP.

1. Why aren't characteristics used to express "greediness/short-circuiting" or "sequentialness/parallelizability"?

I understand that for the former I use ofGreedy/of, or implement Gatherers.Integrator.Greedy/Gatherers.Integrator. And for the latter, I use ofSequential/of, or, if I implement the Gatherer interface, have the combiner return defaultCombiner() or not.

But it seems a bit complex and less familiar than the characteristics mechanism that exists for spliterators, streams, and collectors.

The original design document (https://cr.openjdk.org/~vklang/Gatherers.html) used characteristics, so I wonder what motivated the change.

2. Why wasn't the combiner() designed to allow pushing of elements to the end of the first range's sink? Then distinctBy could be parallelized without buffering the elements. More generally, with some state fiddling one can then handle the elements around range splits.

As it is, I don't see how to parallelize such computations other than to buffer all elements.

I looked at the project at https://github.com/jhspetersson/packrat that implements a number of gatherers. Only one uses a combiner, to join buffers until their contents can be pushed in the finisher.

Cheers,

Cay

On 02/09/2024 19:55, Mark Reinhold wrote:
> https://openjdk.org/jeps/485
>
>    Summary: Enhance the Stream API to support custom intermediate
>    operations.  This will allow stream pipelines to transform data in ways
>    that are not easily achievable with the existing built-in intermediate
>    operations.
>
> - Mark

--

Cay S. Horstmann | https://horstmann.com

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

From dfuchs at openjdk.org  Mon Oct  7 11:25:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 7 Oct 2024 11:25:40 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v11]
In-Reply-To: <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
Message-ID: <p63IB0zfkOvITwRFjjCPiwXN5SPpXvIUWcLd_-jYSBk=.455a8f12-1812-47a1-a509-7b009de3a5b7@github.com>

On Mon, 7 Oct 2024 09:00:28 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov 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 16 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into JDK-8339538_DnsClient_nanoTime_And_InfiniteLoop
>  - improve reporting for unrecoverable exceptions
>  - Add comment suggested by Daniel
>  - Track unfulfilled timeouts during UDP queries.
>    Update exceptions handling.
>    Update TCP client to use nano time source.
>  - set min timeout to 0; set max allowed timeout to 2x expected timeout in tests
>  -  set max allowed value for retries to 30
>  - update tests to calculate allowed timeout range (max is updated to 75%), print it and use it for elapsed time check
>  - remove redundant clamp from timeoutLeft calculation
>  - clamp timeout and retries property values
>  - Measure time the caller spent waiting. Simplify timeoutLeft computation
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/f0646048...c58e34cc

Marked as reviewed by dfuchs (Reviewer).

Thanks Aleksei. I believe reporting the exception that causes to switch `doNotRetry[i]` to `true` when there is a single server is the right thing to do... In case of several servers, there isn't any obvious choice since the other servers could eventually give a valid response, or timeout... In that case adding the exception to a possibly pre-existing (TimeoutException?) with addSuppressed() looks like the best choice.

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

PR Review: https://git.openjdk.org/jdk/pull/20892#pullrequestreview-2351664712
PR Comment: https://git.openjdk.org/jdk/pull/20892#issuecomment-2396649911

From duke at openjdk.org  Mon Oct  7 11:32:37 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 7 Oct 2024 11:32:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
Message-ID: <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>

On Mon, 23 Sep 2024 16:35:18 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:
> 
>   Reword doce

I'll add this here because the rules are still seems not complete. I can create a structure ending with PaddingLayout

{
    Linker linker = Linker.nativeLinker();
    var sequence0a8 = MemoryLayout.sequenceLayout(0, JAVA_LONG);
    var sequence3a1 = MemoryLayout.sequenceLayout(3, JAVA_BYTE);
    var padding5a1 = MemoryLayout.paddingLayout(5);
    var struct8a8 = MemoryLayout.structLayout(sequence0a8, sequence3a1, padding5a1);
    var fd = FunctionDescriptor.of(struct8a8, struct8a8, struct8a8);
    linker.downcallHandle(fd);
}

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2396660563

From redestad at openjdk.org  Mon Oct  7 11:40:38 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 7 Oct 2024 11:40:38 GMT
Subject: RFR: 8341595: Clean up iteration of CEN headers in
 ZipFile.Source.initCEN
In-Reply-To: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>
References: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>
Message-ID: <8Talu6w0Y085npKNBM0-Iql0XF0gmVgZanj9Yr9wg5Q=.48ed0ef2-9dc2-426b-ac5b-65441bdb5ab2@github.com>

On Sun, 6 Oct 2024 16:42:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests we clean up iteration and validation logic in `ZipFile.Source::initCEN` and some related methods to use a simpler and more consistent style:
> 
> * The main loop in `ZipFile.Source::initCEN` currently updates two iteration variables (`pos` and `entryPos`), where `entryPos` is always just `pos + CENHDR`. One variable should be sufficient. `entryPos` can be moved to an effectively final local variable scoped inside the loop.
> * The local variable `int limit = cen.length` no longer carries its weight and is inlined into its only use site
> * Since `entryPos` is no longer in scope for the loop predicate, this is updated to `pos <= cen.length - CENHDR`, instead of the current `entryPos <= limit`
> * The byte array passed to `countCENHeaders` contains only CEN data now, so the `size` parameter can be removed.
> *  `countCENHeaders` is updated to loop on the same predicate as `initCEN`. Additionally, this method is updated to  throw early if a CEN entry exceeds the CEN size (for consistency with similar logic in `checkAndAddEntry`)
> * The `headerSize` validation in `checkAndAddEntry` is updated to avoid widening conversion to `long` of a variable which can provably never exceed `Integer.MAX_VALUE` and to be consistent with  `countCENHeaders`.
> 
> Testing: 
> 
> A new test `CenSizeMaximum` is added:
> * This produces a ZIP file with a CEN size of exactly `MAX_CEN_SIZE` and verifies that the iteration logic handles ZIP files where the CEN size is on or near the limit.
> * This test also manipulates the END headers  'total number of entries' field, in order to exercise `countCENHeader`. 
> * The test is a bit of a resource hog: It produces a  ~1.5GB ZIP file on disk, requires > 2GB heap and takes > 15 seconds to run on my laptop. Let me know if this should be made a manual test.
> 
> GHA tests are currently pending. I have run the following tests locally:
> 
> 
> % make test TEST="test/jdk/java/util/zip" 
> % make test TEST="test/jdk/java/util/jar"

LGTM

src/java.base/share/classes/java/util/zip/ZipFile.java line 1772:

> 1770:             int pos = 0;
> 1771:             manifestNum = 0;
> 1772:             while (pos <= cen.length - CENHDR) {

The interpreter would probably like something like: 

int limit = cen.length - CENHDR;
while (pos <= limit) {

test/jdk/java/util/zip/ZipFile/CenSizeMaximum.java line 24:

> 22:  */
> 23: 
> 24: /* @test

Yes, this test probably should be either manual or moved to a higher tier.

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

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21378#pullrequestreview-2351690639
PR Review Comment: https://git.openjdk.org/jdk/pull/21378#discussion_r1790053062
PR Review Comment: https://git.openjdk.org/jdk/pull/21378#discussion_r1790055277

From eirbjo at openjdk.org  Mon Oct  7 12:16:15 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 12:16:15 GMT
Subject: RFR: 8341595: Clean up iteration of CEN headers in
 ZipFile.Source.initCEN [v2]
In-Reply-To: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>
References: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>
Message-ID: <kknwk_ky0FnMG3jKPxUCbvfiHqVHiVFKInKU_OOtmxQ=.ed08ed67-82bb-4cc8-ada8-259378d75c00@github.com>

> Please review this PR which suggests we clean up iteration and validation logic in `ZipFile.Source::initCEN` and some related methods to use a simpler and more consistent style:
> 
> * The main loop in `ZipFile.Source::initCEN` currently updates two iteration variables (`pos` and `entryPos`), where `entryPos` is always just `pos + CENHDR`. One variable should be sufficient. `entryPos` can be moved to an effectively final local variable scoped inside the loop.
> * The local variable `int limit = cen.length` no longer carries its weight and is inlined into its only use site
> * Since `entryPos` is no longer in scope for the loop predicate, this is updated to `pos <= cen.length - CENHDR`, instead of the current `entryPos <= limit`
> * The byte array passed to `countCENHeaders` contains only CEN data now, so the `size` parameter can be removed.
> *  `countCENHeaders` is updated to loop on the same predicate as `initCEN`. Additionally, this method is updated to  throw early if a CEN entry exceeds the CEN size (for consistency with similar logic in `checkAndAddEntry`)
> * The `headerSize` validation in `checkAndAddEntry` is updated to avoid widening conversion to `long` of a variable which can provably never exceed `Integer.MAX_VALUE` and to be consistent with  `countCENHeaders`.
> 
> Testing: 
> 
> A new test `CenSizeMaximum` is added:
> * This produces a ZIP file with a CEN size of exactly `MAX_CEN_SIZE` and verifies that the iteration logic handles ZIP files where the CEN size is on or near the limit.
> * This test also manipulates the END headers  'total number of entries' field, in order to exercise `countCENHeader`. 
> * The test is a bit of a resource hog: It produces a  ~1.5GB ZIP file on disk, requires > 2GB heap and takes > 15 seconds to run on my laptop. Let me know if this should be made a manual test.
> 
> GHA tests are currently pending. I have run the following tests locally:
> 
> 
> % make test TEST="test/jdk/java/util/zip" 
> % make test TEST="test/jdk/java/util/jar"

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Mark this resource hungry test manual
 - For the benefit of the interpreter, extract loop predicate into a local variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21378/files
  - new: https://git.openjdk.org/jdk/pull/21378/files/142bc7ac..504e1022

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

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

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

From eirbjo at openjdk.org  Mon Oct  7 12:16:16 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 12:16:16 GMT
Subject: RFR: 8341595: Clean up iteration of CEN headers in
 ZipFile.Source.initCEN [v2]
In-Reply-To: <8Talu6w0Y085npKNBM0-Iql0XF0gmVgZanj9Yr9wg5Q=.48ed0ef2-9dc2-426b-ac5b-65441bdb5ab2@github.com>
References: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>
 <8Talu6w0Y085npKNBM0-Iql0XF0gmVgZanj9Yr9wg5Q=.48ed0ef2-9dc2-426b-ac5b-65441bdb5ab2@github.com>
Message-ID: <5T9KmUGknqWDhVLnQN8MBYPQeYVD58UElgTlfJJto1g=.dec1dc3e-e73e-453e-8bff-d2ee9a49cbd1@github.com>

On Mon, 7 Oct 2024 11:35:00 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Mark this resource hungry test manual
>>  - For the benefit of the interpreter, extract loop predicate into a local variable
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1772:
> 
>> 1770:             int pos = 0;
>> 1771:             manifestNum = 0;
>> 1772:             while (pos <= cen.length - CENHDR) {
> 
> The interpreter would probably like something like: 
> 
> int limit = cen.length - CENHDR;
> while (pos <= limit) {

Fixed, look like a good improvement.

> test/jdk/java/util/zip/ZipFile/CenSizeMaximum.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: /* @test
> 
> Yes, this test probably should be either manual or moved to a higher tier.

Added `/manual` for now since I wouldn't know how to move tests between tiers :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21378#discussion_r1790106513
PR Review Comment: https://git.openjdk.org/jdk/pull/21378#discussion_r1790107718

From pkoppula at openjdk.org  Mon Oct  7 12:42:00 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Mon, 7 Oct 2024 12:42:00 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v4]
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: <Tb-8iAEg9YHtjK6lRiLcVbKy9vkgEVwmzZu2g9-v5NQ=.c12dd52f-507b-46ed-9cb4-95bba858c32d@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:

  JDK-8329251

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/7b5dca17..4e65df66

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

  Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 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 mcimadamore at openjdk.org  Mon Oct  7 12:52:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 12:52:39 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
Message-ID: <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>

On Mon, 7 Oct 2024 11:27:33 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> Another test example. I can create a structure ending with PaddingLayout
> 
> ```
> {
>     Linker linker = Linker.nativeLinker();
>     var sequence0a8 = MemoryLayout.sequenceLayout(0, JAVA_LONG);
>     var sequence3a1 = MemoryLayout.sequenceLayout(3, JAVA_BYTE);
>     var padding5a1 = MemoryLayout.paddingLayout(5);
>     var struct8a8 = MemoryLayout.structLayout(sequence0a8, sequence3a1, padding5a1);
>     var fd = FunctionDescriptor.of(struct8a8, struct8a8, struct8a8);
>     linker.downcallHandle(fd);
> }
> ```
> 
> Is it just me or is this a legal way to create an over-aligned layout?
> 
> ```
> {
>     Linker linker = Linker.nativeLinker();
>     var sequence0a8 = MemoryLayout.sequenceLayout(0, JAVA_LONG);
>     var sequence8a1 = MemoryLayout.sequenceLayout(8, JAVA_BYTE);
>     var struct8a8 = MemoryLayout.structLayout(sequence0a8, sequence8a1);
>     var fd = FunctionDescriptor.of(struct8a8, struct8a8, struct8a8);
>     linker.downcallHandle(fd);
> }
> ```
> 
> If I remove the PaddingLayout, the structure appears to be completely normal, except that it doesn't contain a single real element that needs alignment 8

I think the new rules should explicitly ban zero-element sequence layouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2396840477

From duke at openjdk.org  Mon Oct  7 12:56:38 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 7 Oct 2024 12:56:38 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
 <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
Message-ID: <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>

On Mon, 7 Oct 2024 12:49:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I think the new rules should explicitly ban zero-element sequence layouts.

Even in the rules with the latest edits, I don't see what exactly should prohibit such sequences.

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2396850262

From hannesw at openjdk.org  Mon Oct  7 13:53:17 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 7 Oct 2024 13:53:17 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v6]
In-Reply-To: <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
Message-ID: <wz7IX62CEPy8TOx8bUzw5hNC3FkDeIQseh157t6fkTc=.6d12142f-ac3d-4811-aace-8b207891f749@github.com>

On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix paths to links

I created a sub-PR for streamlining integration of this feature into JavaDoc code: mcimadamore/jdk#22

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

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2396993903

From mcimadamore at openjdk.org  Mon Oct  7 14:20:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 14:20:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
 <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
 <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>
Message-ID: <TZnn83hm2GBJtvMeO0tHi6NuToWvy0AJ3PiHDZlXScw=.671a271e-1f2e-4b33-88f4-0a73b035e793@github.com>

On Mon, 7 Oct 2024 12:54:00 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> > I think the new rules should explicitly ban zero-element sequence layouts.
> 
> Even in the rules with the latest edits, I don't see what exactly should prohibit such sequences.
> 
> Also, if they are banned, won't that break jextract and some user code? Additionally, I think many people might use zero-length sequences for layouts that are architecture-dependent.

Let me clarify. The javadoc rules we're talking about try to define a set of suported layout across _all linkers_. As such, the rules have to try and find some lowest common denominator between the various platforms.

While GCC does seem to support empty struct fields and empty sequence fields in structs, other compilers (e.g. MSVC) do not. As such, the set of minimally supported layouts should not allow such fields.

Here's a refined set of rules to see if a group layout is in this minimally supported set:


{@code L} is a group layout {@code G} and all the following conditions hold:
1. the alignment constraint of {@code G} is set to its <a href="MemoryLayout.html#layout-align">natural alignment</a>;</li>
2. the size of {@code G} is a multiple of its alignment constraint;
3. each member layout in {@code G.memberLayouts()} is either a padding layout or a layout supported by {@code NL}
4. {@code G} contains at least a non-padding member layout
5. each padding member layout in {@code G} is naturaly aligned
6. each non-padding member layout in {@code G} follows an optional padding member layout, whose size is the minimum size required to align E;
7. {@code G} contains an optional trailing padding member layout, whose size is the minimum size that satisfies (2)


(and, we need an additional restriction, to say that zero-element sequence layouts are not part of the minimally supported set).

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2397064613

From duke at openjdk.org  Mon Oct  7 14:27:21 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 7 Oct 2024 14:27:21 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v30]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <F_hIzJL4ANeN5n4wV6sfTT_ogRi0f0pKeAz2qZp4occ=.659b318d-b554-4e69-b978-12fa35243fa2@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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

  Correct typo in comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/eb85b04e..4c880789

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=28-29

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

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

From duke at openjdk.org  Mon Oct  7 14:53:38 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 7 Oct 2024 14:53:38 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
Message-ID: <6z8DU95bUuRMRfcpMvt_Dl9hiiv-jUWcoiELWyIVUvA=.d00b59ca-e945-4514-beed-c7e9af311a68@github.com>

On Mon, 23 Sep 2024 16:35:18 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:
> 
>   Reword doce

These rules talk about GroupLayout, and use the term "follow" for group members. But surely this is only true for structs, not unions? I don't really understand why unions should allow PaddingLayout inside themselves at all.

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2397151115

From syan at openjdk.org  Mon Oct  7 14:56:35 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 7 Oct 2024 14:56:35 GMT
Subject: RFR: 8341593: Problemlist java/foreign/TestUpcallStress.java in
 Xcomp mode
In-Reply-To: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
References: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
Message-ID: <OyJB8JgYuk6oNtoh9JCIyYxN-6HXp3QPP015v2d1itg=.35a94c53-8ca0-4761-a3dd-8cfdf97fb6e1@github.com>

On Sun, 6 Oct 2024 09:15:58 GMT, SendaoYan <syan at openjdk.org> wrote:

> A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp mode.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21375#issuecomment-2397159519

From jvernee at openjdk.org  Mon Oct  7 14:59:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 7 Oct 2024 14:59:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <6z8DU95bUuRMRfcpMvt_Dl9hiiv-jUWcoiELWyIVUvA=.d00b59ca-e945-4514-beed-c7e9af311a68@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <6z8DU95bUuRMRfcpMvt_Dl9hiiv-jUWcoiELWyIVUvA=.d00b59ca-e945-4514-beed-c7e9af311a68@github.com>
Message-ID: <pNHSrljMamom6vCcyiwtFMH8zai6SwiAfRktyUr_XDM=.eaef7e2b-bfdd-41b5-9252-b091fa5eda61@github.com>

On Mon, 7 Oct 2024 14:50:33 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> I don't really understand why unions should allow PaddingLayout inside themselves at all.

Padding inside unions is required for a case like this:


union Foo {
    long long x;
    int arr[3];
};


Size of the struct without padding is 12 bytes, but it needs 8-byte alignment, so it needs 16 bytes of padding.

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2397166726

From duke at openjdk.org  Mon Oct  7 15:10:37 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 7 Oct 2024 15:10:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <TZnn83hm2GBJtvMeO0tHi6NuToWvy0AJ3PiHDZlXScw=.671a271e-1f2e-4b33-88f4-0a73b035e793@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
 <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
 <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>
 <TZnn83hm2GBJtvMeO0tHi6NuToWvy0AJ3PiHDZlXScw=.671a271e-1f2e-4b33-88f4-0a73b035e793@github.com>
Message-ID: <HUUa4UIjDXZvtksFPFVRg2kp8u2dZLyA-nC_9H2e3mk=.7bf8dc39-f3d1-499f-902a-112443229934@github.com>

On Mon, 7 Oct 2024 14:17:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> 4. {@code G} contains at least a non-padding member layout

I reread all the points again, now the fourth one confuses me. Does it mean that now linker will not support empty structures at all?

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2397199789

From lancea at openjdk.org  Mon Oct  7 15:18:36 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 15:18:36 GMT
Subject: RFR: 8341595: Clean up iteration of CEN headers in
 ZipFile.Source.initCEN [v2]
In-Reply-To: <kknwk_ky0FnMG3jKPxUCbvfiHqVHiVFKInKU_OOtmxQ=.ed08ed67-82bb-4cc8-ada8-259378d75c00@github.com>
References: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>
 <kknwk_ky0FnMG3jKPxUCbvfiHqVHiVFKInKU_OOtmxQ=.ed08ed67-82bb-4cc8-ada8-259378d75c00@github.com>
Message-ID: <PR0alwuifNB0Ivu9UptSadRr_xHhO-6pNrk115OJwyQ=.86d52cae-846d-4b39-ad96-311da172ba86@github.com>

On Mon, 7 Oct 2024 12:16:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests we clean up iteration and validation logic in `ZipFile.Source::initCEN` and some related methods to use a simpler and more consistent style:
>> 
>> * The main loop in `ZipFile.Source::initCEN` currently updates two iteration variables (`pos` and `entryPos`), where `entryPos` is always just `pos + CENHDR`. One variable should be sufficient. `entryPos` can be moved to an effectively final local variable scoped inside the loop.
>> * The local variable `int limit = cen.length` no longer carries its weight and is inlined into its only use site
>> * Since `entryPos` is no longer in scope for the loop predicate, this is updated to `pos <= cen.length - CENHDR`, instead of the current `entryPos <= limit`
>> * The byte array passed to `countCENHeaders` contains only CEN data now, so the `size` parameter can be removed.
>> *  `countCENHeaders` is updated to loop on the same predicate as `initCEN`. Additionally, this method is updated to  throw early if a CEN entry exceeds the CEN size (for consistency with similar logic in `checkAndAddEntry`)
>> * The `headerSize` validation in `checkAndAddEntry` is updated to avoid widening conversion to `long` of a variable which can provably never exceed `Integer.MAX_VALUE` and to be consistent with  `countCENHeaders`.
>> 
>> Testing: 
>> 
>> A new test `CenSizeMaximum` is added:
>> * This produces a ZIP file with a CEN size of exactly `MAX_CEN_SIZE` and verifies that the iteration logic handles ZIP files where the CEN size is on or near the limit.
>> * This test also manipulates the END headers  'total number of entries' field, in order to exercise `countCENHeader`. 
>> * The test is a bit of a resource hog: It produces a  ~1.5GB ZIP file on disk, requires > 2GB heap and takes > 15 seconds to run on my laptop. Let me know if this should be made a manual test.
>> 
>> GHA tests are currently pending. I have run the following tests locally:
>> 
>> 
>> % make test TEST="test/jdk/java/util/zip" 
>> % make test TEST="test/jdk/java/util/jar"
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark this resource hungry test manual
>  - For the benefit of the interpreter, extract loop predicate into a local variable

Thank you for the clean up Eirik... 

looks good

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21378#pullrequestreview-2352264596

From mcimadamore at openjdk.org  Mon Oct  7 15:36:36 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 15:36:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <HUUa4UIjDXZvtksFPFVRg2kp8u2dZLyA-nC_9H2e3mk=.7bf8dc39-f3d1-499f-902a-112443229934@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
 <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
 <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>
 <TZnn83hm2GBJtvMeO0tHi6NuToWvy0AJ3PiHDZlXScw=.671a271e-1f2e-4b33-88f4-0a73b035e793@github.com>
 <HUUa4UIjDXZvtksFPFVRg2kp8u2dZLyA-nC_9H2e3mk=.7bf8dc39-f3d1-499f-902a-112443229934@github.com>
Message-ID: <SopH0a9bp3Xi87FhX6SX9WF4Jg8lcvL3ykD1957yJ-Y=.045e878e-176d-42f4-b7a5-c00f1f39f618@github.com>

On Mon, 7 Oct 2024 15:08:05 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> > 4. {@code G} contains at least a non-padding member layout
> 
> I reread all the points again, now the fourth one confuses me. Does it mean that now linker will not support empty structures at all?
> 
> Previously you said this:
> 
> > So they should be allowed I think. (We don't currently reject them at least)

The rules are currently quite convoluted as we're trying, as stated above, to define a set of "minimally supported layouts" across linker implementations. That doesn't mean that if a layout doesn't adhere to the rules, it's rejected - it's dealt with in a linker-specific way.

In a discussion offline with @JornVernee we are considering to simplify this section of the linker specification by having *less* rules. The rules are used to state which layouts are well-formed. Think of well-formedness as a sort of check whether a layout is in canonical form. All layouts passed to the linker should adhere to these rules. The Linker can optionally reject more stuff it doesn't support (and that's alluded to, but not covered by the javadoc).

So, we could go about it this way:


A native linker only supports function descriptors whose argument/return layouts are *well-formed* layouts. More formally, a layout `L`is well-formed if:

* `L` is a value layout and `L` is derived from a canonical layout `C` such that  `L.byteAlignment() <= C.byteAlignment()`

* `L` is a sequence layout and all the following conditions hold:
   1. `L.byteAlignment()` is equal to the sequence layout's *natural alignment*, and
   2. `S.elementLayout()` is a well-defined layout

 * `L` is a group layout `G` and all the following conditions hold:
   1. `G.byteAlignment()` is equal to the group layout's *natural alignment*
   2. `G.byteSize()` is a multiple of `G.byteAlignment()`
   3. Each member layout in `G.memberLayouts()` is either a padding layout or a well-defined layout
   4. Each non-padding member layout in `G` follows an optional padding member layout, whose size is the minimum size required to align `E`
   5. `G` contains an optional trailing padding member layout, whose size is the minimum size that satisfies (2)


Note how these new rules are more liberal. But they constraint somehow the set of acceptable layouts, by making ruling out hyper-aligned layouts, or layouts with a non-minimal amount of padding. If a layout fails to adhere to any of the rules above, the `Linker` will fail (this is different from today). It is possible that a linker might come with its own restrictions - e.g. a `Linker` might not support empty structs or packed struct layouts, and so extra checks will be enforced (but it's outside the scope of the javadoc to define precise rules on a per-platform basis).

Does this restacking make things clearer?

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2397260962

From duke at openjdk.org  Mon Oct  7 15:51:43 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Mon, 7 Oct 2024 15:51:43 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <SopH0a9bp3Xi87FhX6SX9WF4Jg8lcvL3ykD1957yJ-Y=.045e878e-176d-42f4-b7a5-c00f1f39f618@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
 <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
 <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>
 <TZnn83hm2GBJtvMeO0tHi6NuToWvy0AJ3PiHDZlXScw=.671a271e-1f2e-4b33-88f4-0a73b035e793@github.com>
 <HUUa4UIjDXZvtksFPFVRg2kp8u2dZLyA-nC_9H2e3mk=.7bf8dc39-f3d1-499f-902a-112443229934@github.com>
 <SopH0a9bp3Xi87FhX6SX9WF4Jg8lcvL3ykD1957yJ-Y=.045e878e-176d-42f4-b7a5-c00f1f39f618@github.com>
Message-ID: <m_3Tinr34oMR8vH3TgpoL07mWMKqKPUgS3Sda56HrJ8=.fb4bca07-9f81-4b06-a99e-187bfce95163@github.com>

On Mon, 7 Oct 2024 15:32:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Does this restacking make things clearer?

I really like this new definition.

To what extent do these rules determine the compatibility of FFM calling conventions with the C calling convention? If I understand correctly, all layouts accepted by the linker must comply with the C calling convention, but must not allow all the cases that C allows?

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2397297069

From duke at openjdk.org  Mon Oct  7 15:55:27 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 7 Oct 2024 15:55:27 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v31]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <Q-FWw1fNhLLka4tKV7y74JFnoDT2GtsTRjT8sMIHXK0=.2f7c712d-5d7e-4de1-9421-6b6d4e4dc0cf@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

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 36 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patchStripTrailingZeros
 - Correct typo in comment
 - Speed up computation of shiftRight() and bitLength()
 - Minor change
 - More explaining variable identificator
 - Correct indentation
 - Refine the estimate of remaining zeros
 - Minor change
 - Optimization
 - An optimization
 - ... and 26 more: https://git.openjdk.org/jdk/compare/8530cce3...8b90da08

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/4c880789..8b90da08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=29-30

  Stats: 11821 lines in 232 files changed: 9817 ins; 1317 del; 687 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

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

From liach at openjdk.org  Mon Oct  7 16:08:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 16:08:36 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <Z8u0xGwDAZ2Wwh-ahLTVdgo4rstXVEhwZisWGi90Chs=.f63b1419-c32d-4f62-b390-db85fcbc67bd@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
 <odqOItnwT466uvC-KfooM2cZ9WqlHNqSL3_d6wQOJQI=.0a483584-d6a0-4a81-824f-23b8e9205106@github.com>
 <Z8u0xGwDAZ2Wwh-ahLTVdgo4rstXVEhwZisWGi90Chs=.f63b1419-c32d-4f62-b390-db85fcbc67bd@github.com>
Message-ID: <LgPjEgBHegKnqfxDRcLOzxoqcGBEjgnEoA6AD1DXh7Y=.280f7eac-9c00-4366-8298-88297c216760@github.com>

On Sun, 6 Oct 2024 17:23:51 GMT, Markus KARG <duke at openjdk.org> wrote:

> keep the reference to the char sequence "forever"

Note that this only happens if the `Reader` instance is kept forever; but a `Reader` is supposed to be used and closed and discarded instead of being held indefinitely after closing. If users are bad enough, they can never call `close` and the non-final `cs` is still leaked.

The right way of GC freeing is to let the GC free the reader and the char sequence together, instead of allowing to free when a client keeps this reader instance erroneously after closing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1790505636

From syan at openjdk.org  Mon Oct  7 16:31:46 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 7 Oct 2024 16:31:46 GMT
Subject: Integrated: 8341593: Problemlist java/foreign/TestUpcallStress.java in
 Xcomp mode
In-Reply-To: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
References: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
Message-ID: <CfRjZsxr_qSf6dxBLlT9ykPPPcLCiRCJIdlajZIm7w0=.233b530e-b55b-4829-be27-71b66355c95b@github.com>

On Sun, 6 Oct 2024 09:15:58 GMT, SendaoYan <syan at openjdk.org> wrote:

> A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp mode.

This pull request has now been integrated.

Changeset: 33595189
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3359518986bd12b0d97e5df5b0154d0539639818
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8341593: Problemlist java/foreign/TestUpcallStress.java in Xcomp mode

Reviewed-by: jvernee

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

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

From eirbjo at openjdk.org  Mon Oct  7 16:38:42 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 16:38:42 GMT
Subject: Integrated: 8341595: Clean up iteration of CEN headers in
 ZipFile.Source.initCEN
In-Reply-To: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>
References: <9tvuAyN3aujFV8peROUfYZ-bjswSNbU2TPzIuJNfMUA=.532d36a5-c027-4942-af2d-0ef4a241c3f1@github.com>
Message-ID: <H8V40WoRZGAqbVfinpnM9lezqMm-Vh0k_1VeoURB600=.12fc3883-32ba-4d27-861c-309da5732989@github.com>

On Sun, 6 Oct 2024 16:42:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests we clean up iteration and validation logic in `ZipFile.Source::initCEN` and some related methods to use a simpler and more consistent style:
> 
> * The main loop in `ZipFile.Source::initCEN` currently updates two iteration variables (`pos` and `entryPos`), where `entryPos` is always just `pos + CENHDR`. One variable should be sufficient. `entryPos` can be moved to an effectively final local variable scoped inside the loop.
> * The local variable `int limit = cen.length` no longer carries its weight and is inlined into its only use site
> * Since `entryPos` is no longer in scope for the loop predicate, this is updated to `pos <= cen.length - CENHDR`, instead of the current `entryPos <= limit`
> * The byte array passed to `countCENHeaders` contains only CEN data now, so the `size` parameter can be removed.
> *  `countCENHeaders` is updated to loop on the same predicate as `initCEN`. Additionally, this method is updated to  throw early if a CEN entry exceeds the CEN size (for consistency with similar logic in `checkAndAddEntry`)
> * The `headerSize` validation in `checkAndAddEntry` is updated to avoid widening conversion to `long` of a variable which can provably never exceed `Integer.MAX_VALUE` and to be consistent with  `countCENHeaders`.
> 
> Testing: 
> 
> A new test `CenSizeMaximum` is added:
> * This produces a ZIP file with a CEN size of exactly `MAX_CEN_SIZE` and verifies that the iteration logic handles ZIP files where the CEN size is on or near the limit.
> * This test also manipulates the END headers  'total number of entries' field, in order to exercise `countCENHeader`. 
> * The test is a bit of a resource hog: It produces a  ~1.5GB ZIP file on disk, requires > 2GB heap and takes > 15 seconds to run on my laptop. Let me know if this should be made a manual test.
> 
> GHA tests are currently pending. I have run the following tests locally:
> 
> 
> % make test TEST="test/jdk/java/util/zip" 
> % make test TEST="test/jdk/java/util/jar"

This pull request has now been integrated.

Changeset: f7bb647d
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7bb647dc88f835fe819e7ab0434c931f243304a
Stats:     265 lines in 2 files changed: 252 ins; 4 del; 9 mod

8341595: Clean up iteration of CEN headers in ZipFile.Source.initCEN

Reviewed-by: lancea, redestad

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

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

From syan at openjdk.org  Mon Oct  7 16:40:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 7 Oct 2024 16:40:09 GMT
Subject: RFR: 8341658: RISC-V: Test DateFormatProviderTest.java run timeouted
Message-ID: <XjeBa45z_vYwst-etRxuo0rGc4QB_4nxsWEnFGtmTmw=.9c98106f-d3f7-4cc2-8179-9c54c24acc2d@github.com>

Hi all,
The test `java/util/PluggableLocale/DateFormatProviderTest.java` run timeout on riscv64 physic machine. This test has 4496 sub-tests, and riscv64 has poor single core performance, so this test run timeouted on riscv64 seems acceptable.
Thus, to make less test noisy, I think we should add more timeout value for this test.
Test-fix only, no risk.

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

Commit messages:
 - 8341658: RISC-V: Test DateFormatProviderTest.java run timeouted

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

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

From rsunderbabu at openjdk.org  Mon Oct  7 16:40:14 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Mon, 7 Oct 2024 16:40:14 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging
Message-ID: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>

JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.

Testing:
tier1,tier2,tier3
tier6-comp,tier8-comp

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

Commit messages:
 - initial commit

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

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

From duke at openjdk.org  Mon Oct  7 16:48:45 2024
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 7 Oct 2024 16:48:45 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v9]
In-Reply-To: <8O4cLBgiKtvDB-LbpkdsMs-9DwrQ8i4_Vv9cVOZ7A7g=.46886782-6549-4095-912d-e66872d67d17@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
 <1z6p_WlO9R1dgc-H29ZjuewTZm04jg-d3YX4is0F8C4=.4405cf0d-484d-4ccc-8022-a37284142545@github.com>
 <8O4cLBgiKtvDB-LbpkdsMs-9DwrQ8i4_Vv9cVOZ7A7g=.46886782-6549-4095-912d-e66872d67d17@github.com>
Message-ID: <pi2pZ_HwW5fF3OcwOoKAKhjH5r5D0MS0Mca4BkJlcmM=.c9a98dfb-cb75-4449-96ec-02b30c06292d@github.com>

On Wed, 2 Oct 2024 20:24:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> First, some bit of history. These API methods are added before those constants, and this patch did not change the type of these methods or constants.

Sure, makes sense to separate this patch from a potential type change of the methods/constants.

> I believe the methods have restricted return types to be informative: `tag()` is a U1, but it can be interpreted as a char (see [JVMS 4.7.16.1](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) and thus is returned as one. CP tag is a U1 too (see [JVMS 4.4](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) so maybe `byte` is just used out of convenience.

I think `byte` and `char` as the types are a good choice given the way these tag items are described in the JVMS.

> However, we usually use `int` to represent U1, also called unsigned bytes. See [`DataInput::readUnsignedByte`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/io/DataInput.java#L323) and [`ClassReader::readU1`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/lang/classfile/ClassReader.java#L133). Guess that's why we used `int` for the constants. (Also, note that byte and char are all [erased to int](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/classfile/TypeKind.html#computational-type) in bytecode, so this has little practical effect and that might be why I didn't bother to change these)

One scenario where the unequal types of the methods and constants _does_ have a practical effect are JVM languages that don't have [binary numeric promotion](https://docs.oracle.com/javase/specs/jls/se23/html/jls-5.html#jls-5.6) for their [numerical equality operators](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.21.1).

This is the case for Kotlin's [value equality expressions](https://kotlinlang.org/spec/expressions.html#value-equality-expressions). This Kotlin code [would not compile](https://pl.kotl.in/A9D1WDdS8):

fun isArray(a: AnnotationValue): Boolean {
    return a.tag() == AnnotationValue.TAG_ARRAY
}

Instead you would have to write [this code](https://pl.kotl.in/qSrwSIL39):

fun isArray(a: AnnotationValue): Boolean {
    return a.tag() == AnnotationValue.TAG_ARRAY.toChar()
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1790562651

From liach at openjdk.org  Mon Oct  7 16:49:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 16:49:05 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName
In-Reply-To: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
Message-ID: <79XNoRK8qWyYLH4rR4-SfjfQYmBs3gO5DoRpceRGlDo=.7a1533a5-7f77-4ab3-943c-f496f2101670@github.com>

On Sun, 6 Oct 2024 01:22:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

Changes requested by liach (Reviewer).

The caching of class entry forms in ReferenceClassDescImpl may be controversial; I will consult with other engineers.

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 152:

> 150:             return rcd.internalName();
> 151:         }
> 152:         return cd.descriptorString();

Suggestion:

        rthrow new IllegalArgumentException(desc);

-------------

PR Review: https://git.openjdk.org/jdk/pull/21373#pullrequestreview-2350548154
PR Comment: https://git.openjdk.org/jdk/pull/21373#issuecomment-2395467102
PR Review Comment: https://git.openjdk.org/jdk/pull/21373#discussion_r1789119065

From swen at openjdk.org  Mon Oct  7 16:49:05 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 7 Oct 2024 16:49:05 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName
In-Reply-To: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
Message-ID: <f5BKM-FjTHQgbLYxTnfNp9rexOjAihyBe1QThNi_oRg=.8557d008-f16c-47db-92b8-1b8dfa58a8ae@github.com>

On Sun, 6 Oct 2024 01:22:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

In many scenarios where classfile is used, ClassDesc is cached by statically declaring constants, such as InvokerBytecodeGenerator/StringConcatFactory. 

However, internalName is generated by subString every time bytecode is built, which means that the purpose of caching ClassDesc is not fully achieved.

This problem can be solved by caching internalName.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21373#issuecomment-2395482862

From swen at openjdk.org  Mon Oct  7 16:49:05 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 7 Oct 2024 16:49:05 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName
Message-ID: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>

ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

-------------

Commit messages:
 - suggestion from @liach
 - stable
 - ReferenceClassDescImpl cache internalName

Changes: https://git.openjdk.org/jdk/pull/21373/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341664
  Stats: 97 lines in 5 files changed: 14 ins; 74 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21373/head:pull/21373

PR: https://git.openjdk.org/jdk/pull/21373

From liach at openjdk.org  Mon Oct  7 17:10:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 17:10:39 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v9]
In-Reply-To: <pi2pZ_HwW5fF3OcwOoKAKhjH5r5D0MS0Mca4BkJlcmM=.c9a98dfb-cb75-4449-96ec-02b30c06292d@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
 <1z6p_WlO9R1dgc-H29ZjuewTZm04jg-d3YX4is0F8C4=.4405cf0d-484d-4ccc-8022-a37284142545@github.com>
 <8O4cLBgiKtvDB-LbpkdsMs-9DwrQ8i4_Vv9cVOZ7A7g=.46886782-6549-4095-912d-e66872d67d17@github.com>
 <pi2pZ_HwW5fF3OcwOoKAKhjH5r5D0MS0Mca4BkJlcmM=.c9a98dfb-cb75-4449-96ec-02b30c06292d@github.com>
Message-ID: <IaQ3eFD_4Ki3praZgk4Fny0uCpBFjmsZODAaouRk4pA=.3fc52b8c-7657-4ca9-9a1d-159f1c31f070@github.com>

On Mon, 7 Oct 2024 16:45:28 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> First, some bit of history. These API methods are added before those constants, and this patch did not change the type of these methods or constants.
>> 
>> I believe the methods have restricted return types to be informative: `tag()` is a U1, but it can be interpreted as a char (see [JVMS 4.7.16.1](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) and thus is returned as one. CP tag is a U1 too (see [JVMS 4.4](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) so maybe `byte` is just used out of convenience.
>> 
>> However, we usually use `int` to represent U1, also called unsigned bytes. See [`DataInput::readUnsignedByte`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/io/DataInput.java#L323) and [`ClassReader::readU1`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/lang/classfile/ClassReader.java#L133). Guess that's why we used `int` for the constants. (Also, note that byte and char are all [erased to int](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/classfile/TypeKind.html#computational-type) in bytecode, so this has little practical effect and that might be why I didn't bother to change these)
>
>> First, some bit of history. These API methods are added before those constants, and this patch did not change the type of these methods or constants.
> 
> Sure, makes sense to separate this patch from a potential type change of the methods/constants.
> 
>> I believe the methods have restricted return types to be informative: `tag()` is a U1, but it can be interpreted as a char (see [JVMS 4.7.16.1](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) and thus is returned as one. CP tag is a U1 too (see [JVMS 4.4](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) so maybe `byte` is just used out of convenience.
> 
> I think `byte` and `char` as the types are a good choice given the way these tag items are described in the JVMS.
> 
>> However, we usually use `int` to represent U1, also called unsigned bytes. See [`DataInput::readUnsignedByte`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/io/DataInput.java#L323) and [`ClassReader::readU1`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/lang/classfile/ClassReader.java#L133). Guess that's why we used `int` for the constants. (Also, note that byte and char are all [erased to int](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/classfile/TypeKind.html#computational-type) in bytecode, so this has little practical effect and that might be why I didn't bother to change these)
> 
> One scenario where the unequal types of the methods and constants _does_ have a practical effect are JVM languages that don't have [binary numeric promotion](https://docs.oracle.com/javase/specs/jls/se23/html/jls-5.html#jls-5.6) for their [numerical equality operators](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.21.1).
> 
> This is the case for Kotlin's [value equality expressions](https://kotlinlang.org/spec/expressions.html#value-equality-expressions). This Kotlin code [would not compile](https://pl.kotl.in/A9D1WDdS8):
> 
> fun isArray(a: AnnotationValue): Boolean {
>     return a.tag() == AnnotationValue.TAG_ARRAY
> }
> 
> Instead you would have to write [this code](https://pl.kotl.in/qSrwSIL39):
> 
> fun isArray(a: AnnotationValue): Boolean {
>     return a.tag() == AnnotationValue.TAG_ARRAY.toChar()
> }

Your example is an exact antipattern from our data-oriented model: we would want users to check the object type with `instanceof` (should be `is` in kotlin) instead of checking these constants.

Yet I think we can consider promoting Constant Pool tag from byte or char, short, or int to represent a u1 in case it goes over 127.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1790591290

From duke at openjdk.org  Mon Oct  7 17:40:42 2024
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 7 Oct 2024 17:40:42 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v9]
In-Reply-To: <IaQ3eFD_4Ki3praZgk4Fny0uCpBFjmsZODAaouRk4pA=.3fc52b8c-7657-4ca9-9a1d-159f1c31f070@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
 <2eVJ0y-JEbIxv6xNHAf5Qk-XTvStANsEnfgIJEkvJqU=.b0e70e97-ecc7-498d-bb67-3e69e15bcfc6@github.com>
 <1z6p_WlO9R1dgc-H29ZjuewTZm04jg-d3YX4is0F8C4=.4405cf0d-484d-4ccc-8022-a37284142545@github.com>
 <8O4cLBgiKtvDB-LbpkdsMs-9DwrQ8i4_Vv9cVOZ7A7g=.46886782-6549-4095-912d-e66872d67d17@github.com>
 <pi2pZ_HwW5fF3OcwOoKAKhjH5r5D0MS0Mca4BkJlcmM=.c9a98dfb-cb75-4449-96ec-02b30c06292d@github.com>
 <IaQ3eFD_4Ki3praZgk4Fny0uCpBFjmsZODAaouRk4pA=.3fc52b8c-7657-4ca9-9a1d-159f1c31f070@github.com>
Message-ID: <KcJAu7R-8apstljbBQunA2RYLhze1-sbBBL5yhcKGL8=.f3dc2338-ea39-424a-a990-7b38a79f6ae0@github.com>

On Mon, 7 Oct 2024 17:07:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> Your example is an exact antipattern from our data-oriented model: we would want users to check the object type with `instanceof` (should be `is` in kotlin) instead of checking these constants.

I'm aware, this was just the first example I could come up with.

> Yet I think we can consider promoting Constant Pool tag from byte or char, short, or int to represent a u1 in case it goes over 127.

Maybe just using `int` everywhere for consistency might be a good option too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1790628903

From duke at openjdk.org  Mon Oct  7 17:42:37 2024
From: duke at openjdk.org (Markus KARG)
Date: Mon, 7 Oct 2024 17:42:37 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <LgPjEgBHegKnqfxDRcLOzxoqcGBEjgnEoA6AD1DXh7Y=.280f7eac-9c00-4366-8298-88297c216760@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
 <odqOItnwT466uvC-KfooM2cZ9WqlHNqSL3_d6wQOJQI=.0a483584-d6a0-4a81-824f-23b8e9205106@github.com>
 <Z8u0xGwDAZ2Wwh-ahLTVdgo4rstXVEhwZisWGi90Chs=.f63b1419-c32d-4f62-b390-db85fcbc67bd@github.com>
 <LgPjEgBHegKnqfxDRcLOzxoqcGBEjgnEoA6AD1DXh7Y=.280f7eac-9c00-4366-8298-88297c216760@github.com>
Message-ID: <XCNXmQEJqiyqo6pfalLW8oLYkfNn3qDEb8s7_M5OxZg=.1d651f67-85a7-43b9-9e94-fb6e87865ad2@github.com>

On Mon, 7 Oct 2024 16:06:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is correct, but then we would keep the reference to the char sequence "forever", without any good reason. This content could be *huge* (and often it is, as `CharSequence` most often is a `StringBuilder` just because the application *wants* to create huge content, and `String`-concatenation would be too costly with *huge* content). In fact, I see this scenario as the top use case for this new API.
>> 
>> Having said that, I would really like to have this field non-final to unlink the reference to the source as soon as possible, implicitly allowing GC to free this unused memory.
>
>> keep the reference to the char sequence "forever"
> 
> Note that this only happens if the `Reader` instance is kept forever; but a `Reader` is supposed to be used and closed and discarded instead of being held indefinitely after closing. If users are bad enough, they can never call `close` and the non-final `cs` is still leaked.
> 
> The right way of GC freeing is to let the GC free the reader and the char sequence together, instead of allowing to free when a client keeps this reader instance erroneously after closing.

I really do see you point, nevertheless I think we should be kind to "bad" users, too. In the end, there is *no* specification which explicitly tells "bad" users that readers are support to be short-living (despite it being rather obvious), while `close` explicitly mentions freeing *all* resources, so it is rather unexpected to keep something past `close`, even for short term. NB: `StringReader` applies the very same behavior, too (using `s` and `str` variables), that's where I copied the code from originally. It is not a big problem for us to have two variables, neither that the name of the variable is `source` (in fact, I do like `source` even more than `cs`, but this is just my personal preference). To sum up, I really dislike the idea to keep the reference for any longer than essentially needed. If it's just about the name of the variable, I could simply switch them if you prefer that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1790631189

From lancea at openjdk.org  Mon Oct  7 18:09:44 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 18:09:44 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v5]
In-Reply-To: <iEKvdtRISrEjyZa876Ak4QuxRUKJFIV7xWMrQLKzwvo=.9068deb1-6062-44e7-969f-c82ec8f4d528@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <iEKvdtRISrEjyZa876Ak4QuxRUKJFIV7xWMrQLKzwvo=.9068deb1-6062-44e7-969f-c82ec8f4d528@github.com>
Message-ID: <EcgEIBc5W5vDYdWnhTpbZevw0lvUospKZbdatN_MZdI=.cf5204ce-5d62-43c9-ada6-966eb3ac10cd@github.com>

On Wed, 2 Oct 2024 00:25:00 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More review comments

Overall,  this looks ok

We will also need an RN which would be good to have available when the CSR is finalized to review

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 322:

> 320: \  -k, --keep-old-files       Do not overwrite existing files.\n\
> 321: \                             If a file with the same name exists in the target\n\
> 322: \                             directory, skip the extraction of that file.\n\

This is OK, but I would probably just  the if the file exists, it will not be overwritten

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21141#pullrequestreview-2352617048
PR Review Comment: https://git.openjdk.org/jdk/pull/21141#discussion_r1790662939

From eirbjo at openjdk.org  Mon Oct  7 18:13:38 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 18:13:38 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
Message-ID: <_BEAFeJzkItGJTnmfGFK_voslIWQzA_AZOT-HnKb_0U=.207a0936-edfa-47fb-9c6b-70631df68474@github.com>

On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s 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 ziperror-deprecation
>  - Simplify the deprecation note by focusing on behavior in the current release
>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>  - Update copyright year
>  - Deprecate java.util.zip.ZipError for removal

As promised in the CSR, this change will be accompanied by a release note. A release note was drafted a while back, but I don't think anyone provided feedback.

Before integrating this change, I would love if someone could take a look at the release note and provide feedback. This way all aspects of this task can be completed:

https://bugs.openjdk.org/browse/JDK-8336843

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2397576675

From lancea at openjdk.org  Mon Oct  7 18:55:42 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 18:55:42 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header
In-Reply-To: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
Message-ID: <6EMLbuhWzkHJGhaDoeU8ZC83xHj1RZykv58mFRGgORI=.76a4c8a0-d164-437a-aeb7-09465f64a000@github.com>

On Mon, 7 Oct 2024 09:13:57 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which adds validation of the 'total entries' value when fetched from the 'ZIP64 End of Central Directory' header.
> 
> We should reject this value under the following conditions:
> 
> 1. It is too large to fit within the specified CEN size (considering each CEN header encodes as at least 46 bytes each)
> 2. It is too large to create the `int[] entries` array safely (max value is `ArraysSupport.SOFT_MAX_ARRAY_LENGTH / 3`)
> 
> I claim that condition 2 here is already implicitly validated by the current maximum CEN size validation. (A CEN encoding such a large number of entries would exceed the maximum CEN size a lot and would already be rejected)
> 
> This change aims to protect the integrity of the implementation against specially crafted ZIP files. No sane ZIP tool will produce such files. 
> 
> Testing:
> 
> This PR adds a test `EndOfCenValidation.shouldRejectBadTotalEntries` which exercises the first condition above.
> 
> ZIP tests run locally. GHA results pending.

Marked as reviewed by lancea (Reviewer).

test/jdk/java/util/zip/ZipFile/EndOfCenValidation.java line 264:

> 262:          */
> 263: 
> 264:         byte[] zipBytes = HexFormat.of().parseHex("""

It might be beneficial to future readers to provide the steps used to create the  hex string in the format you have provided.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21384#pullrequestreview-2352700634
PR Review Comment: https://git.openjdk.org/jdk/pull/21384#discussion_r1790720612

From lancea at openjdk.org  Mon Oct  7 18:58:38 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 18:58:38 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v13]
In-Reply-To: <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>
Message-ID: <I_Jq2GyqoX4dBeAZV0C3_bGvC5BePg-iPyNY9My2MAA=.9c2e09f8-bb40-40bd-a328-ad80a38b46be@github.com>

On Mon, 7 Oct 2024 05:58:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use a fixed locale in the test to prevent failures on environments that are not en_US
>  - add a test to verify extraction to a non-directory fails

Thank you Jai for getting this long outstanding PR across the finish line

looks good to me

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/2752#pullrequestreview-2352707299

From lancea at openjdk.org  Mon Oct  7 19:14:41 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 19:14:41 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v4]
In-Reply-To: <X04m7EGiB5FqVOgVKofwuDFRFL7stUBdGC4Ism8blpg=.9e151c1b-f77f-429a-81ae-4fe210db9539@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <X04m7EGiB5FqVOgVKofwuDFRFL7stUBdGC4Ism8blpg=.9e151c1b-f77f-429a-81ae-4fe210db9539@github.com>
Message-ID: <03Ny-sTsfavVUiMnACGvYS6haib4jhy_Ndrz5z8uxAw=.af9bbc4c-82b0-4083-87ea-b55cef2a2eb2@github.com>

On Sun, 6 Oct 2024 21:45:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
>> 
>> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
>> 
>> 
>> make test TEST=micro:java.util.zip.ZipFile
>> 
>> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
>> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
>> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
>> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
>> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
>> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
>> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
>> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
>> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>>   * = significant
>> 
>> 
>> This PR also address some code duplication in `ZipUtils`.
>> 
>> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zi...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename get64 -> get64S

Hi Claes,

Looks reasonable to me.

thank you for your efforts here

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21377#pullrequestreview-2352737725

From duke at openjdk.org  Mon Oct  7 19:35:10 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 7 Oct 2024 19:35:10 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v32]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <3FoydNfCzRhNL5Fts7M-30uB-QwPJyZq-DkWlF4NVtk=.b28f509b-15f5-4f16-aff5-9b91f6506246@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use log cache of BigInteger

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/8b90da08..12200d55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=30-31

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From lancea at openjdk.org  Mon Oct  7 19:40:38 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 19:40:38 GMT
Subject: RFR: 8341597: ZipFileInflaterInputStream input buffer size uses
 uncompressed size
In-Reply-To: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>
References: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>
Message-ID: <1XmJJZtdJl3vIOigNI3OIEwQNIADPO4ZCrq6kF3hsLU=.1d8b00ec-6896-43bc-9c36-fb93e744e3f6@github.com>

On Sun, 6 Oct 2024 18:02:58 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which proposes to change the input buffer size of `ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP entry instead of the _uncompressed_ size. This saves allocation since buffers will no longer be oversized:
> 
> * The `size` parameter passed to the `ZipFileInflaterInputStream` constructor is passed on to the superclass `InflaterInputStream` where it determines the size of the input buffer. This buffer is used to read compressed data and pass it on to the `Inflater`.
> * `ZipFile:getInputStream` currently looks at the _uncompressed_ size when determining the input buffer size. It should instead use the _compressed_ size, since this buffer is used for compressed, not uncompressed data.
> * The current implementation somewhat mysteriously adds 2 to the uncompressed size. My guess is that this is to allow fitting a two-byte DEFLATE header for empty files (where the uncompressed size is 0 and the compressed size is 2).
> * There is a check for `size <= 0`. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be `>= 2`. I propose we remove this check.
> 
> Performance: A benchmark which measures the cost of opening and closing input streams using `ZipFile::getInputStream` shows a modest improvement of ~5%, consistent with less allocation of unused buffer space.
> 
> Testing: No tests are added in this PR. The `noreg-cleanup` label is added in JBS. GHA testing is currently pending.

On the surface this looks OK.

I couldn't find any historical reason as to why the change was done originally outside of part of the conversion from leaning on JNI.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21379#pullrequestreview-2352785217

From redestad at openjdk.org  Mon Oct  7 19:42:39 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 7 Oct 2024 19:42:39 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v23]
In-Reply-To: <Zb4OZ-X15Gd4lNwrhxlxHabBzzMHdTIE8wjY97NpvaA=.fad1e101-b042-4190-9d71-2c66cf206557@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <Zb4OZ-X15Gd4lNwrhxlxHabBzzMHdTIE8wjY97NpvaA=.fad1e101-b042-4190-9d71-2c66cf206557@github.com>
Message-ID: <SxtGRzBWOir7W1WJa3UOJtVPqCYQlvzvTSCKCeHozQo=.03b1a049-fe10-46c2-a38a-5ff59382e24c@github.com>

On Sat, 5 Oct 2024 16:33:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge error

I took this for a spin and results looks promising. Even a tentative win on the Write.jdkTree microbenchmark. The number of changes is a bit staggering so will take a while to thoroughly review in detail. I might be able to get through it all tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21243#issuecomment-2397739639

From liach at openjdk.org  Mon Oct  7 19:46:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 19:46:37 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <XCNXmQEJqiyqo6pfalLW8oLYkfNn3qDEb8s7_M5OxZg=.1d651f67-85a7-43b9-9e94-fb6e87865ad2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
 <odqOItnwT466uvC-KfooM2cZ9WqlHNqSL3_d6wQOJQI=.0a483584-d6a0-4a81-824f-23b8e9205106@github.com>
 <Z8u0xGwDAZ2Wwh-ahLTVdgo4rstXVEhwZisWGi90Chs=.f63b1419-c32d-4f62-b390-db85fcbc67bd@github.com>
 <LgPjEgBHegKnqfxDRcLOzxoqcGBEjgnEoA6AD1DXh7Y=.280f7eac-9c00-4366-8298-88297c216760@github.com>
 <XCNXmQEJqiyqo6pfalLW8oLYkfNn3qDEb8s7_M5OxZg=.1d651f67-85a7-43b9-9e94-fb6e87865ad2@github.com>
Message-ID: <kTGWzSGXMXt_iNPxnTwqe1sLfMRinw2iF89DmuEp2yc=.b9fe48a9-5c78-44f4-8f74-9775037f40cf@github.com>

On Mon, 7 Oct 2024 17:39:33 GMT, Markus KARG <duke at openjdk.org> wrote:

>>> keep the reference to the char sequence "forever"
>> 
>> Note that this only happens if the `Reader` instance is kept forever; but a `Reader` is supposed to be used and closed and discarded instead of being held indefinitely after closing. If users are bad enough, they can never call `close` and the non-final `cs` is still leaked.
>> 
>> The right way of GC freeing is to let the GC free the reader and the char sequence together, instead of allowing to free when a client keeps this reader instance erroneously after closing.
>
> I really do see you point, nevertheless I think we should be kind to "bad" users, too. In the end, there is *no* specification which explicitly tells "bad" users that readers are support to be short-living (despite it being rather obvious), while `close` explicitly mentions freeing *all* resources, so it is rather unexpected to keep something past `close`, even for short term. NB: `StringReader` applies the very same behavior, too (using `s` and `str` variables), that's where I copied the code from originally. It is not a big problem for us to have two variables, neither that the name of the variable is `source` (in fact, I do like `source` even more than `cs`, but this is just my personal preference). To sum up, I really dislike the idea to keep the reference for any longer than essentially needed. If it's just about the name of the variable, I could simply switch them if you prefer that.

On a linux x64 build:

./javap -p java.io.Reader$2
Compiled from "Reader.java"
class java.io.Reader$2 extends java.io.Reader {
  private final int length;
  private java.lang.CharSequence cs;
  private int next;
  private int mark;
  final java.lang.CharSequence val$source;
  java.io.Reader$2(java.lang.CharSequence);
  private void ensureOpen() throws java.io.IOException;
  public int read() throws java.io.IOException;
  public int read(char[], int, int) throws java.io.IOException;
  public long skip(long) throws java.io.IOException;
  public boolean ready() throws java.io.IOException;
  public boolean markSupported();
  public void mark(int) throws java.io.IOException;
  public void reset() throws java.io.IOException;
  public void close();
}


The javap in the built binaries of this patch shows that this anonymous class already keeps the `CharSequence val$source` in a final field; therefore, your setting the `cs` field to `null` will not help GC or anything of that sort.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1790782348

From duke at openjdk.org  Mon Oct  7 19:50:37 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 7 Oct 2024 19:50:37 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
Message-ID: <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnrwS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>

On Fri, 4 Oct 2024 22:42:18 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti Though, it's also true that if I want to do astronomical calculations, I probably have a machine that allows me to do so, and so I'd like to be able to make the most of it...
>
> `BigDecimal` was not designed to do astronomical computations. One would probably use other libraries for that, e.g., [GMP](https://gmplib.org/) and would not be interested too much in "stripping trailing zeros".
> The focus of this class is mainly commercial applications, where decimal arithmetic is sometimes mandated by regulators.
> 
> So I'd expect that most usages, for example SQL or commercial application workloads, will process numbers with a few dozens of digits, maybe sometimes some hundreds digits for intermediate results. So I think that accelerating for these sizes makes the most practical sense.
> 
> With modest memory and CPU costs, I think even one million digits or so might be processed reasonably fast.
> My point is that there's room for improvement in these range of sizes, but perhaps not for larger ones.
> 
> More importantly, though, I'd like to avoid one single computation to affect the resident memory footprint of a JVM instance for its entire lifetime.

@rgiulietti FYI, I have found that `BigInteger` has already a cache for the repeated squares that uses in radix string conversion, and it is provided by the method `BigInteger.getRadixConversionCache(int radix, int exponent)`. Although, I don't know if it would be a good idea to use it, because it computes all the squares up to `radix^(2^exponent)`, and this may not be necessary but could cost a lot of running time and memory if the number to strip is very large...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1790787304

From eirbjo at openjdk.org  Mon Oct  7 19:54:15 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 19:54:15 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header [v2]
In-Reply-To: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
Message-ID: <kZikDHV8049i9eAoalXCWQYNDkQxhMcIdU1AtfaXotY=.aae0098a-7371-432d-85f8-c4c87aaee66c@github.com>

> Please review this PR which adds validation of the 'total entries' value when fetched from the 'ZIP64 End of Central Directory' header.
> 
> We should reject this value under the following conditions:
> 
> 1. It is too large to fit within the specified CEN size (considering each CEN header encodes as at least 46 bytes each)
> 2. It is too large to create the `int[] entries` array safely (max value is `ArraysSupport.SOFT_MAX_ARRAY_LENGTH / 3`)
> 
> I claim that condition 2 here is already implicitly validated by the current maximum CEN size validation. (A CEN encoding such a large number of entries would exceed the maximum CEN size a lot and would already be rejected)
> 
> This change aims to protect the integrity of the implementation against specially crafted ZIP files. No sane ZIP tool will produce such files. 
> 
> Testing:
> 
> This PR adds a test `EndOfCenValidation.shouldRejectBadTotalEntries` which exercises the first condition above.
> 
> ZIP tests run locally. GHA results pending.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Remove trailing whitespace
 - Use a ZIP64 test vector which may be reproduced using InfoZIP

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21384/files
  - new: https://git.openjdk.org/jdk/pull/21384/files/8e8cb818..ccfa56e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21384&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21384&range=00-01

  Stats: 110 lines in 1 file changed: 14 ins; 25 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/21384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21384/head:pull/21384

PR: https://git.openjdk.org/jdk/pull/21384

From eirbjo at openjdk.org  Mon Oct  7 19:54:15 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 19:54:15 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header [v2]
In-Reply-To: <6EMLbuhWzkHJGhaDoeU8ZC83xHj1RZykv58mFRGgORI=.76a4c8a0-d164-437a-aeb7-09465f64a000@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
 <6EMLbuhWzkHJGhaDoeU8ZC83xHj1RZykv58mFRGgORI=.76a4c8a0-d164-437a-aeb7-09465f64a000@github.com>
Message-ID: <cAiC5onB9VN0u3F1opofO_HXBrmZ8XkEaNfTqw0iqBA=.f756e15d-70df-4593-b464-358ac2d3551c@github.com>

On Mon, 7 Oct 2024 18:51:52 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> It might be beneficial to future readers to provide the steps used to create the hex string in the format you have provided.

The test vector was crafted using a ZIP test library not available in OpenJDK.

I have replaced that with a test vector which is easily reproduced using InfoZIP. Take a look at the updated test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21384#discussion_r1790790630

From eirbjo at openjdk.org  Mon Oct  7 20:02:10 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 7 Oct 2024 20:02:10 GMT
Subject: RFR: 8340814: ZipFileInflaterInputStream should release its Inflater
 after observing EOF
Message-ID: <Y22r_IgycB-aKfqOrgoneP-1QycfJpg3exIN17ucCDI=.c1588a33-3f3a-4f37-907c-e44f02a3388f@github.com>

Please consider this PR which makes `ZipFileInflaterInputStream` release its `Inflater` instance back to the pool when observing that the stream has been fully consumed.

This is motivated by the following observations:

* After a `ZipFileInflaterInputStream` has reached the end of stream, its `Inflater` instance no longer does useful work.
* Obtaining an input stream via `ZipFile::getInputStream` without properly closing it is probably common. Obtaining it without fully consuming it is probably more rare. (Something like `classLoader.getInputStream(entry).readAllBytes()` is probably common)
* While GC will eventually release the `Inflater` when the `Cleaner` closes the stream, this will only happen at some later point in time. In the meantime, `ZipFile::getInputStream` may produce many new `Inflater` instances. These will all be released to the pool once GC eventually catches up.
* Once an `Inflater` is released to to pool, it will stay there for the lifetime of the `ZipFile`
* The lifetime of a `ZipFile` may often be as long as the application (consider class loaders).

This PR suggests the following changes:

* Rename the existing field `ZipFileInflaterInputStream.eof` to `compressedEof`. (This tracks the EOF of the filtered input stream)
* Add a new field  `ZipFileInflaterInputStream.eof` to track the EOF of uncompressed data.
* Override  `ZipFileInflaterInputStream.read(byte[] b, int off, int len)` to detect the EOF of uncompressed data and release the `Inflater` instance back to the pool when it is no longer needed.
* To protect the `Inflater` instance from being used after being released and reset, the following updates are needed:
  * `ZipFileInflaterInputStream.read` must check if EOF has been reached  but that the stream has not yet been closed. In this case, EOF should be returned.
  * Similarly, `ZipFileInflaterInputStream.available` needs an update to return 0 if EOF has been detected.

The PR adds a test `ReleaseInflaterOnEOF` which verifies that all fully consumed input streams are backed by the same `Inflater` instance.

This PR was inspired by JDK-7031076 and this discussion: https://mail.openjdk.org/pipermail/core-libs-dev/2011-March/006341.html

-------------

Commit messages:
 - Add comment justifying the override of InputStream.read
 - Use correct copyright year for a new test
 - Make sure the ZipFile is closed using TwR
 - Call transferTo on the correct stream instance
 - Make ZipFileInflaterInputStream release its Inflater to the pool when observing that the stream is fully consumed (EOF)

Changes: https://git.openjdk.org/jdk/pull/21157/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21157&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340814
  Stats: 139 lines in 2 files changed: 135 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21157/head:pull/21157

PR: https://git.openjdk.org/jdk/pull/21157

From lancea at openjdk.org  Mon Oct  7 20:02:35 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 20:02:35 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header [v2]
In-Reply-To: <kZikDHV8049i9eAoalXCWQYNDkQxhMcIdU1AtfaXotY=.aae0098a-7371-432d-85f8-c4c87aaee66c@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
 <kZikDHV8049i9eAoalXCWQYNDkQxhMcIdU1AtfaXotY=.aae0098a-7371-432d-85f8-c4c87aaee66c@github.com>
Message-ID: <fbFrO59NPRGGWQHDrlTBjX71VP0MwP6MR7H_E-8LERY=.4889dece-ff3b-46cd-a1f0-235fb12be84b@github.com>

On Mon, 7 Oct 2024 19:54:15 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which adds validation of the 'total entries' value when fetched from the 'ZIP64 End of Central Directory' header.
>> 
>> We should reject this value under the following conditions:
>> 
>> 1. It is too large to fit within the specified CEN size (considering each CEN header encodes as at least 46 bytes each)
>> 2. It is too large to create the `int[] entries` array safely (max value is `ArraysSupport.SOFT_MAX_ARRAY_LENGTH / 3`)
>> 
>> I claim that condition 2 here is already implicitly validated by the current maximum CEN size validation. (A CEN encoding such a large number of entries would exceed the maximum CEN size a lot and would already be rejected)
>> 
>> This change aims to protect the integrity of the implementation against specially crafted ZIP files. No sane ZIP tool will produce such files. 
>> 
>> Testing:
>> 
>> This PR adds a test `EndOfCenValidation.shouldRejectBadTotalEntries` which exercises the first condition above.
>> 
>> ZIP tests run locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove trailing whitespace
>  - Use a ZIP64 test vector which may be reproduced using InfoZIP

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21384#pullrequestreview-2352826338

From liach at openjdk.org  Mon Oct  7 20:13:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 20:13:38 GMT
Subject: RFR: 8341581: Optimize BytecodeHelpers validate slot
In-Reply-To: <N4SW9Z6F7Ea0KnaCQcx_heBeEdbwBu8P0MWY6uBkEu8=.8f26f859-71c6-4f91-84a2-be63ea6f238a@github.com>
References: <N4SW9Z6F7Ea0KnaCQcx_heBeEdbwBu8P0MWY6uBkEu8=.8f26f859-71c6-4f91-84a2-be63ea6f238a@github.com>
Message-ID: <YX5Bhhx7BjPW3HO2qdMaP__kFspbFITi83rpKegYEu0=.e29c6f3d-0124-4bdf-8db5-f3f27df037df@github.com>

On Fri, 4 Oct 2024 23:49:42 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Use `slot & ~0xFF == 0` instead of `(slot & 0xFF) == slot` to reduce codeSize.
> 
> The following is a comparison of the bytecode before and after the modification. It can be seen that using `slot & ~0xFF == 0` will reduce one iload operation.
> 
> 
> // (slot & 0xFF) == slot
> 56: iload_0
> 57: sipush        255
> 60: iand
> 61: iload_0
> 62: if_icmpne     71
> 
> // slot & ~0xFF == 0
> 56: iload_0
> 57: sipush        -256
> 60: iand
> 61: ifne          70

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21367#pullrequestreview-2352845364

From liach at openjdk.org  Mon Oct  7 20:13:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Oct 2024 20:13:39 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v23]
In-Reply-To: <Zb4OZ-X15Gd4lNwrhxlxHabBzzMHdTIE8wjY97NpvaA=.fad1e101-b042-4190-9d71-2c66cf206557@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <Zb4OZ-X15Gd4lNwrhxlxHabBzzMHdTIE8wjY97NpvaA=.fad1e101-b042-4190-9d71-2c66cf206557@github.com>
Message-ID: <EEOCB_T_t8kH3Di9qvUIPG2tEHQQ2NYoJ29Pr1ytTnM=.c4a4169c-761d-47cb-aa55-56a37b7be9c1@github.com>

On Sat, 5 Oct 2024 16:33:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge error

Everything else looks good.

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 78:

> 76:     private static final LocalVariableType[] EMPTY_LOCAL_VARIABLE_TYPE_ARRAY = new LocalVariableType[0];
> 77:     private static final AbstractPseudoInstruction.ExceptionCatchImpl[] EMPTY_HANDLER_ARRAY = new AbstractPseudoInstruction.ExceptionCatchImpl[0];
> 78:     private static final DeferredLabel[] EMPTY_DEFERRED_LABEL_ARRAY = new DeferredLabel[0];

You used `{}` for conciseness in `DirectClassBuilder`. Maybe use `{}` here as well?

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 507:

> 505:         } else {
> 506:             bytecodesBufWriter.writeU1U1U2(WIDE, bytecode, slot);
> 507:         }

Can we do:

        if ((slot & ~0xFF) == 0)
            bytecodesBufWriter.writeU1U1(bytecode, slot);
        else if ((slot & ~0xFFFF) == 0)
            bytecodesBufWriter.writeU1U1U2(WIDE, bytecode, slot);
        else
            throw BytecodeHelpers.slotOutOfBounds(slot);

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 989:

> 987:     @Override
> 988:     public CodeBuilder aload(int slot) {
> 989:         if (slot >= 0 && slot <= 3) {

Should we use `if ((slot & ~3) != 0)` for shorter bytecode? #21367

-------------

PR Review: https://git.openjdk.org/jdk/pull/21243#pullrequestreview-2352814559
PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1790792835
PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1790810567
PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1790804586

From mcimadamore at openjdk.org  Mon Oct  7 21:01:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 21:01:35 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <m_3Tinr34oMR8vH3TgpoL07mWMKqKPUgS3Sda56HrJ8=.fb4bca07-9f81-4b06-a99e-187bfce95163@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
 <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
 <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>
 <TZnn83hm2GBJtvMeO0tHi6NuToWvy0AJ3PiHDZlXScw=.671a271e-1f2e-4b33-88f4-0a73b035e793@github.com>
 <HUUa4UIjDXZvtksFPFVRg2kp8u2dZLyA-nC_9H2e3mk=.7bf8dc39-f3d1-499f-902a-112443229934@github.com>
 <SopH0a9bp3Xi87FhX6SX9WF4Jg8lcvL3ykD1957yJ-Y=.045e878e-176d-42f4-b7a5-c00f1f39f618@github.com>
 <m_3Tinr34oMR8vH3TgpoL07mWMKqKPUgS3Sda56HrJ8=.fb4bca07-9f81-4b06-a99e-187bfce95163@github.com>
Message-ID: <rpTdBp-jZdnj8cASgWkq7GCVsbsfuS7ppDOIoR61OQI=.ccfc18db-77c2-41cc-a44c-b5eb1a1fdeed@github.com>

On Mon, 7 Oct 2024 15:48:46 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> > Does this restacking make things clearer?
> 
> I really like this new definition.
> 
> To what extent do these rules determine the compatibility of FFM calling conventions with the C calling convention? If I understand correctly, all layouts accepted by the linker must comply with the C calling convention, but linker must not allow all the cases that C allows?

I think the new rules define a bunch of rules that all layouts that model C type declarations should follow - but do so in broad strokes, still allowing the linker implementation to have the final say on what is and is not accepted.

The main problem with the current approach is that we are trying to define all C layouts in a platform agnostic fashion. But, as we discovered more and more over the last week or so, a lot of things which seemed "sensible" back when we wrote the javadoc, in reality rely on this or that platform/compiler assumption. And, given that the support for packed structs was already linker-dependent, it seems to make more sense to just say which things are "clearly wrong" (and then say that linker can reject more if it so wishes), rather than say which ones are "clearly correct" (and then say that linker can support more if it wants). It's a subtle change, but one that doesn't send us spinning trying to mimic complex C rules in where certain layouts might be allowed. For instance, the C standard disallows empty arrays. But empty arrays can be used as the last field of a struct (flexible array member) but only if they are preceded by some other field (and only if the struct is not nested in som
 e other struct)... as you can see, things get hairy pretty quickly, so I think it's probably better to say which general shape linker layouts should adhere to, while still leaving the linker a lot of say in what is/not correct.

> 
> I think it might be worth renaming the pull request and perhaps the issue to reflect that what's going on has moved well beyond the original bug report.

Agreed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2397884234

From mcimadamore at openjdk.org  Mon Oct  7 21:07:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 21:07:38 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v6]
In-Reply-To: <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <GIjvq9l0CvL1RALZtKDw-dmf94dQkp-_8IXSgsRoOtU=.359dccda-de8d-451e-8723-c6d0ba831347@github.com>
Message-ID: <EAizkBhsJBCBPaefX6OSy9-sddDsnO1WpX_8uE8FBMU=.5ac9a51e-c4a6-432a-a742-7eeae3f30b71@github.com>

On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix paths to links

> I created a sub-PR for streamlining integration of this feature into JavaDoc code: [mcimadamore#22](https://github.com/mcimadamore/jdk/pull/22)

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2397893723

From mcimadamore at openjdk.org  Mon Oct  7 21:12:57 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 7 Oct 2024 21:12:57 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v7]
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <BDXWLTMbZmhEfh_Te0Oks1R_enSv3nCcLG5WR20Mmiw=.d3748255-4fad-4954-b36d-659cea304f8b@github.com>

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #22 from hns/restricted_better_javadoc
   
   Only link restricted method doc-file if it is available
 - Only link restricted method doc-file if it is available

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21067/files
  - new: https://git.openjdk.org/jdk/pull/21067/files/e2326094..af0a13c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=05-06

  Stats: 34 lines in 4 files changed: 16 ins; 6 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21067/head:pull/21067

PR: https://git.openjdk.org/jdk/pull/21067

From redestad at openjdk.org  Mon Oct  7 21:42:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 7 Oct 2024 21:42:23 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v23]
In-Reply-To: <EEOCB_T_t8kH3Di9qvUIPG2tEHQQ2NYoJ29Pr1ytTnM=.c4a4169c-761d-47cb-aa55-56a37b7be9c1@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <Zb4OZ-X15Gd4lNwrhxlxHabBzzMHdTIE8wjY97NpvaA=.fad1e101-b042-4190-9d71-2c66cf206557@github.com>
 <EEOCB_T_t8kH3Di9qvUIPG2tEHQQ2NYoJ29Pr1ytTnM=.c4a4169c-761d-47cb-aa55-56a37b7be9c1@github.com>
Message-ID: <EmV7cfyGoNgEjLEWytRxqnILMstVg1fGfpNgdLDblsU=.2ef10e0d-20bb-4260-826d-c5b399912a53@github.com>

On Mon, 7 Oct 2024 20:03:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix merge error
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 989:
> 
>> 987:     @Override
>> 988:     public CodeBuilder aload(int slot) {
>> 989:         if (slot >= 0 && slot <= 3) {
> 
> Should we use `if ((slot & ~3) != 0)` for shorter bytecode? #21367

While fun, I wonder if such bit-fiddling optimizations obfuscate the code more than it helps performance. Would be good with some supporting evidence that it 1) helps interpreted performance and 2) that all JITs recognize and optimize this pattern well and without surprises.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1790909547

From henryjen at openjdk.org  Mon Oct  7 21:45:00 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 7 Oct 2024 21:45:00 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v6]
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <rdUeSQL1qOClVlCTWKO6kPmnx68R1ZrJuID81b_5BeY=.c4f04a86-8f38-4349-b887-7c2dd3d8868b@github.com>

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Adapt review suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21141/files
  - new: https://git.openjdk.org/jdk/pull/21141/files/1b7a1f99..f24d965c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21141&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21141/head:pull/21141

PR: https://git.openjdk.org/jdk/pull/21141

From lancea at openjdk.org  Mon Oct  7 22:01:17 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 7 Oct 2024 22:01:17 GMT
Subject: RFR: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files [v6]
In-Reply-To: <rdUeSQL1qOClVlCTWKO6kPmnx68R1ZrJuID81b_5BeY=.c4f04a86-8f38-4349-b887-7c2dd3d8868b@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
 <rdUeSQL1qOClVlCTWKO6kPmnx68R1ZrJuID81b_5BeY=.c4f04a86-8f38-4349-b887-7c2dd3d8868b@github.com>
Message-ID: <mftb_ZUFfxVfm-XslwemCN6f7wnshXgOFYPnaJimlDo=.cc8ca817-d343-487c-b291-e2706dbb8b11@github.com>

On Mon, 7 Oct 2024 21:45:00 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapt review suggestion

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21141#pullrequestreview-2352992128

From mchung at openjdk.org  Mon Oct  7 22:23:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 7 Oct 2024 22:23:59 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v3]
In-Reply-To: <2xTd_J60NVwLjWFUeWL4AIrVSst8J04M2ObOHIvWd68=.feae34e2-67f2-4087-bbe3-3f11251c3795@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <2xTd_J60NVwLjWFUeWL4AIrVSst8J04M2ObOHIvWd68=.feae34e2-67f2-4087-bbe3-3f11251c3795@github.com>
Message-ID: <_vUBAbj1W8GPLiy3aDJcGhswLe-ztMH--Cqpkzzu8JQ=.51d8d3a0-895a-44ef-87f9-1dd70abf441e@github.com>

On Mon, 7 Oct 2024 07:03:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's suggestion - retain old text plus add a new deprecation note

src/java.scripting/share/classes/module-info.java line 33:

> 31:  * that supports executing JavaScript and other languages if its corresponding
> 32:  * script engine is installed.
> 33:  * <p> The {@code jrunscript} tool is deprecated for removal since JDK 24

I think "since JDK 24" can be dropped as not needed and consistent with other deprecation message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21380#discussion_r1790949903

From sspitsyn at openjdk.org  Mon Oct  7 22:32:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Oct 2024 22:32:55 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation related
 methods
Message-ID: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>

This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
Please, see a fix description in the first comment.

Testing:
 - Verified with new test `vthread/CheckHiddenFrames`
 - Mach5 tiers 1-6 are passed

-------------

Commit messages:
 - fix one more place with trailing spaces
 - fix trailing spaces
 - add new test coverage with  vthread/CheckHiddenFrames
 - 8341273: JVMTI is not properly hiding some continuation related methods

Changes: https://git.openjdk.org/jdk/pull/21397/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341273
  Stats: 233 lines in 7 files changed: 210 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From sspitsyn at openjdk.org  Mon Oct  7 22:32:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Oct 2024 22:32:55 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <p7k__WSzVED_67foMGXVosUeTO_oPgQEcTjd6D4vPiY=.e5fd7e5a-12c4-4d47-8757-0c23085d7ec6@github.com>

On Mon, 7 Oct 2024 22:03:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

The frames which are in VTMS transition should not be visible to the JVMTI agents including debug agent because the thread identity can be incorrect. The JVMTI events are not posted when `java_thread->is_in_VTMS_transition() == true`.
All the JVMTI functions returning stack related info do skip frames that are in transition. The hiding mechanism is using the annotation `@JvmtiMountTransition` to mark the `notifyJvmti*` methods and the bit `java_thread->is_in_VTMS_transition()`.
It occurred that the methods `yield()` and `yield0()` can be present in stack trace of an unmounted virtual threads.
The bit `java_thread->is_in_VTMS_transition() ` is not set in such a case.
The fix is to add the annotation `@JvmtiMountTransition` to the methods `yield()` and `yield0()` and correct the frames skipping mechanism to account for such frames as well.
The update also includes:
 - fix in one of the `JvmtiHandshake::execute()` functions which is needed for better stability and safety
 - tweak in the test which expects frames with `yield()` and `yield0()` methods to be present at the top

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2398025342

From swen at openjdk.org  Mon Oct  7 22:54:24 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 7 Oct 2024 22:54:24 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v24]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <xQZk_VHNGcOM2rfbgu1jNi0QpQtIZGjFhtXvHq1Slq8=.0ba2be55-a510-46c9-b8b6-de0fea9cefa3@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  suggestion from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/0bcedf85..c6e4114c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=22-23

  Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Mon Oct  7 23:33:01 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 7 Oct 2024 23:33:01 GMT
Subject: Integrated: 8341581: Optimize BytecodeHelpers validate slot
In-Reply-To: <N4SW9Z6F7Ea0KnaCQcx_heBeEdbwBu8P0MWY6uBkEu8=.8f26f859-71c6-4f91-84a2-be63ea6f238a@github.com>
References: <N4SW9Z6F7Ea0KnaCQcx_heBeEdbwBu8P0MWY6uBkEu8=.8f26f859-71c6-4f91-84a2-be63ea6f238a@github.com>
Message-ID: <QDlh9MaFW7yxBcIGibV1UKWOSrCbwF13DhtewzoRXLE=.ee6b5a5e-ff84-4fa5-ab39-166ac7233aa7@github.com>

On Fri, 4 Oct 2024 23:49:42 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Use `slot & ~0xFF == 0` instead of `(slot & 0xFF) == slot` to reduce codeSize.
> 
> The following is a comparison of the bytecode before and after the modification. It can be seen that using `slot & ~0xFF == 0` will reduce one iload operation.
> 
> 
> // (slot & 0xFF) == slot
> 56: iload_0
> 57: sipush        255
> 60: iand
> 61: iload_0
> 62: if_icmpne     71
> 
> // slot & ~0xFF == 0
> 56: iload_0
> 57: sipush        -256
> 60: iand
> 61: ifne          70

This pull request has now been integrated.

Changeset: d996ca86
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d996ca863deef50ba7c1c8878cc4c202fa1a9d6b
Stats:     26 lines in 1 file changed: 0 ins; 0 del; 26 mod

8341581: Optimize BytecodeHelpers validate slot

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21367

From lmesnik at openjdk.org  Tue Oct  8 00:13:58 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 8 Oct 2024 00:13:58 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>

On Mon, 7 Oct 2024 22:03:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Changes requested by lmesnik (Reviewer).

src/hotspot/share/prims/jvmtiEnvBase.cpp line 691:

> 689: 
> 690:   if (is_virtual || jt->is_in_VTMS_transition()) { // filter out pure continuations
> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);

Wouldn't be easier to split method `check_and_skip_hidden_frames` to skip_yeilds and skip_transition frames? 
BTW Also it is unclear shouldn't the `@Hidden` methods be skipped from all jvmti frame streams?

src/hotspot/share/prims/jvmtiEnvBase.cpp line 2009:

> 2007:   bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
> 2008: 
> 2009:   // Target can be virtual or platform thread.

Can you please explain in comment why is it needed to disable all threads for platform target thread.

test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 25:

> 23: 
> 24: /*
> 25:  * @test id=virtual

Having 'id=virtual' not needed and might confuse people. They expect to have other test variations for platform.

test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 32:

> 30: 
> 31: public class CheckHiddenFrames {
> 32:     private static final String AGENT_LIB = "CheckHiddenFrames";

It is not used?

test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 43:

> 41: 
> 42:     public static void main(String[] args) throws Exception {
> 43:         Thread thread = Thread.ofVirtual().unstarted(CheckHiddenFrames::test);

You can use 
startVirtualThread
to save one line.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21397#pullrequestreview-2353060666
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1791023030
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1791008060
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1790967726
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1790968113
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1790966876

From swen at openjdk.org  Tue Oct  8 01:08:01 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 01:08:01 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v4]
In-Reply-To: <X04m7EGiB5FqVOgVKofwuDFRFL7stUBdGC4Ism8blpg=.9e151c1b-f77f-429a-81ae-4fe210db9539@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <X04m7EGiB5FqVOgVKofwuDFRFL7stUBdGC4Ism8blpg=.9e151c1b-f77f-429a-81ae-4fe210db9539@github.com>
Message-ID: <Ai_e_kWlBtk2rMemknK-ng_5YJF7zC6QrtPkzNyJcos=.164c316f-e362-4184-afc2-4da7ef092ad1@github.com>

On Sun, 6 Oct 2024 21:45:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
>> 
>> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
>> 
>> 
>> make test TEST=micro:java.util.zip.ZipFile
>> 
>> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
>> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
>> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
>> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
>> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
>> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
>> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
>> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
>> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
>> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
>> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>>   * = significant
>> 
>> 
>> This PR also address some code duplication in `ZipUtils`.
>> 
>> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zi...
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename get64 -> get64S

src/java.base/share/classes/java/util/zip/ZipUtils.java line 173:

> 171:      * The bytes are assumed to be in Intel (little-endian) byte order.
> 172:      */
> 173:     public static final int get16(byte[] b, int off) {

Can JIT automatically perform MergeStore here? If JIT can automatically perform MergeStore without using Unsafe, many scenarios will benefit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1791050224

From liach at openjdk.org  Tue Oct  8 01:13:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 01:13:37 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - class or interface descriptor renamed for clarity
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Cleanup after merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Compile error
 - Redundant import
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - 8338544: Dedicated Array class descriptor implementation

-------------

Changes: https://git.openjdk.org/jdk/pull/20665/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=01
  Stats: 795 lines in 17 files changed: 428 ins; 239 del; 128 mod
  Patch: https://git.openjdk.org/jdk/pull/20665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20665/head:pull/20665

PR: https://git.openjdk.org/jdk/pull/20665

From liach at openjdk.org  Tue Oct  8 01:16:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 01:16:59 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v4]
In-Reply-To: <Ai_e_kWlBtk2rMemknK-ng_5YJF7zC6QrtPkzNyJcos=.164c316f-e362-4184-afc2-4da7ef092ad1@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <X04m7EGiB5FqVOgVKofwuDFRFL7stUBdGC4Ism8blpg=.9e151c1b-f77f-429a-81ae-4fe210db9539@github.com>
 <Ai_e_kWlBtk2rMemknK-ng_5YJF7zC6QrtPkzNyJcos=.164c316f-e362-4184-afc2-4da7ef092ad1@github.com>
Message-ID: <K51df1JMSuUjvrigHS6mlQQ7y7ggTMlL6m4w8FAu1F0=.d32abe25-93b4-45cb-9d6e-9d641e189f25@github.com>

On Tue, 8 Oct 2024 01:05:14 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename get64 -> get64S
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 173:
> 
>> 171:      * The bytes are assumed to be in Intel (little-endian) byte order.
>> 172:      */
>> 173:     public static final int get16(byte[] b, int off) {
> 
> Can JIT automatically perform MergeStore here? If JIT can automatically perform MergeStore without using Unsafe, many scenarios will benefit.

Unfortunately we only have merge store for writing to arrays; no merge load when we are reading from arrays.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1791054849

From liach at openjdk.org  Tue Oct  8 01:27:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 01:27:00 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <N1OgqEd8yYslRfcJah8ARN45mCGOLPFMKsbJ_oF6FV0=.5748000c-f279-418a-96de-a32fc0fc480c@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <N1OgqEd8yYslRfcJah8ARN45mCGOLPFMKsbJ_oF6FV0=.5748000c-f279-418a-96de-a32fc0fc480c@github.com>
Message-ID: <L2ES-QqWw2XDgawEfUhibfYgzxcALO84ghcizb0QMBg=.3d17d29c-f3d1-49c7-ae22-4f3142aab2a4@github.com>

On Fri, 4 Oct 2024 18:08:53 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 pull request now contains nine commits:
>> 
>>  - class or interface descriptor renamed for clarity
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>>  - Cleanup after merge
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>>  - Compile error
>>  - Redundant import
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>>  - 8338544: Dedicated Array class descriptor implementation
>
> Nice cleanup! I'm just not really sure about the new subtype relationship (see inline comment)

@JornVernee I have updated the implementation class name and the factories for clarity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20665#issuecomment-2398408789

From liach at openjdk.org  Tue Oct  8 01:27:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 01:27:01 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <IQcb7ziiEnShoto3oMu1WjHcDUDPuMQ5_lM3VODIi9o=.9f762441-e078-410e-bb1a-95260af63de0@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <mFWB4NbqeDN7VsWr2pFMq3mYlx-Pm1Hjh7OkLLkugJg=.a0597e0b-c55c-414a-a429-7da7866ee62e@github.com>
 <gnGD55EqH3a5xpN5TPdf1zfMLg7VDUxMu-iglw0NMBU=.8ef4b834-562d-45ee-86e4-9f34da999a12@github.com>
 <IQcb7ziiEnShoto3oMu1WjHcDUDPuMQ5_lM3VODIi9o=.9f762441-e078-410e-bb1a-95260af63de0@github.com>
Message-ID: <D2vdYEM8PocZDY5vUsxrB6T_E7xc5tgmN0nSIZ-eJm4=.624522cc-599b-49ad-b9d9-a77c4a1547e7@github.com>

On Wed, 25 Sep 2024 20:00:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch already has a CSR for trivial signature changes. The real difficulty lies in how we should name our new array class descriptors, `Object_array` or `ObjectArray` or what else?
>
> That said, can you leave a quick review on CSR https://bugs.openjdk.org/browse/JDK-8340963 too?

I think I will do this in another patch that adds it to `ConstantDescs` - there's a place in `ConstantDescs` that could have used it, but if I put it in `ConstantUtils` I fear we are at risk of circular initialization dependencies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1791060061

From jpai at openjdk.org  Tue Oct  8 01:36:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 01:36:39 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v4]
In-Reply-To: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
Message-ID: <CsrcEvhoyJWWa4M_xLPfcgUL7K2Lbb-hv_kwW3PBYzE=.b2540caf-4880-4e76-a4bd-7ec1d59e6baa@github.com>

> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
> 
> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
> 
> 
> $> jrunscript
> script engine for language js can not be found
> 
> 
> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Mandy's review - remove since JDK 24

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21380/files
  - new: https://git.openjdk.org/jdk/pull/21380/files/5f2c4a5f..b045f298

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21380&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21380&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21380/head:pull/21380

PR: https://git.openjdk.org/jdk/pull/21380

From jpai at openjdk.org  Tue Oct  8 01:36:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 01:36:39 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v3]
In-Reply-To: <_vUBAbj1W8GPLiy3aDJcGhswLe-ztMH--Cqpkzzu8JQ=.51d8d3a0-895a-44ef-87f9-1dd70abf441e@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <2xTd_J60NVwLjWFUeWL4AIrVSst8J04M2ObOHIvWd68=.feae34e2-67f2-4087-bbe3-3f11251c3795@github.com>
 <_vUBAbj1W8GPLiy3aDJcGhswLe-ztMH--Cqpkzzu8JQ=.51d8d3a0-895a-44ef-87f9-1dd70abf441e@github.com>
Message-ID: <nvCCNs-8aadzSxgvBKetVxg2DzWK9fgPM8qEDXdkrnw=.a592afe9-95e6-4cdc-898d-5f9b1d9fe3cc@github.com>

On Mon, 7 Oct 2024 22:21:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Alan's suggestion - retain old text plus add a new deprecation note
>
> src/java.scripting/share/classes/module-info.java line 33:
> 
>> 31:  * that supports executing JavaScript and other languages if its corresponding
>> 32:  * script engine is installed.
>> 33:  * <p> The {@code jrunscript} tool is deprecated for removal since JDK 24
> 
> I think "since JDK 24" can be dropped as not needed and consistent with other deprecation message.

Hello Mandy, I've now updated the PR to remove that part.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21380#discussion_r1791064199

From cstein at openjdk.org  Tue Oct  8 05:26:08 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 8 Oct 2024 05:26:08 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v13]
In-Reply-To: <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <SUv_LP_LiRNNYUTA0Q5hJxYk9xEjAkVQqUa33lcg6WE=.0aa18d89-e7dc-4f4c-85f0-2474372d7d28@github.com>
Message-ID: <JYvOQEE5QZI4NqeiYbqmJHM-UsOgeT_3xmVzqrlVWgY=.800f4316-6531-4446-98c8-48d32e6eb19e@github.com>

On Mon, 7 Oct 2024 05:58:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use a fixed locale in the test to prevent failures on environments that are not en_US
>  - add a test to verify extraction to a non-directory fails

Marked as reviewed by cstein (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/2752#pullrequestreview-2353419284

From duke at openjdk.org  Tue Oct  8 05:27:15 2024
From: duke at openjdk.org (Johny Jose)
Date: Tue, 8 Oct 2024 05:27:15 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b [v2]
In-Reply-To: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
Message-ID: <sFluBusZSSs-A8W0gwF_hktARw40ueKdcnkiV0xHdbA=.a1d47265-1450-4569-9226-baf767dc0d7b@github.com>

> Timezone data 2024b changes

Johny Jose has updated the pull request incrementally with one additional commit since the last revision:

  Review changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21265/files
  - new: https://git.openjdk.org/jdk/pull/21265/files/6c4ce6f8..c3238444

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21265&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21265&range=00-01

  Stats: 15 lines in 5 files changed: 0 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21265/head:pull/21265

PR: https://git.openjdk.org/jdk/pull/21265

From pkoppula at openjdk.org  Tue Oct  8 06:27:58 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Tue, 8 Oct 2024 06:27:58 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v4]
In-Reply-To: <Tb-8iAEg9YHtjK6lRiLcVbKy9vkgEVwmzZu2g9-v5NQ=.c12dd52f-507b-46ed-9cb4-95bba858c32d@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <Tb-8iAEg9YHtjK6lRiLcVbKy9vkgEVwmzZu2g9-v5NQ=.c12dd52f-507b-46ed-9cb4-95bba858c32d@github.com>
Message-ID: <rjXQoUVIUGezErDEsZ6oVotXL1al7e3eHKKnMVTroOU=.54c9584d-e9b4-4a19-9248-042ef5e57a36@github.com>

On Mon, 7 Oct 2024 12:42:00 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:
> 
>   JDK-8329251

Moved the debug messages higher in the call stack. Please review the changes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20414#issuecomment-2398955252

From duke at openjdk.org  Tue Oct  8 07:20:00 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Tue, 8 Oct 2024 07:20:00 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <rpTdBp-jZdnj8cASgWkq7GCVsbsfuS7ppDOIoR61OQI=.ccfc18db-77c2-41cc-a44c-b5eb1a1fdeed@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
 <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
 <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>
 <TZnn83hm2GBJtvMeO0tHi6NuToWvy0AJ3PiHDZlXScw=.671a271e-1f2e-4b33-88f4-0a73b035e793@github.com>
 <HUUa4UIjDXZvtksFPFVRg2kp8u2dZLyA-nC_9H2e3mk=.7bf8dc39-f3d1-499f-902a-112443229934@github.com>
 <SopH0a9bp3Xi87FhX6SX9WF4Jg8lcvL3ykD1957yJ-Y=.045e878e-176d-42f4-b7a5-c00f1f39f618@github.com>
 <m_3Tinr34oMR8vH3TgpoL07mWMKqKPUgS3Sda56HrJ8=.fb4bca07-9f81-4b06-a99e-187bfce95163@github.com>
 <rpTdBp-jZdnj8cASgWkq7GCVsbsfuS7ppDOIoR61OQI=.ccfc18db-77c2-41cc-a44c-b5eb1a1fdeed@github.com>
Message-ID: <Rp7a7zaPvY1TAIwQhsAi1f0WigbgNngzC4rKt_Wsd8k=.126bd939-a835-432c-9894-5bdd0ca72107@github.com>

On Mon, 7 Oct 2024 20:59:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I think the new rules define a bunch of rules that all layouts that model C type declarations should follow - but do so in broad strokes, still allowing the linker implementation to have the final say on what is and is not accepted.

I completely agree with you, but I was worried about another case.

I'm wondering if a particular linker implementation must declare its compatibility with the C calling convention for that platform? An implementation may reject many things that are possible, but what it accepts _must_ be consistent with the native convention, otherwise it doesn't make sense.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2399037464

From eirbjo at openjdk.org  Tue Oct  8 07:45:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 8 Oct 2024 07:45:13 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header [v3]
In-Reply-To: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
Message-ID: <raG3xH3qjZqvc0BUJv_wzRegIvq6Z6fDiXpUyWkR74I=.39544674-6f14-476a-a4a7-9ea57b322673@github.com>

> Please review this PR which adds validation of the 'total entries' value when fetched from the 'ZIP64 End of Central Directory' header.
> 
> We should reject this value under the following conditions:
> 
> 1. It is too large to fit within the specified CEN size (considering each CEN header encodes as at least 46 bytes each)
> 2. It is too large to create the `int[] entries` array safely (max value is `ArraysSupport.SOFT_MAX_ARRAY_LENGTH / 3`)
> 
> I claim that condition 2 here is already implicitly validated by the current maximum CEN size validation. (A CEN encoding such a large number of entries would exceed the maximum CEN size a lot and would already be rejected)
> 
> This change aims to protect the integrity of the implementation against specially crafted ZIP files. No sane ZIP tool will produce such files. 
> 
> Testing:
> 
> This PR adds a test `EndOfCenValidation.shouldRejectBadTotalEntries` which exercises the first condition above.
> 
> ZIP tests run locally. GHA results pending.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Reject "negative" 'total entries' values
 - Convert EndOfCenValidation to JUnit 5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21384/files
  - new: https://git.openjdk.org/jdk/pull/21384/files/ccfa56e4..0f0801c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21384&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21384&range=01-02

  Stats: 29 lines in 2 files changed: 9 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21384/head:pull/21384

PR: https://git.openjdk.org/jdk/pull/21384

From eirbjo at openjdk.org  Tue Oct  8 07:45:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 8 Oct 2024 07:45:13 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header [v2]
In-Reply-To: <fbFrO59NPRGGWQHDrlTBjX71VP0MwP6MR7H_E-8LERY=.4889dece-ff3b-46cd-a1f0-235fb12be84b@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
 <kZikDHV8049i9eAoalXCWQYNDkQxhMcIdU1AtfaXotY=.aae0098a-7371-432d-85f8-c4c87aaee66c@github.com>
 <fbFrO59NPRGGWQHDrlTBjX71VP0MwP6MR7H_E-8LERY=.4889dece-ff3b-46cd-a1f0-235fb12be84b@github.com>
Message-ID: <MIrYagNedjCopPMChrLR72uKPHN4VYC6YjGQ31t8CTs=.ba7b7e66-326e-4e7e-a419-840aed6839c8@github.com>

On Mon, 7 Oct 2024 20:00:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailing whitespace
>>  - Use a ZIP64 test vector which may be reproduced using InfoZIP
>
> Marked as reviewed by lancea (Reviewer).

@LanceAndersen 

I figured it would make sense to also reject "negative" values. These are not actually negative, just values larger than `Long.MAX_VALUE` can represent.

See the 11a275d for the conversion to JUnit 5 and 0f0801c which makes the test parameterized to verify that a bunch of bad entry count values are rejected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21384#issuecomment-2399088510

From redestad at openjdk.org  Tue Oct  8 07:55:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 07:55:06 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
Message-ID: <SFahKTg3NKXaxMmu7lrLVWEWBXE5ppA2q9JdMYdgpZg=.a1511101-9b2f-4437-a940-7e1302f93e94@github.com>

On Tue, 8 Oct 2024 01:13:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - class or interface descriptor renamed for clarity
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Cleanup after merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Compile error
>  - Redundant import
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - 8338544: Dedicated Array class descriptor implementation

Looks reasonable to me. 

An alternative could be to put an `int rank` in both `PrimitiveClassDescImpl` and `ReferenceClassDescImpl`. Would lead to slightly gnarlier code in places, but keep the number of classes down. Worth considering if any throughput benchmark sees fallout from going from 2 to 3 types. 

The `internalNameToDesc` changes could perhaps better have been done in a separate PR but no point teasing it apart now.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2353684434

From redestad at openjdk.org  Tue Oct  8 08:18:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 08:18:04 GMT
Subject: Integrated: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils
In-Reply-To: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
Message-ID: <VLs5rxeJ7u0-GRF8DWLKea9aqGiteVb_9jYFS6MZmXQ=.43c476dc-04d0-4487-b813-60a05b6d1ee9@github.com>

On Sun, 6 Oct 2024 14:16:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> #14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but the suggested PR would increase startup overheads by early use of `ByteArrayLittleEndian` which depends on `VarHandles`. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2. 
> 
> In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away):
> 
> 
> make test TEST=micro:java.util.zip.ZipFile
> 
> Name                          (size) Cnt       Base      Error        Test      Error  Unit  Change
> GetEntry.getEntryHit             512  15     37.999 ?    0.841      34.641 ?    0.389 ns/op   1.10x (p = 0.000*)
> GetEntry.getEntryHit            1024  15     39.557 ?    0.523      36.959 ?    1.488 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached     512  15     69.250 ?    0.931      64.851 ?    0.987 ns/op   1.07x (p = 0.000*)
> GetEntry.getEntryHitUncached    1024  15     71.628 ?    0.307      67.927 ?    0.714 ns/op   1.05x (p = 0.000*)
> GetEntry.getEntryMiss            512  15     22.961 ?    0.336      22.825 ?    0.188 ns/op   1.01x (p = 0.158 )
> GetEntry.getEntryMiss           1024  15     22.940 ?    0.115      23.502 ?    0.273 ns/op   0.98x (p = 0.000*)
> GetEntry.getEntryMissUncached    512  15     35.886 ?    0.429      35.598 ?    1.296 ns/op   1.01x (p = 0.395 )
> GetEntry.getEntryMissUncached   1024  15     38.168 ?    0.911      36.141 ?    0.356 ns/op   1.06x (p = 0.000*)
> Open.openCloseZipFile            512  15  62425.563 ?  997.455   56263.401 ?  896.892 ns/op   1.11x (p = 0.000*)
> Open.openCloseZipFile           1024  15 117491.250 ?  962.928  108055.491 ? 1595.577 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2          512  15  62974.575 ?  911.095   57996.388 ?  910.929 ns/op   1.09x (p = 0.000*)
> Open.openCloseZipFilex2         1024  15 119164.769 ? 1756.065  108803.468 ?  929.483 ns/op   1.10x (p = 0.000*)
>   * = significant
> 
> 
> This PR also address some code duplication in `ZipUtils`.
> 
> An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code ou...

This pull request has now been integrated.

Changeset: ffb60e55
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffb60e55cd77a92d19e1fde305f5d204b9fae429
Stats:     119 lines in 5 files changed: 18 ins; 22 del; 79 mod

8341594: Use Unsafe to coalesce reads in java.util.zip.ZipUtils

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/21377

From redestad at openjdk.org  Tue Oct  8 08:18:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 08:18:03 GMT
Subject: RFR: 8341594: Use Unsafe to coalesce reads in
 java.util.zip.ZipUtils [v4]
In-Reply-To: <K51df1JMSuUjvrigHS6mlQQ7y7ggTMlL6m4w8FAu1F0=.d32abe25-93b4-45cb-9d6e-9d641e189f25@github.com>
References: <eZF574iBy9bMafleqMLyijEScjSKMgp8xd81AfHY0dk=.ba458b55-493f-4246-8ea6-b2823b5c24bf@github.com>
 <X04m7EGiB5FqVOgVKofwuDFRFL7stUBdGC4Ism8blpg=.9e151c1b-f77f-429a-81ae-4fe210db9539@github.com>
 <Ai_e_kWlBtk2rMemknK-ng_5YJF7zC6QrtPkzNyJcos=.164c316f-e362-4184-afc2-4da7ef092ad1@github.com>
 <K51df1JMSuUjvrigHS6mlQQ7y7ggTMlL6m4w8FAu1F0=.d32abe25-93b4-45cb-9d6e-9d641e189f25@github.com>
Message-ID: <aJCv-kk-Vngmhq3EYT0XteQyzkxAxf3h50aNFH5qnDE=.b916a8a0-d55b-4e90-86b6-19b1880d560c@github.com>

On Tue, 8 Oct 2024 01:14:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipUtils.java line 173:
>> 
>>> 171:      * The bytes are assumed to be in Intel (little-endian) byte order.
>>> 172:      */
>>> 173:     public static final int get16(byte[] b, int off) {
>> 
>> Can JIT automatically perform MergeStore here? If JIT can automatically perform MergeStore without using Unsafe, many scenarios will benefit.
>
> Unfortunately we only have merge store for writing to arrays; no merge load when we are reading from arrays.

Yes. As I wrote in the PR description: "An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2." So it's the opposite of a merge store. I recall @eme64 mentioning somewhere that such an optimization would be possible, if we could show it to be profitable. I think it's reasonable to do this enhancement now, then revert the `Unsafe` stuff if/when there's a merge load optimization that beats it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21377#discussion_r1791410504

From jpai at openjdk.org  Tue Oct  8 09:37:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 09:37:36 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v14]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <EJ6v8Htfhqy5Z_saZL57stAHUGaYkfHGSEN5MP-CDPI=.59cd7aac-ad17-4568-bb00-8fef5824358d@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  update the man page of jar tool for the new option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/2752/files
  - new: https://git.openjdk.org/jdk/pull/2752/files/0b8d5aaa..d4bce414

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=12-13

  Stats: 21 lines in 1 file changed: 20 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

PR: https://git.openjdk.org/jdk/pull/2752

From jpai at openjdk.org  Tue Oct  8 09:47:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 09:47:02 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v14]
In-Reply-To: <EJ6v8Htfhqy5Z_saZL57stAHUGaYkfHGSEN5MP-CDPI=.59cd7aac-ad17-4568-bb00-8fef5824358d@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <EJ6v8Htfhqy5Z_saZL57stAHUGaYkfHGSEN5MP-CDPI=.59cd7aac-ad17-4568-bb00-8fef5824358d@github.com>
Message-ID: <rPZcHxZsU6tN4qQGxDisLhTgNqpsd8z8-WBIAwPPcBY=.6e120b7b-4b4a-4151-b378-8ecb782c7535@github.com>

On Tue, 8 Oct 2024 09:37:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the man page of jar tool for the new option

Thank you Lance and Christian for the reviews. Joe, in the CSR, rightly noted that I had missed including the man page changes. I've now updated the PR to include the man page update for the `jar` tool and also updated the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2752#issuecomment-2399372409

From swen at openjdk.org  Tue Oct  8 09:57:43 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 09:57:43 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v25]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <7Y4K8fhMRRaLlg3jF__2poKiMRwKwHggUE0iepmjFbg=.6e67168d-968b-4981-8618-2d274bba3835@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - Fold opcode.bytecode() in writeLoadConstant
 - A few missed places, U1U2U2 seem common enough too to be included
 - Rename writeUtfEntry
 - Fold TAG_UTF8 write into writeUTF

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/c6e4114c..cd597a2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=23-24

  Stats: 43 lines in 4 files changed: 14 ins; 12 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From eirbjo at openjdk.org  Tue Oct  8 10:02:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 8 Oct 2024 10:02:03 GMT
Subject: Integrated: 8341597: ZipFileInflaterInputStream input buffer size uses
 uncompressed size
In-Reply-To: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>
References: <hlJJFNS_lWPa5azpyzeLfUf5fekNkFS4HB8g692zBWY=.a054d0d8-7c83-42d0-b244-560b1917d489@github.com>
Message-ID: <M-PgieL1I6oBxQ6hLmVaV-fQeSuVOonpT8SxXq5869g=.2b99b012-2bda-43d9-8fa9-510101f03853@github.com>

On Sun, 6 Oct 2024 18:02:58 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which proposes to change the input buffer size of `ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP entry instead of the _uncompressed_ size. This saves allocation since buffers will no longer be oversized:
> 
> * The `size` parameter passed to the `ZipFileInflaterInputStream` constructor is passed on to the superclass `InflaterInputStream` where it determines the size of the input buffer. This buffer is used to read compressed data and pass it on to the `Inflater`.
> * `ZipFile:getInputStream` currently looks at the _uncompressed_ size when determining the input buffer size. It should instead use the _compressed_ size, since this buffer is used for compressed, not uncompressed data.
> * The current implementation somewhat mysteriously adds 2 to the uncompressed size. My guess is that this is to allow fitting a two-byte DEFLATE header for empty files (where the uncompressed size is 0 and the compressed size is 2).
> * There is a check for `size <= 0`. This condition is unreachable in the current code and in the PR as well, since the compressed size will always be `>= 2`. I propose we remove this check.
> 
> Performance: A benchmark which measures the cost of opening and closing input streams using `ZipFile::getInputStream` shows a modest improvement of ~5%, consistent with less allocation of unused buffer space.
> 
> Testing: No tests are added in this PR. The `noreg-cleanup` label is added in JBS. GHA testing is currently pending.

This pull request has now been integrated.

Changeset: f62dba36
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f62dba3651719bc0031522e171a6e42b362c1363
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8341597: ZipFileInflaterInputStream input buffer size uses uncompressed size

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/21379

From eirbjo at openjdk.org  Tue Oct  8 10:11:07 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 8 Oct 2024 10:11:07 GMT
Subject: Integrated: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <nbtiECz2zTVfRrSaO0yL1aHtEodV3D6kxA4axEfTGYc=.b6bd06f4-2fe2-447b-8fa3-2b70dc68e23c@github.com>

On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

This pull request has now been integrated.

Changeset: 7a1e832e
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a1e832ea997f9984eb5fc18474a8f1650ddb1bf
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8336843: Deprecate java.util.zip.ZipError for removal

Reviewed-by: liach, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/20642

From mcimadamore at openjdk.org  Tue Oct  8 10:30:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Oct 2024 10:30:05 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v5]
In-Reply-To: <Rp7a7zaPvY1TAIwQhsAi1f0WigbgNngzC4rKt_Wsd8k=.126bd939-a835-432c-9894-5bdd0ca72107@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <mkrihzCYvo2dTwQrNPIrSR26mVUUrug5eoF4eDES2xQ=.c2967070-191e-4f83-abf7-9e292f2f8ffb@github.com>
 <XiNV6k9V1lZFgzSZsHJIsYYFyauAP9t6_TSY5CG_gYk=.b17a908c-ac14-4b06-846a-151825814437@github.com>
 <6uoveIThKhi94sNsXtVPbafpsfPcn7I3Zs01_cIqnKg=.912834f2-fdb1-43c9-a53c-70997216d2d5@github.com>
 <H_gSjqiUX4BhnO2Td_WpVB7kUiBPZEbz5JEZIxIQKQQ=.a77f75b2-4f04-4730-ad63-d8ebbe0fb4da@github.com>
 <TZnn83hm2GBJtvMeO0tHi6NuToWvy0AJ3PiHDZlXScw=.671a271e-1f2e-4b33-88f4-0a73b035e793@github.com>
 <HUUa4UIjDXZvtksFPFVRg2kp8u2dZLyA-nC_9H2e3mk=.7bf8dc39-f3d1-499f-902a-112443229934@github.com>
 <SopH0a9bp3Xi87FhX6SX9WF4Jg8lcvL3ykD1957yJ-Y=.045e878e-176d-42f4-b7a5-c00f1f39f618@github.com>
 <m_3Tinr34oMR8vH3TgpoL07mWMKqKPUgS3Sda56HrJ8=.fb4bca07-9f81-4b06-a99e-187bfce95163@github.com>
 <rpTdBp-jZdnj8cASgWkq7GCVsbsfuS7ppDOIoR61OQI=.ccfc18db-77c2-41cc-a44c-b5eb1a1fdeed@github.com>
 <Rp7a7zaPvY1TAIwQhsAi1f0WigbgNngzC4r
 Kt_Wsd8k=.126bd939-a835-432c-9894-5bdd0ca72107@github.com>
Message-ID: <QjTr-cnjXiL5lfURVa6WucWyQUrDGrsOhwMihKaWK8I=.204dfde4-a932-498d-9358-d5272ba225e6@github.com>

On Tue, 8 Oct 2024 07:17:02 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> I'm wondering if a particular linker implementation must declare its compatibility with the C calling convention for that platform? An implementation may reject many things that are possible, but what it accepts _must_ be consistent with the native convention, otherwise it doesn't make sense.

Of course - that's implicit in the sentence `A linker has detailed knowledge of the calling conventions and data types used by a
specific ABI` which appears quite early in the `Linker` javadoc. Also, the javadoc for `Linker::nativeLinker` states:


{@return a linker for the ABI associated with the underlying native platform}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2399463764

From ihse at openjdk.org  Tue Oct  8 10:59:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 10:59:57 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v3]
In-Reply-To: <h-ayzrZ0RwwhCDppYY5B5cvKLWcISIEAa2wQYBkyvVE=.b412428d-9758-4601-a092-91d69992c87e@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <h-ayzrZ0RwwhCDppYY5B5cvKLWcISIEAa2wQYBkyvVE=.b412428d-9758-4601-a092-91d69992c87e@github.com>
Message-ID: <iMCi38g3F48v2Zl5eCC-RONwv_YVxniY3B3XNpsQBAI=.1ecf4efe-0e08-4851-a4e6-939f370f3136@github.com>

On Fri, 4 Oct 2024 09:34:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move ub.h to a better location

>From a build point of view, this looks good. 

I'm not commenting if it is correct to disable ub checking for `DEFINE_SOLID_DRAWGLYPHLISTAA` instead of trying to fix them.

As a general note, we have discussed multiple times if, or rather how, we could have a generic library that is shared by native code across all Java modules, and Hotspot code alike, but no satisfactory solution has been found as of yet.

In this particular case, where all that is needed is an additional header file, I think the currently suggested solution of putting it in libjava makes sense. The majority of other JDK native libraries already depend on libjava.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21184#pullrequestreview-2354135668
PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2399523662

From ihse at openjdk.org  Tue Oct  8 10:59:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 10:59:58 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <xZHRfRmcxI5Nm_rsC5Ev9XFDVJWiCfi6XYl5mb6mdGI=.9cfc12bb-5d33-4ec1-a932-9fbd1e63a60b@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <xZHRfRmcxI5Nm_rsC5Ev9XFDVJWiCfi6XYl5mb6mdGI=.9cfc12bb-5d33-4ec1-a932-9fbd1e63a60b@github.com>
Message-ID: <MwSkfKBC2IM1CqykyIBCo5u5E1SHMq_U5feJoruqCxk=.685225f5-90a0-4e5b-82de-ad88bcbdad4d@github.com>

On Thu, 26 Sep 2024 21:25:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> This needs careful thinking about by various parties.
> I am not sold on it, and the build team have indicated they do not support --enable-ubsan and my experience with that and similar options is that they are a nightmare to find a system on which they build and produce a working binary.
> 
> Until there's solid committed support by the leads of the build team I don't think we should be considering these kinds of PRs.

@prrace 

>  the build team have indicated they do not support --enable-ubsan and my experience with that and similar options is that they are a nightmare to find a system on which they build and produce a working binary.

The UBSan functionality is well supported, as such, in the build system. As you say, actually building and running a JDK with UBSan functionality is not trivial. This just means that we are unlikely to e.g. run it continuously on our CI in the foreseeable future, not that any changes towards improving support for detecting undefined behavior should be stopped.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2399519251

From aph at openjdk.org  Tue Oct  8 11:10:06 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 8 Oct 2024 11:10:06 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <kSwMoNMtYWBlfxQQaVB0DJ6AqBlA499dW3VLznfXO5Q=.522d5cc2-513e-4f80-a8b6-5589683b1a1f@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

On 9/10/24 12:42, Coleen Phillimore wrote:
 > Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.

I'm a bit concerned about this one.

I'm working on megamorphic dispatch, and a uniform representation of
compressed class pointers allows me to squeeze klass+offset into a
single 64-bit word. This in turn allows fast and simple method
lookups. I need, at least, to be able to use compressed interface
pointers. If interfaces are "somewhere else", and thus incompressible,
I can't do what I need to do. If, however, klass and non-klass
metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
rather use compressed klass pointers without having to decode them.

All I need is a way to represent interface pointers in a compact way
in lookup tables, and to be able to get from compressed class pointers
to the address. As long as interface pointers are in a 32-bit range
and there's a fast way to get from compressed class to address that's
OK.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2399545521

From duke at openjdk.org  Tue Oct  8 11:23:42 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:23:42 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with six additional commits since the last revision:

 - renamed source to cs; cs is final; close sets boolean; no adouble reference to source
 - Fixed Typo: 'resect' -> 'respect'
 - Improved wording: 'The returned reader supports the {@link #mark mark()} operation'
 - Improved wording: 'Returns a {@code Reader} that reads characters from a {@code CharSequence}, starting at the first character in the sequence'
 - test for generic read(char, int, int) case
 - Remove useless test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/ae9f5845..5cbc0450

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=02-03

  Stats: 42 lines in 2 files changed: 24 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From duke at openjdk.org  Tue Oct  8 11:29:00 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:00 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <znZFF_2o9nmCUx_20Rf4RVVjAfCvEfaT-PvNvaso16k=.af8a0bab-4cc3-4bb7-8dfa-0a39654c2b63@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <znZFF_2o9nmCUx_20Rf4RVVjAfCvEfaT-PvNvaso16k=.af8a0bab-4cc3-4bb7-8dfa-0a39654c2b63@github.com>
Message-ID: <vLoBUAirbyHdvofcy5zMe_eTKrKWrLCENCHO50_KdLI=.1864f2c4-143b-4b1a-8d1d-b2a0beb4550b@github.com>

On Sun, 6 Oct 2024 18:12:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! Reader.of(String)
>>   
>>   Dropping non-public JavaDocs
>
> src/java.base/share/classes/java/io/Reader.java line 144:
> 
>> 142: 
>> 143:     /**
>> 144:      * Returns a new {@code Reader} whose source is a {@link CharSequence}.
> 
> Probably better to more this more precise, e.g.  Returns a {@code Reader} that reads characters from a {@code CharSequence}, starting at the first character in the sequence.

I have replaced the wording by your exact proposal.

> src/java.base/share/classes/java/io/Reader.java line 154:
> 
>> 152:      * have no effect.
>> 153:      *
>> 154:      * <p> After the reader has been closed, the {@code read()},
> 
> This paragraph is okay but the Reader methods should really specify this (doing so after 25+ years of being unspecified would require being confident wouldn't invalidate any existing Readers).

IIUC then there is nothing to change in this PR?

> src/java.base/share/classes/java/io/Reader.java line 159:
> 
>> 157:      * {@code transferTo()} methods all throw {@code IOException}.
>> 158:      *
>> 159:      * <p> The {@code markSupported()} method returns {@code true}.
> 
> Chen's suggestion to say that it supports the mark operation would be clearer than the legacy wording.

I have replaced the wording by Chen's exact proposal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791294423
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791294032
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791298262

From duke at openjdk.org  Tue Oct  8 11:29:00 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:00 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <Jxilv7cTmgx8_mCRfRclli7KnX1ulnXEAkxhXLHypRc=.212411b3-6aca-4d35-aba6-8ebf9bbb7786@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
 <6ldzKUI3h9PGaHwA67VYyha6LNjNw9T_sOp_G56OXOw=.d20df34a-1fbd-417a-b625-b5c419c4d37d@github.com>
 <Jxilv7cTmgx8_mCRfRclli7KnX1ulnXEAkxhXLHypRc=.212411b3-6aca-4d35-aba6-8ebf9bbb7786@github.com>
Message-ID: <-L0peP79Lr_Xk-_9xtiNFGffQ80MLSwGchsWO8p13XA=.03e8c66c-03ea-4a72-83d6-34e2238773f3@github.com>

On Sun, 6 Oct 2024 17:56:03 GMT, Bernd <duke at openjdk.org> wrote:

>> This is not wrong. This exact wording is already used in `Reader.java`, so it would be strange to change it *just here*.
>
> You can ?elaborately? the close and mark protocol in the Reader interface and then only mention itnadgeres to it here.

Replaced wording by exact proposal from Chen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791697726

From duke at openjdk.org  Tue Oct  8 11:29:02 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:02 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <Pgq6Ik_lhiHvnf9p00w6qHkeLoJqe8yAgCcnFBmf5hQ=.5cb5ff41-8560-4b76-b73c-5dfecd950fe1@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <YxZliiXoiN-Np51CvhnYFlqNwC-REI00Xvn0DXp6q6E=.f77b984b-8584-44a0-aab9-b30e1c91c7f2@github.com>
 <Pgq6Ik_lhiHvnf9p00w6qHkeLoJqe8yAgCcnFBmf5hQ=.5cb5ff41-8560-4b76-b73c-5dfecd950fe1@github.com>
Message-ID: <MaEoKvkKPlVUiw-psAxpC7yBZXtHvok58NruZKDtQOg=.5a9fa86a-7ba6-43a4-98aa-5557759acf74@github.com>

On Mon, 7 Oct 2024 04:44:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 172:
>> 
>>> 170:         Objects.requireNonNull(source);
>>> 171: 
>>> 172:         return new Reader() {
>> 
>> Maybe?make?this into?a?package?private `CharSequenceReader` so?that?[`StringReader?::close()`] doesn?t?have to?use a?try?catch.
>> 
>> [`StringReader?::close()`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/StringReader.html#close()
>
> I don't think that try-catch is too much of a bloat compared to the extra license header and imports from the explicit `CharSequenceReader.java` file.

> Maybe make this into a package?private `CharSequenceReader` so that [`StringReader?::close()`](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/StringReader.html#close()) doesn?t have to use a try?catch.

This is exactly the opposite of what Alan and me had in mind: It piles up the stack of special-case classes. Instead, I do agree with Chen regarding code bloat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791300193

From duke at openjdk.org  Tue Oct  8 11:29:05 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:05 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <Z6ZHUcp2HYmXS4LHrEQRS7lFGsbo4Lg_vPhi4iXulqs=.e594f802-f9bf-4a36-aed1-65abe08f7bf6@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <sPBzh8qERLoHb-zhlcwqmTxQJHRgF-CIXMGqJnGMBGg=.75ccbf48-f7ad-4f35-b67f-8b31fe224d60@github.com>
 <Z6ZHUcp2HYmXS4LHrEQRS7lFGsbo4Lg_vPhi4iXulqs=.e594f802-f9bf-4a36-aed1-65abe08f7bf6@github.com>
Message-ID: <Uos2RtudGzuXUUe6yU6AAUtyWXxT1VoaaRC1IBu0fS4=.db21d3d2-53fa-4451-8ada-458d30093252@github.com>

On Sun, 6 Oct 2024 18:25:15 GMT, Bernd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 231:
>> 
>>> 229:             public boolean ready() throws IOException {
>>> 230:                 ensureOpen();
>>> 231:                 return true;
>> 
>> I guess it?s not wrong, but can this be false when end of source is reached? Related to this you already described it is not synchronized but should we also describe it does not support changes to the length during ?iteration? (could be in the same thread).
>
> Ignore my ?thinko?/comment. of course it needs to return true for the EOD.

>From `Reader.ready()`'s JavaDocs:
>True if the next read() is guaranteed not to **block** for input, false otherwise. Note that returning false does not guarantee that the next read will **block**.

`ready()` says that it will not **block**. The current proposal will *never block*. So it is correct to return `true` *always*, even in case of EOL. There is nothing we need to explicitly describe here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791503407

From duke at openjdk.org  Tue Oct  8 11:29:06 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:06 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <4NhYHpnhVsaWgmz2u4vf2DP0ojj-jbOV7vtgxycmb1g=.93654fbb-bcca-4af9-84c8-f13155ddbefa@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <6Gmbld63oMglbxHX4V8LzN2-ppuAyPsNolXEmlKQJhQ=.fb5f2511-478e-4e28-b895-6587e1282834@github.com>
 <kWAQ_rylD-s6KOYHQTdM6uT_qcnTmQKM6rVbWh0dir4=.c8c24b58-7f46-44f8-8be5-dca7f58dcee9@github.com>
 <pT_K6-FjqOsV9TEp75t3B-_WkT3H6vGYxT7VJzAYuvs=.d186b40a-bd4f-4c5e-b3e9-68609c27de76@github.com>
 <4NhYHpnhVsaWgmz2u4vf2DP0ojj-jbOV7vtgxycmb1g=.93654fbb-bcca-4af9-84c8-f13155ddbefa@github.com>
Message-ID: <8bdmeFkzJJCrU2wofdBu4EUDtYpKsvRnOYy0a4tvYns=.56f4cbde-250a-4d4f-b31e-bb0ef78e118c@github.com>

On Sun, 6 Oct 2024 18:10:49 GMT, Bernd <duke at openjdk.org> wrote:

>> Good idea. But instead, we could also add a new API `CharSequence.of(char[])` and test *that* class? WDYT?
>
>> Good idea. But instead, we could also add a new API `CharSequence.of(char[])` and test _that_ class? WDYT?
> 
> Both you need to test the generic case anyway.

Added ad-hoc class now in the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791504386

From duke at openjdk.org  Tue Oct  8 11:29:02 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:02 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v2]
In-Reply-To: <kTGWzSGXMXt_iNPxnTwqe1sLfMRinw2iF89DmuEp2yc=.b9fe48a9-5c78-44f4-8f74-9775037f40cf@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <0PdvWpmfoLDIMe5XwDCM5_a8j6lEaq0vjl_VgCtZXvw=.3dd97fcd-ea50-4de6-8d85-9f4aa92c7a42@github.com>
 <odqOItnwT466uvC-KfooM2cZ9WqlHNqSL3_d6wQOJQI=.0a483584-d6a0-4a81-824f-23b8e9205106@github.com>
 <Z8u0xGwDAZ2Wwh-ahLTVdgo4rstXVEhwZisWGi90Chs=.f63b1419-c32d-4f62-b390-db85fcbc67bd@github.com>
 <LgPjEgBHegKnqfxDRcLOzxoqcGBEjgnEoA6AD1DXh7Y=.280f7eac-9c00-4366-8298-88297c216760@github.com>
 <XCNXmQEJqiyqo6pfalLW8oLYkfNn3qDEb8s7_M5OxZg=.1d651f67-85a7-43b9-9e94-fb6e87865ad2@github.com>
 <kTGWzSGXMXt_iNPxnTwqe1sLfMRinw2iF89DmuEp2yc=.b9fe48a9-5c78-44f4-8f74-9775037f40cf@github.com>
Message-ID: <z0XlveGMkICCPUlNeKlCpWS02df0Go-kH2GYycfjY40=.4bf2e311-4999-4c3e-941d-9e7fde389207@github.com>

On Mon, 7 Oct 2024 19:44:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I really do see you point, nevertheless I think we should be kind to "bad" users, too. In the end, there is *no* specification which explicitly tells "bad" users that readers are support to be short-living (despite it being rather obvious), while `close` explicitly mentions freeing *all* resources, so it is rather unexpected to keep something past `close`, even for short term. NB: `StringReader` applies the very same behavior, too (using `s` and `str` variables), that's where I copied the code from originally. It is not a big problem for us to have two variables, neither that the name of the variable is `source` (in fact, I do like `source` even more than `cs`, but this is just my personal preference). To sum up, I really dislike the idea to keep the reference for any longer than essentially needed. If it's just about the name of the variable, I could simply switch them if you prefer that.
>
> On a linux x64 build:
> 
> ./javap -p java.io.Reader$2
> Compiled from "Reader.java"
> class java.io.Reader$2 extends java.io.Reader {
>   private final int length;
>   private java.lang.CharSequence cs;
>   private int next;
>   private int mark;
>   final java.lang.CharSequence val$source;
>   java.io.Reader$2(java.lang.CharSequence);
>   private void ensureOpen() throws java.io.IOException;
>   public int read() throws java.io.IOException;
>   public int read(char[], int, int) throws java.io.IOException;
>   public long skip(long) throws java.io.IOException;
>   public boolean ready() throws java.io.IOException;
>   public boolean markSupported();
>   public void mark(int) throws java.io.IOException;
>   public void reset() throws java.io.IOException;
>   public void close();
> }
> 
> 
> The javap in the built binaries of this patch shows that this anonymous class already keeps the `CharSequence val$source` in a final field; therefore, your setting the `cs` field to `null` will not help GC or anything of that sort.

Sigh, too bad, as keeping `val$source` is actually useless in our case, but I understand that this happens due to our class being an anonymous inner class, not a standalone class (as it was the case with `StringReader`, where this source code originates from).

Anyways, adopted your proposal now to proceed with this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791494712

From duke at openjdk.org  Tue Oct  8 11:29:07 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:07 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <58-cunZZhUAeoGtIRxxaGHIwfe1ib0ysT3FhHrdgtxM=.72ff4faf-347b-4246-a190-17d47dbf78d9@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <58-cunZZhUAeoGtIRxxaGHIwfe1ib0ysT3FhHrdgtxM=.72ff4faf-347b-4246-a190-17d47dbf78d9@github.com>
Message-ID: <iKuwpV9iAR3EfF230_o2fZsMJ-oiq951iUuJZzjwEBU=.cc8cb14a-146f-49f9-8111-e05f66e6920e@github.com>

On Sun, 6 Oct 2024 18:13:14 GMT, Bernd <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixup! Reader.of(String)
>>   
>>   Dropping non-public JavaDocs
>
> test/jdk/java/io/Reader/Of.java line 63:
> 
>> 61:     @Test(dataProvider = "readers")
>> 62:     public void testOpen(Reader reader) {
>> 63:         assertNotNull(reader, "Reader.of(String) returned null");
> 
> This does not look like a useful test and the assert is misleading (no String)

Removed this test.

> test/jdk/java/io/Reader/Of.java line 145:
> 
>> 143:         assertEquals(reader.transferTo(sw), 16, "transferTo() != 16");
>> 144:         assertEquals(reader.transferTo(sw), 0,
>> 145:                 "transferTo() does not resect empty stream");
> 
> Typo respect (I also wonder if ?empty stream? (used multiple times) should be ?end of stream? or ?exhausted stream?. The test never get an empty stream to test.

"empty stream" is actually correct. The case "end of stream" is implied in the line before (the test that expects result `16`, it starts with non-empty stream, it stops at end-of-stream). From that point, the stream is now empty, as `transferTo()` transferred *everything*. So what this test (the one expecting result `0`) tests is what happens if `transferTo()` starts in an already-empty situation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791504721
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791673725

From duke at openjdk.org  Tue Oct  8 11:29:03 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:03 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <trsusRgdNOsDtaMIgryeTCApN4FHXa7VOvkd0mmA4Vg=.dffc8b68-5040-42b8-a7d7-2d95609d6b36@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <tE6SYgcvzAET4q-ZtNMQFEW0ASPCflDfXbyMba3qP8c=.40cfcad6-7f4d-40be-99ab-6342384b10d3@github.com>
 <5mL72m7q6LN2GB3ut_Ps8bB4FIM6W__2TZEnmgq9oQM=.232c5973-3e30-4161-90e2-7fae8a39cb27@github.com>
 <trsusRgdNOsDtaMIgryeTCApN4FHXa7VOvkd0mmA4Vg=.dffc8b68-5040-42b8-a7d7-2d95609d6b36@github.com>
Message-ID: <yiEP7EnVgnF3p9j4G8XJcfdSmycEJtguFcS0D56T_jA=.6e673314-3a7f-4d7a-a3b9-24f01a5247a6@github.com>

On Mon, 7 Oct 2024 07:39:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I do not see what is "confusing" in that case, as the caller still gets what he intends: a reader for the passed source. I also wonder how likely that case actually is. Anyways, I may be biased as I proposed `of`.
>> 
>> @AlanBateman WDYT?
>
> You'll get different opinions on naming, personally I think Reader.of(cs) is very readable at use-sites. There are several other static methods named "of" added in other areas in recent years.

So let's go with `Reader.of()` unless nobody has stronger feelings against it. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791696472

From duke at openjdk.org  Tue Oct  8 11:29:04 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 11:29:04 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <aS1igbav6qq6txb2AwzrbtnzZ-kYcW5vqj8gQXoLp_4=.f4cd2d6c-ac80-49aa-9f18-d5f6e0e03683@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <rmnOeQu8FeDwMXMOXz0U-KEVH9Tv9x_KRsenJDs6NEI=.183ecf47-c216-4ffe-b90d-6a02493a2623@github.com>
 <aS1igbav6qq6txb2AwzrbtnzZ-kYcW5vqj8gQXoLp_4=.f4cd2d6c-ac80-49aa-9f18-d5f6e0e03683@github.com>
Message-ID: <bMbI1M2tov3C9m-Zex6C1HADOeLribuSdTtYStrBFqk=.3fd55f57-a11c-42fc-ad17-30ab3016dca0@github.com>

On Mon, 7 Oct 2024 04:43:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 203:
>> 
>>> 201:                 int n = Math.min(length - next, len);
>>> 202:                 switch (cs) {
>>> 203:                     case String s -> s.getChars(next, next + n, cbuf, off);
>> 
>> There was some discussion on the mailing list of introducing a method to CharSequence for bulk getChars. Doing that would help both here and in Appendable/Writer implementations like StringWriter, PrintWriter, and OutputStreamWriter which currently convert to a String to then write.
>> 
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/Writer.java#L367
>> 
>> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/OutputStreamWriter.java#L253
>
> I believe this batch operation would be a useful addition, but it is best reserved for another RFE.

Agree to Chen. As I already wrote in [the RFE](https://bugs.openjdk.org/browse/JDK-8341566):
>As this option is not essentially needed, and as it implies deeper thought and discussion, this option is explicitly EXCLUDED from this current enhancement request. We can pick it up later in a subsequent enhancement request.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791500863

From alanb at openjdk.org  Tue Oct  8 11:40:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Oct 2024 11:40:58 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
Message-ID: <b58kFBc8j-KafmiXDBkL79_7AaFYrotfS_bNb92Zpto=.9a61c0b8-f621-4919-b25e-6560b1f0219b@github.com>

On Tue, 8 Oct 2024 11:23:42 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - renamed source to cs; cs is final; close sets boolean; no adouble reference to source
>  - Fixed Typo: 'resect' -> 'respect'
>  - Improved wording: 'The returned reader supports the {@link #mark mark()} operation'
>  - Improved wording: 'Returns a {@code Reader} that reads characters from a {@code CharSequence}, starting at the first character in the sequence'
>  - test for generic read(char, int, int) case
>  - Remove useless test

src/java.base/share/classes/java/io/Reader.java line 155:

> 153:      * have no effect.
> 154:      *
> 155:      * <p> After the reader has been closed, the {@code read()},

The API docs in 5cbc0450 looks okay. One minor comment is that "After the reader has been closed ..." doesn't need to be a new paragraph as it's part of the lifecycle topic in the previous paragraph.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791712536

From jpai at openjdk.org  Tue Oct  8 11:57:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 11:57:01 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
Message-ID: <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>

On Tue, 8 Oct 2024 11:23:42 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - renamed source to cs; cs is final; close sets boolean; no adouble reference to source
>  - Fixed Typo: 'resect' -> 'respect'
>  - Improved wording: 'The returned reader supports the {@link #mark mark()} operation'
>  - Improved wording: 'Returns a {@code Reader} that reads characters from a {@code CharSequence}, starting at the first character in the sequence'
>  - test for generic read(char, int, int) case
>  - Remove useless test

src/java.base/share/classes/java/io/Reader.java line 174:

> 172: 
> 173:         return new Reader() {
> 174:             private final int length = cs.length();

Hello Markus, as far as I can see, a  `CharSequence` is allowed to have a non-fixed `length()` (typically allowed to increase?). Is there a reason why the length is captured at construction time instead of being evaluated during the read operations of the `Reader`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791734338

From mbaesken at openjdk.org  Tue Oct  8 12:00:58 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Oct 2024 12:00:58 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <MwSkfKBC2IM1CqykyIBCo5u5E1SHMq_U5feJoruqCxk=.685225f5-90a0-4e5b-82de-ad88bcbdad4d@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <xZHRfRmcxI5Nm_rsC5Ev9XFDVJWiCfi6XYl5mb6mdGI=.9cfc12bb-5d33-4ec1-a932-9fbd1e63a60b@github.com>
 <MwSkfKBC2IM1CqykyIBCo5u5E1SHMq_U5feJoruqCxk=.685225f5-90a0-4e5b-82de-ad88bcbdad4d@github.com>
Message-ID: <ejiJS3IevGl1IR-9khJDuWurNucJfwZinz3VxPasBU4=.6a67be67-b161-451f-8424-5e4b9ca275ed@github.com>

On Tue, 8 Oct 2024 10:54:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>The UBSan functionality is well supported, as such, in the build system. As you say, actually building and running a JDK with 
> UBSan functionality is not trivial. This just means that we are unlikely to e.g. run it continuously on our CI

We are running it for some weeks now at least once a week in our central builds/tests  (so far only on Linux x86_64).
If you have a recent SUSE or Ubuntu ubsan works nicely with OpenJDK .  But I haven't checked on all popular distros.
In the past we had just too many ubsan-related issues in the OpenJDK codebase that even hindered doing a build, but this situation has improved a lot over the last months.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2399644216

From duke at openjdk.org  Tue Oct  8 12:02:00 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 12:02:00 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <b58kFBc8j-KafmiXDBkL79_7AaFYrotfS_bNb92Zpto=.9a61c0b8-f621-4919-b25e-6560b1f0219b@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <b58kFBc8j-KafmiXDBkL79_7AaFYrotfS_bNb92Zpto=.9a61c0b8-f621-4919-b25e-6560b1f0219b@github.com>
Message-ID: <4pOPvBKs10oYjNcA-kUlbEZA18jA1MPsqNRv5cGiaiU=.e2771429-fcf8-4a61-988c-ed6b5f3cd784@github.com>

On Tue, 8 Oct 2024 11:38:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - renamed source to cs; cs is final; close sets boolean; no adouble reference to source
>>  - Fixed Typo: 'resect' -> 'respect'
>>  - Improved wording: 'The returned reader supports the {@link #mark mark()} operation'
>>  - Improved wording: 'Returns a {@code Reader} that reads characters from a {@code CharSequence}, starting at the first character in the sequence'
>>  - test for generic read(char, int, int) case
>>  - Remove useless test
>
> src/java.base/share/classes/java/io/Reader.java line 155:
> 
>> 153:      * have no effect.
>> 154:      *
>> 155:      * <p> After the reader has been closed, the {@code read()},
> 
> The API docs in 5cbc0450 looks okay. One minor comment is that "After the reader has been closed ..." doesn't need to be a new paragraph as it's part of the lifecycle topic in the previous paragraph.

IIUC I shall just remove the `<p>` but keep the text `After the reader...`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791741264

From duke at openjdk.org  Tue Oct  8 12:10:59 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 12:10:59 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
Message-ID: <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>

On Tue, 8 Oct 2024 11:54:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - renamed source to cs; cs is final; close sets boolean; no adouble reference to source
>>  - Fixed Typo: 'resect' -> 'respect'
>>  - Improved wording: 'The returned reader supports the {@link #mark mark()} operation'
>>  - Improved wording: 'Returns a {@code Reader} that reads characters from a {@code CharSequence}, starting at the first character in the sequence'
>>  - test for generic read(char, int, int) case
>>  - Remove useless test
>
> src/java.base/share/classes/java/io/Reader.java line 174:
> 
>> 172: 
>> 173:         return new Reader() {
>> 174:             private final int length = cs.length();
> 
> Hello Markus, as far as I can see, a  `CharSequence` is allowed to have a non-fixed `length()` (typically allowed to increase?). Is there a reason why the length is captured at construction time instead of being evaluated during the read operations of the `Reader`?

As the anonymous class MUST NOT be used with be used with multiple threads, I always have seen the `CharSequence` as *fixed/static* text in the moment the `Reader` is getting used. But indeed, technically one could interleave `Reader::read()` invocations by `CharSequence.append()` (or even worse, `CharSequence.delete()`) invocations. The question is: Would that make *any* sense in the end? I mean, what happens if one has `read()` text that in the next step gets `delete()`'d? I cannot image *any* scenario where such a program would result in *useful* outcome.

&lt;fun>The fact that nobody so far (before you) brought up this question seems to proof that nobody (besides you) would write such a program. ? &lt;/fun>

So I would plea for clearly saying in the JavaDocs that `cs` MUST NOT be modified before `close()` is called. Every other solution implies strange side effects and slower and error-prone implementation of both, anoynous reader *and* test.

@AlanBateman WDYT?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791754907

From liach at openjdk.org  Tue Oct  8 12:34:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 12:34:59 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v3]
In-Reply-To: <vLoBUAirbyHdvofcy5zMe_eTKrKWrLCENCHO50_KdLI=.1864f2c4-143b-4b1a-8d1d-b2a0beb4550b@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <qQwAOH-pd-3ILu_i5cSeGtdF4BqffQYuSFAM5tiQyWM=.4c63c5d5-32c9-49a4-afc1-cdf95907610f@github.com>
 <znZFF_2o9nmCUx_20Rf4RVVjAfCvEfaT-PvNvaso16k=.af8a0bab-4cc3-4bb7-8dfa-0a39654c2b63@github.com>
 <vLoBUAirbyHdvofcy5zMe_eTKrKWrLCENCHO50_KdLI=.1864f2c4-143b-4b1a-8d1d-b2a0beb4550b@github.com>
Message-ID: <q4RuVC-s8bTstsX2nTWDV97HACYhDfUpjYI4FVyA_t0=.816015f2-2c65-4c8d-9b3a-aa33298ec215@github.com>

On Tue, 8 Oct 2024 06:48:59 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 154:
>> 
>>> 152:      * have no effect.
>>> 153:      *
>>> 154:      * <p> After the reader has been closed, the {@code read()},
>> 
>> This paragraph is okay but the Reader methods should really specify this (doing so after 25+ years of being unspecified would require being confident wouldn't invalidate any existing Readers).
>
> IIUC then there is nothing to change in this PR?

Yep, I believe we will specify the closed behavior of methods on reader in a separate RFE. Not to worry for this patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791790362

From liach at openjdk.org  Tue Oct  8 12:35:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 12:35:00 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
 <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
Message-ID: <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>

On Tue, 8 Oct 2024 12:08:06 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 174:
>> 
>>> 172: 
>>> 173:         return new Reader() {
>>> 174:             private final int length = cs.length();
>> 
>> Hello Markus, as far as I can see, a  `CharSequence` is allowed to have a non-fixed `length()` (typically allowed to increase?). Is there a reason why the length is captured at construction time instead of being evaluated during the read operations of the `Reader`?
>
> As the anonymous class MUST NOT be used with multiple threads, I always have seen the `CharSequence` as *fixed/static* text in the moment the `Reader` is getting used. But indeed, technically one could interleave `Reader::read()` invocations by `CharSequence.append()` (or even worse, `CharSequence.delete()`) invocations. The question is: Would that make *any* sense in the end? I mean, what happens if one has `read()` text that in the next step gets `delete()`'d? I cannot image *any* scenario where such a program would result in *useful* outcome.
> 
> &lt;fun>The fact that nobody so far (before you) brought up this question seems to proof that nobody (besides you) would write such a program. ? &lt;/fun>
> 
> So I would plea for clearly saying in the JavaDocs that `cs` MUST NOT be modified before `close()` is called. Every other solution implies strange side effects and slower and error-prone implementation of both, anoynous reader *and* test.
> 
> @AlanBateman WDYT?

I would treat this specific scenario as one of the "no concurrent usage" examples. Note that by this principle, mutable objects like `StringBuilder` should not override object comparison methods as these states can change, but they do :(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791787167

From jpai at openjdk.org  Tue Oct  8 12:35:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 12:35:00 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
 <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
 <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>
Message-ID: <kRXktNf1JWHEqBKKCHiBSC_tpAcEKuEhEstpVIf8ofI=.7e87860e-3de2-4ff2-90ca-f3759cc9e823@github.com>

On Tue, 8 Oct 2024 12:30:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As the anonymous class MUST NOT be used with multiple threads, I always have seen the `CharSequence` as *fixed/static* text in the moment the `Reader` is getting used. But indeed, technically one could interleave `Reader::read()` invocations by `CharSequence.append()` (or even worse, `CharSequence.delete()`) invocations. The question is: Would that make *any* sense in the end? I mean, what happens if one has `read()` text that in the next step gets `delete()`'d? I cannot image *any* scenario where such a program would result in *useful* outcome.
>> 
>> &lt;fun>The fact that nobody so far (before you) brought up this question seems to proof that nobody (besides you) would write such a program. ? &lt;/fun>
>> 
>> So I would plea for clearly saying in the JavaDocs that `cs` MUST NOT be modified before `close()` is called. Every other solution implies strange side effects and slower and error-prone implementation of both, anoynous reader *and* test.
>> 
>> @AlanBateman WDYT?
>
> I would treat this specific scenario as one of the "no concurrent usage" examples. Note that by this principle, mutable objects like `StringBuilder` should not override object comparison methods as these states can change, but they do :(

> The question is: Would that make any sense in the end?

Consider the example of `StringBuffer`, which is a `CharSequence`. Wouldn't something like the following be a logical use of `Reader.of(CharSequence)`, where you create a `Reader` for the underlying sequence (which is not yet populated) and then keep reading through the `Reader` until the underlying sequence's data is finished?


final StringBuffer sb = new StringBuffer();
try (final Reader reader = Reader.of(sb)) {
    final ContentGenerator cg = new ContentGenerator(sb);
    Thread.ofPlatform().start(cg);
    int numRead = 0;
    while (numRead != -1) {
        final char[] content = new char[1024];
        numRead = reader.read(content); // wait for content
    }
}

private class ContentGenerator {
    final StringBuffer sb;
    ContentGenerator(StringBuffer sb) {
        this.sb = sb;
    }

    @Override
    run() {
        while (true) {
            String foo = getSomeContent(); // maybe blocking
            sb.append(foo);
        }
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791789988

From liach at openjdk.org  Tue Oct  8 12:40:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 12:40:58 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <4pOPvBKs10oYjNcA-kUlbEZA18jA1MPsqNRv5cGiaiU=.e2771429-fcf8-4a61-988c-ed6b5f3cd784@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <b58kFBc8j-KafmiXDBkL79_7AaFYrotfS_bNb92Zpto=.9a61c0b8-f621-4919-b25e-6560b1f0219b@github.com>
 <4pOPvBKs10oYjNcA-kUlbEZA18jA1MPsqNRv5cGiaiU=.e2771429-fcf8-4a61-988c-ed6b5f3cd784@github.com>
Message-ID: <a7026pBCp3iCoDp9Dq8AfiFpMDmviKlh3k9VveUuBKc=.9d12172e-3b5e-4ca3-bcc9-3c86e3fe9fca@github.com>

On Tue, 8 Oct 2024 11:59:03 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 155:
>> 
>>> 153:      * have no effect.
>>> 154:      *
>>> 155:      * <p> After the reader has been closed, the {@code read()},
>> 
>> The API docs in 5cbc0450 looks okay. One minor comment is that "After the reader has been closed ..." doesn't need to be a new paragraph as it's part of the lifecycle topic in the previous paragraph.
>
> IIUC I shall just remove the `<p>` but keep the text `After the reader...`?

Yep. Better keep everything about closing in the same paragraph.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791798714

From jpai at openjdk.org  Tue Oct  8 12:49:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Oct 2024 12:49:59 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <kRXktNf1JWHEqBKKCHiBSC_tpAcEKuEhEstpVIf8ofI=.7e87860e-3de2-4ff2-90ca-f3759cc9e823@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
 <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
 <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>
 <kRXktNf1JWHEqBKKCHiBSC_tpAcEKuEhEstpVIf8ofI=.7e87860e-3de2-4ff2-90ca-f3759cc9e823@github.com>
Message-ID: <BF9tP3Qy6N1xub8xyjky5ZfSideN1833h4R3XNg6uao=.9b62fee2-f5f6-4082-b78a-273029189e34@github.com>

On Tue, 8 Oct 2024 12:32:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I would treat this specific scenario as one of the "no concurrent usage" examples. Note that by this principle, mutable objects like `StringBuilder` should not override object comparison methods as these states can change, but they do :(
>
>> The question is: Would that make any sense in the end?
> 
> Consider the example of `StringBuffer`, which is a `CharSequence`. Wouldn't something like the following be a logical use of `Reader.of(CharSequence)`, where you create a `Reader` for the underlying sequence (which is not yet populated) and then keep reading through the `Reader` until the underlying sequence's data is finished?
> 
> 
> final StringBuffer sb = new StringBuffer();
> try (final Reader reader = Reader.of(sb)) {
>     final ContentGenerator cg = new ContentGenerator(sb);
>     Thread.ofPlatform().start(cg);
>     int numRead = 0;
>     while (numRead != -1) {
>         final char[] content = new char[1024];
>         numRead = reader.read(content); // wait for content
>     }
> }
> 
> private class ContentGenerator {
>     final StringBuffer sb;
>     ContentGenerator(StringBuffer sb) {
>         this.sb = sb;
>     }
> 
>     @Override
>     run() {
>         while (true) {
>             String foo = getSomeContent(); // maybe blocking
>             sb.append(foo);
>         }
>     }
> }

>  I cannot image any scenario where such a program would result in useful outcome.

An additional point of reference is the current default implementation of CharSequence's `public default IntStream chars()`, which returns an IntStream of char values from the sequence and the implementation of which doesn't consider the `length()` to be fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791811620

From liach at openjdk.org  Tue Oct  8 13:01:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 13:01:00 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <BF9tP3Qy6N1xub8xyjky5ZfSideN1833h4R3XNg6uao=.9b62fee2-f5f6-4082-b78a-273029189e34@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
 <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
 <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>
 <kRXktNf1JWHEqBKKCHiBSC_tpAcEKuEhEstpVIf8ofI=.7e87860e-3de2-4ff2-90ca-f3759cc9e823@github.com>
 <BF9tP3Qy6N1xub8xyjky5ZfSideN1833h4R3XNg6uao=.9b62fee2-f5f6-4082-b78a-273029189e34@github.com>
Message-ID: <yTDgfvNrZU1d4Iug9uzoYC7Ur6rfnZFLLrEYzlMsq_U=.d1f7c76a-51c3-4dc8-ad40-32c9665cea59@github.com>

On Tue, 8 Oct 2024 12:46:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> The question is: Would that make any sense in the end?
>> 
>> Consider the example of `StringBuffer`, which is a `CharSequence`. Wouldn't something like the following be a logical use of `Reader.of(CharSequence)`, where you create a `Reader` for the underlying sequence (which is not yet populated) and then keep reading through the `Reader` until the underlying sequence's data is finished?
>> 
>> 
>> final StringBuffer sb = new StringBuffer();
>> try (final Reader reader = Reader.of(sb)) {
>>     final ContentGenerator cg = new ContentGenerator(sb);
>>     Thread.ofPlatform().start(cg);
>>     int numRead = 0;
>>     while (numRead != -1) {
>>         final char[] content = new char[1024];
>>         numRead = reader.read(content); // wait for content
>>     }
>> }
>> 
>> private class ContentGenerator {
>>     final StringBuffer sb;
>>     ContentGenerator(StringBuffer sb) {
>>         this.sb = sb;
>>     }
>> 
>>     @Override
>>     run() {
>>         while (true) {
>>             String foo = getSomeContent(); // maybe blocking
>>             sb.append(foo);
>>         }
>>     }
>> }
>
>>  I cannot image any scenario where such a program would result in useful outcome.
> 
> An additional point of reference is the current default implementation of CharSequence's `public default IntStream chars()`, which returns an IntStream of char values from the sequence and the implementation of which doesn't consider the `length()` to be fixed.

For `chars()` or `codePoints()`, I believe calling `length()` or not was a matter of implementation convenience instead of the assumption that `length()` can change during calls. Note implementation methods in the anonymous class in `codePoints()` cache the length in local variables. Maybe they just don't want the extra field overhead in the objects they construct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791830179

From alanb at openjdk.org  Tue Oct  8 13:26:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Oct 2024 13:26:01 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <yTDgfvNrZU1d4Iug9uzoYC7Ur6rfnZFLLrEYzlMsq_U=.d1f7c76a-51c3-4dc8-ad40-32c9665cea59@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
 <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
 <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>
 <kRXktNf1JWHEqBKKCHiBSC_tpAcEKuEhEstpVIf8ofI=.7e87860e-3de2-4ff2-90ca-f3759cc9e823@github.com>
 <BF9tP3Qy6N1xub8xyjky5ZfSideN1833h4R3XNg6uao=.9b62fee2-f5f6-4082-b78a-273029189e34@github.com>
 <yTDgfvNrZU1d4Iug9uzoYC7Ur6rfnZFLLrEYzlMsq_U=.d1f7c76a-51c3-4dc8-ad40-32c9665cea59@github.com>
Message-ID: <_VSLUFJJhDuKwt62-0OR8QYXBd3Q5DvxhdpgqfasGPI=.8cf22f15-0a68-4868-86f3-81a7bae65510@github.com>

On Tue, 8 Oct 2024 12:58:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>>>  I cannot image any scenario where such a program would result in useful outcome.
>> 
>> An additional point of reference is the current default implementation of CharSequence's `public default IntStream chars()`, which returns an IntStream of char values from the sequence and the implementation of which doesn't consider the `length()` to be fixed.
>
> For `chars()` or `codePoints()`, I believe calling `length()` or not was a matter of implementation convenience instead of the assumption that `length()` can change during calls. Note implementation methods in the anonymous class in `codePoints()` cache the length in local variables. Maybe they just don't want the extra field overhead in the objects they construct.

> @AlanBateman WDYT?

It's good question as a CharSequence's length can change over time, e.g. StringBuilder. This scenario comes up regularly with InputStreams and Readers connected to files as the file may be growing and shrinking as bytes are read. It would not be surprising to read to EOF/-1 and to not read any further chars, even if the underlying sequence has grow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1791870741

From mbaesken at openjdk.org  Tue Oct  8 13:44:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Oct 2024 13:44:12 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux with
 toolchain clang
Message-ID: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>

There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

-------------

Commit messages:
 - JDK-8341722

Changes: https://git.openjdk.org/jdk/pull/21407/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21407&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341722
  Stats: 9 lines in 4 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21407/head:pull/21407

PR: https://git.openjdk.org/jdk/pull/21407

From ihse at openjdk.org  Tue Oct  8 13:49:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 13:49:58 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <ejiJS3IevGl1IR-9khJDuWurNucJfwZinz3VxPasBU4=.6a67be67-b161-451f-8424-5e4b9ca275ed@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <xZHRfRmcxI5Nm_rsC5Ev9XFDVJWiCfi6XYl5mb6mdGI=.9cfc12bb-5d33-4ec1-a932-9fbd1e63a60b@github.com>
 <MwSkfKBC2IM1CqykyIBCo5u5E1SHMq_U5feJoruqCxk=.685225f5-90a0-4e5b-82de-ad88bcbdad4d@github.com>
 <ejiJS3IevGl1IR-9khJDuWurNucJfwZinz3VxPasBU4=.6a67be67-b161-451f-8424-5e4b9ca275ed@github.com>
Message-ID: <b5LSbC-O5u3_hOh3aaeNCOQQkIKBKEMhLeUPzKjJMvo=.3218a990-e872-4715-8521-0440ea638538@github.com>

On Tue, 8 Oct 2024 11:58:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We are running it for some weeks now at least once a week in our central builds/tests (so far only on Linux x86_64).

That is good to hear. Kudos to you for all your hard work on getting it there!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2399899161

From ihse at openjdk.org  Tue Oct  8 14:51:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 14:51:07 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: <trKpuI8_8X3YZ1W6HJNNJYI3wbpLdkBbA49UUl9kvZU=.a1351ef4-30e3-4b9e-8df3-f97646592f97@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

Build changes still look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2354745100

From swen at openjdk.org  Tue Oct  8 15:33:13 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 15:33:13 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
Message-ID: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>

A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

-------------

Commit messages:
 - Use global cache, don't need per-instance array
 - Merge remote-tracking branch 'upstream/master' into optim_inner_class_lamba_meta_factory_202410
 - suggestion from @liach
 - optimize InnerClassLambdaMetafactory init

Changes: https://git.openjdk.org/jdk/pull/21399/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341755
  Stats: 39 lines in 1 file changed: 23 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21399/head:pull/21399

PR: https://git.openjdk.org/jdk/pull/21399

From liach at openjdk.org  Tue Oct  8 15:33:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 15:33:13 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
In-Reply-To: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
Message-ID: <AQ5abIX7K0dvY2nxxz6_hP0Ax0IXQ9dS58FV03iZVWI=.5426b5b3-d0f9-4ba3-9a62-ba5769c590ae@github.com>

On Tue, 8 Oct 2024 00:47:27 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

`argNames[i]` is always `"arg$" + (i + 1)`. Maybe we can change all `argNames[x]` usage to a method like:

public static String argName(int i) {
    if (i < 8)
        return ARG_NAME_CACHE[i];
    return "arg$" + (i + 1);
}

Can we change the name to "Optimize argNames in InnerClassLambdaMetafactory"?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21399#issuecomment-2398382531
PR Comment: https://git.openjdk.org/jdk/pull/21399#issuecomment-2400146805

From jlahoda at openjdk.org  Tue Oct  8 15:33:32 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Oct 2024 15:33:32 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints about
 JShell
Message-ID: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@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` launcher, 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 launcher 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:

$ java
openjdk 24-internal 2025-03-18

Usage: java [options...] <what to execute> [arguments to main method...]

Where <what to execute> is one of:
  <MainClass>                to execute the main method of a compiled class
  -jar <jar-file.jar>        to execute the main class in a JAR archive
  -m <module>[/<MainClass>]  to execute the main class of a module
  <SourceFile.java>          to compile and execute a single-file program

Where key options include:
  --class-path <class path>
      a : separated list of directories and JAR archives to search for class files
  --module-path <module path>
      a : separated list of directories and JAR archives to search for modules

For more details about this launcher:   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!

-------------

Commit messages:
 - Cleanup.
 - Adjusting/improving the concise help.
 - Attempting to make the java launcher message consice, and let it refer to JShell.

Changes: https://git.openjdk.org/jdk/pull/21411/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340133
  Stats: 54 lines in 6 files changed: 49 ins; 0 del; 5 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  Tue Oct  8 15:41:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 8 Oct 2024 15:41:01 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell
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: <YppxZnLfQP_sxc5bWKJiVtyT10-t6VPAuK9rz0ST2PY=.36fff337-c25f-42c2-80dc-e066910534b9@github.com>

On Tue, 8 Oct 2024 15:28:17 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` launcher, 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 launcher 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:
> 
> $ java
> openjdk 24-internal 2025-03-18
> 
> Usage: java [options...] <what to execute> [arguments to main method...]
> 
> Where <what to execute> is one of:
>   <MainClass>                to execute the main method of a compiled class
>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>   -m <module>[/<MainClass>]  to execute the main class of a module
>   <SourceFile.java>          to compile and execute a single-file program
> 
> Where key options include:
>   --class-path <class path>
>       a : separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a : separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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!

Yay! This looks so much better than the default blob. I think you are on the right track, but the actual message can do with some fine tuning. For instance, `<what to execute>` seems a bit ... untypically non-formal. What about just `<target>`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2400192734

From swen at openjdk.org  Tue Oct  8 15:52:35 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 15:52:35 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v2]
In-Reply-To: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
Message-ID: <7W1ZriqGvyB45kQbqMZIgya0r0almU99ryDQHxgF_54=.77f22662-6642-49e2-b69b-86b5b8454ddf@github.com>

> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Lazy initialization of ARG_NAME_CACHE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21399/files
  - new: https://git.openjdk.org/jdk/pull/21399/files/a28f856b..96244330

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=00-01

  Stats: 15 lines in 1 file changed: 1 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21399/head:pull/21399

PR: https://git.openjdk.org/jdk/pull/21399

From liach at openjdk.org  Tue Oct  8 16:01:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 16:01:59 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v2]
In-Reply-To: <7W1ZriqGvyB45kQbqMZIgya0r0almU99ryDQHxgF_54=.77f22662-6642-49e2-b69b-86b5b8454ddf@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <7W1ZriqGvyB45kQbqMZIgya0r0almU99ryDQHxgF_54=.77f22662-6642-49e2-b69b-86b5b8454ddf@github.com>
Message-ID: <T_0otxUsnr7WK8ryhDptQvR_MW5K6VdkrPJ3Jn8DHaM=.42f2e616-d6dc-4e09-a624-976a8a50d938@github.com>

On Tue, 8 Oct 2024 15:52:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lazy initialization of ARG_NAME_CACHE

Looks good. Since I have contributed I think we need another review, such as @cl4es.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21399#pullrequestreview-2354929271

From jlu at openjdk.org  Tue Oct  8 16:32:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Oct 2024 16:32:06 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b [v2]
In-Reply-To: <FiTyMuhCLrFwNYA48M_t15wfLm1x3NWVar6Doeopd7Q=.09e84944-bb27-475d-94eb-84bf6bb5a9fc@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
 <FiTyMuhCLrFwNYA48M_t15wfLm1x3NWVar6Doeopd7Q=.09e84944-bb27-475d-94eb-84bf6bb5a9fc@github.com>
Message-ID: <wJ7afs0FX4gLcT-F0XYQJHXK2mf6CxyzFPAqyWriYE0=.a8f052a1-e164-408d-91da-c2aaf6e6135d@github.com>

On Tue, 1 Oct 2024 18:16:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Johny Jose has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review changes
>
> src/java.base/share/classes/java/time/ZoneId.java line 191:
> 
>> 189:      * This map contains a mapping of the IDs that is in line with TZDB 2024b and
>> 190:      * later, where 'EST', 'MST' and 'HST' map to IDs which do not include daylight
>> 191:      * savings since 1970.
> 
> Hi Johny, the future flexibility clause seems to be missing in the spec update of ZoneId.

Thanks for the changes in https://github.com/openjdk/jdk/pull/21265/commits/c3238444b63cb87c61f2503cbb1b5b7452181533.

Can we also add the following to the ZoneId specification,

Suggestion:

     * savings since 1970. This mapping may change in update releases in support of new versions of TZDB.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21265#discussion_r1792184364

From cjplummer at openjdk.org  Tue Oct  8 16:32:59 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 8 Oct 2024 16:32:59 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
Message-ID: <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>

On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 393:

> 391: 
> 392:       hcreate_r(htab_sz, symtab->hash_table);
> 393:       // guarantee(rslt, "unexpected failure: hcreate_r");

The commented out guarantee line references rslt. I'm not so sure why it was commented out, but it goes back to the initial load of the file 17 years ago. It looks like the correct thing to do if rslt is null is to "goto bad;" but that change is probably beyond the scope of this PR. Maybe file a new CR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1792185871

From psandoz at openjdk.org  Tue Oct  8 16:40:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 8 Oct 2024 16:40:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v22]
In-Reply-To: <hTNfN3mdbuIvNUqr1DV48gpKQP-RFOInpRktdAvi1YE=.2804ce60-a7b3-4a49-a3fe-10c8e5e3f2ec@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <hTNfN3mdbuIvNUqr1DV48gpKQP-RFOInpRktdAvi1YE=.2804ce60-a7b3-4a49-a3fe-10c8e5e3f2ec@github.com>
Message-ID: <JoZsJYyhpqnavTrbcULlOVUj9bU36I-BzD4c-M4xVLs=.b1f11a41-2241-4910-86b1-196726d97d40@github.com>

On Fri, 4 Oct 2024 00:01:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update VectorMath.java

Java changes look good (see comments to fix some typos). Needs another HotSpot reviewer.

Marked as reviewed by psandoz (Reviewer).

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 275:

> 273:      * @param b the second operand.
> 274:      * @return the saturating addition of the operands.
> 275:      * @see VectorOperators#SADD

Suggestion:

     * @see VectorOperators#SUADD

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 301:

> 299:      * @param b the second operand.
> 300:      * @return the saturating difference of the operands.
> 301:      * @see VectorOperators#SSUB

Suggestion:

     * @see VectorOperators#SUSUB

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 413:

> 411:      * @param b the second operand.
> 412:      * @return the saturating addition of the operands.
> 413:      * @see VectorOperators#SADD

Suggestion:

     * @see VectorOperators#SUADD

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 439:

> 437:      * @param b the second operand.
> 438:      * @return the saturating difference of the operands.
> 439:      * @see VectorOperators#SSUB

Suggestion:

     * @see VectorOperators#SUSUB

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 551:

> 549:      * @param b the second operand.
> 550:      * @return the saturating addition of the operands.
> 551:      * @see VectorOperators#SADD

Suggestion:

     * @see VectorOperators#SUADD

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 577:

> 575:      * @param b the second operand.
> 576:      * @return the saturating difference of the operands.
> 577:      * @see VectorOperators#SSUB

Suggestion:

     * @see VectorOperators#SUSUB

-------------

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2354993291
PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2355019508
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792178593
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792178872
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792179260
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792179485
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792179780
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1792180281

From psandoz at openjdk.org  Tue Oct  8 17:13:10 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 8 Oct 2024 17:13:10 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v16]
In-Reply-To: <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <3OXPOIGRRD4KoZ21PsL1viyEDvZsh_8GtacPQHcuQq4=.e5f4f05d-d21f-4a6c-b41e-c78268b8e2fe@github.com>
Message-ID: <DKnd321onRNE_6ejF24rlrlbBvyeSh8AcyyVlsJZ-xE=.f0f38b83-09a8-4f21-b443-e9b4d89540fc@github.com>

On Thu, 3 Oct 2024 19:05:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sharpening intrinsic exit check.

test/jdk/jdk/incubator/vector/templates/Unit-header.template line 408:

> 406:                 for (j = 0; j < vector_len; j++) {
> 407:                     idx = i + j;
> 408:                     wrapped_index =(((int)order[idx]) & (2 * vector_len -1));

This assumes a power of two, can we change to use `Math.floorMod`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1792232986

From rsunderbabu at openjdk.org  Tue Oct  8 17:16:10 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 8 Oct 2024 17:16:10 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java now()
 to be more robust
Message-ID: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>

The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.

Testing: The test was run for 100 times with -Xcomp option.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/21413/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21413&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324672
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21413/head:pull/21413

PR: https://git.openjdk.org/jdk/pull/21413

From naoto at openjdk.org  Tue Oct  8 17:18:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Oct 2024 17:18:05 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b [v2]
In-Reply-To: <bTYv37ev9W1rMPjxrmzDuIJxz8f53id5GzfpTDeEFC0=.af504bb0-6f48-4e6d-8fc9-c341e6e7a06f@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
 <bTYv37ev9W1rMPjxrmzDuIJxz8f53id5GzfpTDeEFC0=.af504bb0-6f48-4e6d-8fc9-c341e6e7a06f@github.com>
Message-ID: <aiKgGeidaMAEi3ClmeOZovz6KwVgi6qHMWut0qn2TII=.916b2e88-0fb3-4868-91a7-38b0deffaf74@github.com>

On Tue, 1 Oct 2024 18:40:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Johny Jose has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review changes
>
> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 290:
> 
>> 288: 
>> 289:         if (l1.equals(l2)) {
>> 290:             System.out.println("no diff");
> 
> Is this needed? IIUC `diff` is only called if the array contents are not equal.

Since `diff` is a generic debug function, equality check needed to be in the function itself. Anyway, I wrote this code for purely debug purpose, so can be removed altogether.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21265#discussion_r1792238867

From naoto at openjdk.org  Tue Oct  8 17:49:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Oct 2024 17:49:02 GMT
Subject: RFR: 8341484: TimeZone.toZoneId() throws exception when using old
 mapping for "HST"
In-Reply-To: <UnvFa2tl5Dgm0gViyWpN0IOnAV_TF5AxKfBvP782cQ4=.736933d1-33cc-43e3-83bc-090ef5ec4635@github.com>
References: <UnvFa2tl5Dgm0gViyWpN0IOnAV_TF5AxKfBvP782cQ4=.736933d1-33cc-43e3-83bc-090ef5ec4635@github.com>
Message-ID: <2iMmLNTxsUnKJtWpuQ4kvfxXf5RemJtIgwPHi-zTfXo=.4cc2da6b-0ad0-4a0a-ac0b-e3ceed8fe11a@github.com>

On Thu, 3 Oct 2024 19:46:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes an unexpected exception for `TimeZone.toZoneId("HST")` when the old mapping system property is used.
> 
> The culprit is in `TimeZone.toZoneId0()`.
> 
> This method provides workarounds for "EST", "MST", and "HST" when the old mapping system property is true. However, it seems that "HST" was added with "America/Honolulu" when it should have been "Pacific/Honolulu".
> 
> Added a basic test.

This is indeed surprising that this has not been revealed by now. I guess nobody used this old mapping before... Anyway, I am now trying to get rid of this old mapping behavior altogether (https://bugs.openjdk.org/browse/JDK-8340477), so the entire code will be gone.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21332#issuecomment-2400469928

From redestad at openjdk.org  Tue Oct  8 17:52:00 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 17:52:00 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v2]
In-Reply-To: <7W1ZriqGvyB45kQbqMZIgya0r0almU99ryDQHxgF_54=.77f22662-6642-49e2-b69b-86b5b8454ddf@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <7W1ZriqGvyB45kQbqMZIgya0r0almU99ryDQHxgF_54=.77f22662-6642-49e2-b69b-86b5b8454ddf@github.com>
Message-ID: <8QsurVWzpQC6K3tHgX7OhWebOPJfB2tPHcheZ64eNpc=.60b9eb45-2154-4147-8e33-b66cdbb69b94@github.com>

On Tue, 8 Oct 2024 15:52:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lazy initialization of ARG_NAME_CACHE

Looks reasonable

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 193:

> 191:         String argName = i < ARG_NAME_CACHE_SIZE ? ARG_NAME_CACHE[i] : null;
> 192:         if (argName == null) {
> 193:             argName = "arg$".concat(Integer.toString(i + 1));

With `Integer.toString` in the mix perhaps just as well keep this as a standard concat?
Suggestion:

            argName = "arg$" + (i + 1);

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21399#pullrequestreview-2355130507
PR Review Comment: https://git.openjdk.org/jdk/pull/21399#discussion_r1792264161

From jlu at openjdk.org  Tue Oct  8 18:05:05 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Oct 2024 18:05:05 GMT
Subject: RFR: 8341484: TimeZone.toZoneId() throws exception when using old
 mapping for "HST"
In-Reply-To: <2iMmLNTxsUnKJtWpuQ4kvfxXf5RemJtIgwPHi-zTfXo=.4cc2da6b-0ad0-4a0a-ac0b-e3ceed8fe11a@github.com>
References: <UnvFa2tl5Dgm0gViyWpN0IOnAV_TF5AxKfBvP782cQ4=.736933d1-33cc-43e3-83bc-090ef5ec4635@github.com>
 <2iMmLNTxsUnKJtWpuQ4kvfxXf5RemJtIgwPHi-zTfXo=.4cc2da6b-0ad0-4a0a-ac0b-e3ceed8fe11a@github.com>
Message-ID: <4ZLhJc26QEspWXrvmSWxVYlw1aIe1UCHvVuNWpxIZhM=.2f2ca03d-b55f-4295-8c14-31847f245153@github.com>

On Tue, 8 Oct 2024 17:46:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is indeed surprising that this has not been revealed by now. I guess nobody used this old mapping before... Anyway, I am now trying to get rid of this old mapping behavior altogether (https://bugs.openjdk.org/browse/JDK-8340477), so the entire code will be gone.

I guess the fact this behavior has not been discovered further supports the change that we can remove the workaround altogether. Will close out this PR and issue then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21332#issuecomment-2400499127

From jlu at openjdk.org  Tue Oct  8 18:05:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Oct 2024 18:05:06 GMT
Subject: Withdrawn: 8341484: TimeZone.toZoneId() throws exception when using
 old mapping for "HST"
In-Reply-To: <UnvFa2tl5Dgm0gViyWpN0IOnAV_TF5AxKfBvP782cQ4=.736933d1-33cc-43e3-83bc-090ef5ec4635@github.com>
References: <UnvFa2tl5Dgm0gViyWpN0IOnAV_TF5AxKfBvP782cQ4=.736933d1-33cc-43e3-83bc-090ef5ec4635@github.com>
Message-ID: <tFxL4Y0owaAjqAm4fOSrmY-lifXcDuzldbucLJu5I7o=.f5d48c78-25f5-4d73-8528-778b459b17b2@github.com>

On Thu, 3 Oct 2024 19:46:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes an unexpected exception for `TimeZone.toZoneId("HST")` when the old mapping system property is used.
> 
> The culprit is in `TimeZone.toZoneId0()`.
> 
> This method provides workarounds for "EST", "MST", and "HST" when the old mapping system property is true. However, it seems that "HST" was added with "America/Honolulu" when it should have been "Pacific/Honolulu".
> 
> Added a basic test.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21332

From duke at openjdk.org  Tue Oct  8 18:05:44 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 18:05:44 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v5]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <9vavxhCKRQuf8gDlG7koUyxTJ-ybffVjKY9WYEypogo=.8ae4a9cc-2a6a-48a7-b68b-b57d46929c84@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with two additional commits since the last revision:

 - Looking up cs.length() always, not keeping fixed length
 - Removed <p> to keep everything about closing in the same paragraph

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/5cbc0450..7d285bec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=03-04

  Stats: 11 lines in 1 file changed: 2 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From liach at openjdk.org  Tue Oct  8 18:06:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 18:06:02 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v2]
In-Reply-To: <8QsurVWzpQC6K3tHgX7OhWebOPJfB2tPHcheZ64eNpc=.60b9eb45-2154-4147-8e33-b66cdbb69b94@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <7W1ZriqGvyB45kQbqMZIgya0r0almU99ryDQHxgF_54=.77f22662-6642-49e2-b69b-86b5b8454ddf@github.com>
 <8QsurVWzpQC6K3tHgX7OhWebOPJfB2tPHcheZ64eNpc=.60b9eb45-2154-4147-8e33-b66cdbb69b94@github.com>
Message-ID: <l4OmSukAatMQVV1an6Y16by6p1wGCmePIJazMzzmqQc=.73beccfe-f844-4492-885d-eb65dd27d4ec@github.com>

On Tue, 8 Oct 2024 17:35:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lazy initialization of ARG_NAME_CACHE
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 193:
> 
>> 191:         String argName = i < ARG_NAME_CACHE_SIZE ? ARG_NAME_CACHE[i] : null;
>> 192:         if (argName == null) {
>> 193:             argName = "arg$".concat(Integer.toString(i + 1));
> 
> With `Integer.toString` in the mix perhaps just as well keep this as a standard concat?
> Suggestion:
> 
>             argName = "arg$" + (i + 1);

New bytecode in last commit's `computeArgName`:

         0: ldc           #186                // String arg$
         2: iload_0
         3: iconst_1
         4: iadd
         5: invokestatic  #188                // Method java/lang/Integer.toString:(I)Ljava/lang/String;
         8: invokevirtual #193                // Method java/lang/String.concat:(Ljava/lang/String;)Ljava/lang/String;
        11: areturn


Old bytecode in constructor:

       222: iload         11
       224: new           #150                // class java/lang/StringBuilder
       227: dup
       228: invokespecial #152                // Method java/lang/StringBuilder."<init>":()V
       231: ldc           #155                // String arg$
       233: invokevirtual #157                // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
       236: iload         11
       238: iconst_1
       239: iadd
       240: invokevirtual #161                // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
       243: invokevirtual #164                // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
       246: aastore
       247: aload_0

I believe using concat is cleaner.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21399#discussion_r1792297029

From duke at openjdk.org  Tue Oct  8 18:09:00 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 18:09:00 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <a7026pBCp3iCoDp9Dq8AfiFpMDmviKlh3k9VveUuBKc=.9d12172e-3b5e-4ca3-bcc9-3c86e3fe9fca@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <b58kFBc8j-KafmiXDBkL79_7AaFYrotfS_bNb92Zpto=.9a61c0b8-f621-4919-b25e-6560b1f0219b@github.com>
 <4pOPvBKs10oYjNcA-kUlbEZA18jA1MPsqNRv5cGiaiU=.e2771429-fcf8-4a61-988c-ed6b5f3cd784@github.com>
 <a7026pBCp3iCoDp9Dq8AfiFpMDmviKlh3k9VveUuBKc=.9d12172e-3b5e-4ca3-bcc9-3c86e3fe9fca@github.com>
Message-ID: <iMbrCOMm-5HyWY2WH2nk5Elnu8JDzh8ifycRTMSNdog=.0802340f-630a-4eb4-bc92-52c6ab4f660d@github.com>

On Tue, 8 Oct 2024 12:38:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> IIUC I shall just remove the `<p>` but keep the text `After the reader...`?
>
> Yep. Better keep everything about closing in the same paragraph.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792259809

From duke at openjdk.org  Tue Oct  8 18:09:01 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 8 Oct 2024 18:09:01 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <_VSLUFJJhDuKwt62-0OR8QYXBd3Q5DvxhdpgqfasGPI=.8cf22f15-0a68-4868-86f3-81a7bae65510@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
 <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
 <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>
 <kRXktNf1JWHEqBKKCHiBSC_tpAcEKuEhEstpVIf8ofI=.7e87860e-3de2-4ff2-90ca-f3759cc9e823@github.com>
 <BF9tP3Qy6N1xub8xyjky5ZfSideN1833h4R3XNg6uao=.9b62fee2-f5f6-4082-b78a-273029189e34@github.com>
 <yTDgfvNrZU1d4Iug9uzoYC7Ur6rfnZFLLrEYzlMsq_U=.d1f7c76a-51c3-4dc8-ad40-32c9665cea59@github.com>
 <_VSLUFJJhDuKwt62-0OR8QYXBd3Q5DvxhdpgqfasGPI=.8cf22f15-0a68-4868-86f3-81a7bae65510@github.com>
Message-ID: <s0VZnbN4VkoY7DMLvb2CXMsgMRrbM5SGFMh_ElWILgk=.76d22034-65f5-458a-8f98-c294ff355cb3@github.com>

On Tue, 8 Oct 2024 13:23:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> For `chars()` or `codePoints()`, I believe calling `length()` or not was a matter of implementation convenience instead of the assumption that `length()` can change during calls. Note implementation methods in the anonymous class in `codePoints()` cache the length in local variables. Maybe they just don't want the extra field overhead in the objects they construct.
>
>> @AlanBateman WDYT?
> 
> It's good question as a CharSequence's length can change over time, e.g. StringBuilder. This scenario comes up regularly with InputStreams and Readers connected to files as the file may be growing and shrinking as bytes are read. It would not be surprising to read to EOF/-1 and to not read any further chars, even if the underlying sequence has grow.

I have updated the source code so that it looks up `cs.length()` live each time. Nevertheless, this does not necessarily imply any predictable outcome due to the natur of an interface: Custom implementations could concurrently replace already read characters, but we need to step on with `next` for each `read()`/`skip()`, and `CharSequence` itself does not provide any read cursor means (like files have with `position()`). Because of that, I have added a warning in the JavaDocs, paraphrased from `CharSequence::chars` and `CharSequence::codePoints`: `If the sequence is concurrently modified then the result is undefined.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792267271

From mchung at openjdk.org  Tue Oct  8 18:30:03 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 8 Oct 2024 18:30:03 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
Message-ID: <x7MTEJpurK6gmVssJh73bsRvW3Gfy1yXrHaiKBQlCtY=.363cff7d-ade9-4fa4-ab22-fafbd6c470fb@github.com>

On Tue, 8 Oct 2024 01:13:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - class or interface descriptor renamed for clarity
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Cleanup after merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Compile error
>  - Redundant import
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - 8338544: Dedicated Array class descriptor implementation

Looks good with minor suggestion.  I agree having a separate implementation class for array type and class/interface allows a cleaner subclass implementation.

src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 45:

> 43:  */
> 44: public final class ArrayClassDescImpl implements ClassDesc {
> 45:     private final ClassDesc element;

Suggestion:

    private final ClassDesc elementType;

src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 81:

> 79:             throw new IllegalStateException(
> 80:                 "Cannot create an array type descriptor with more than "
> 81:                         + MAX_ARRAY_TYPE_DESC_DIMENSIONS + " dimensions");

Suggestion:

        ConstantUtils.validateArrayDepth(rank + 1);

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2355186246
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792299237
PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792314209

From mchung at openjdk.org  Tue Oct  8 18:32:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 8 Oct 2024 18:32:59 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v4]
In-Reply-To: <CsrcEvhoyJWWa4M_xLPfcgUL7K2Lbb-hv_kwW3PBYzE=.b2540caf-4880-4e76-a4bd-7ec1d59e6baa@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <CsrcEvhoyJWWa4M_xLPfcgUL7K2Lbb-hv_kwW3PBYzE=.b2540caf-4880-4e76-a4bd-7ec1d59e6baa@github.com>
Message-ID: <SLsYgOBIXvJXYOzuaUcfgTrHSivOuPM8D-gONC8CgIU=.350a4ed2-26cb-4ba9-8276-637303b173cb@github.com>

On Tue, 8 Oct 2024 01:36:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mandy's review - remove since JDK 24

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21380#pullrequestreview-2355237552

From swen at openjdk.org  Tue Oct  8 18:35:46 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 18:35:46 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v3]
In-Reply-To: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
Message-ID: <C9y5pN6s6Qp28T8LmDz42JJhFypygpSTigsNiOZF9cg=.ca7689bf-6cfe-48c8-be05-0a76d98b3920@github.com>

> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21399/files
  - new: https://git.openjdk.org/jdk/pull/21399/files/96244330..191bba08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21399/head:pull/21399

PR: https://git.openjdk.org/jdk/pull/21399

From redestad at openjdk.org  Tue Oct  8 18:35:46 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 18:35:46 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v2]
In-Reply-To: <l4OmSukAatMQVV1an6Y16by6p1wGCmePIJazMzzmqQc=.73beccfe-f844-4492-885d-eb65dd27d4ec@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <7W1ZriqGvyB45kQbqMZIgya0r0almU99ryDQHxgF_54=.77f22662-6642-49e2-b69b-86b5b8454ddf@github.com>
 <8QsurVWzpQC6K3tHgX7OhWebOPJfB2tPHcheZ64eNpc=.60b9eb45-2154-4147-8e33-b66cdbb69b94@github.com>
 <l4OmSukAatMQVV1an6Y16by6p1wGCmePIJazMzzmqQc=.73beccfe-f844-4492-885d-eb65dd27d4ec@github.com>
Message-ID: <GMiw3FnS4xt2EgZR8kEKhf4kldFZFlz_xuJEdgUQnb4=.c63ad866-80f1-4dad-946c-ff7063ff8829@github.com>

On Tue, 8 Oct 2024 18:03:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 193:
>> 
>>> 191:         String argName = i < ARG_NAME_CACHE_SIZE ? ARG_NAME_CACHE[i] : null;
>>> 192:         if (argName == null) {
>>> 193:             argName = "arg$".concat(Integer.toString(i + 1));
>> 
>> With `Integer.toString` in the mix perhaps just as well keep this as a standard concat?
>> Suggestion:
>> 
>>             argName = "arg$" + (i + 1);
>
> New bytecode in last commit's `computeArgName`:
> 
>          0: ldc           #186                // String arg$
>          2: iload_0
>          3: iconst_1
>          4: iadd
>          5: invokestatic  #188                // Method java/lang/Integer.toString:(I)Ljava/lang/String;
>          8: invokevirtual #193                // Method java/lang/String.concat:(Ljava/lang/String;)Ljava/lang/String;
>         11: areturn
> 
> 
> Old bytecode in constructor:
> 
>        222: iload         11
>        224: new           #150                // class java/lang/StringBuilder
>        227: dup
>        228: invokespecial #152                // Method java/lang/StringBuilder."<init>":()V
>        231: ldc           #155                // String arg$
>        233: invokevirtual #157                // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
>        236: iload         11
>        238: iconst_1
>        239: iadd
>        240: invokevirtual #161                // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
>        243: invokevirtual #164                // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
>        246: aastore
>        247: aload_0
> 
> I believe using concat is cleaner.

Irrelevant; idiomatic concatenation is more concise in source and easier to read, comprehend and check, so should generally be preferred. That the legacy javac concat translatiom is lousy for constant + primitive is a different matter.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21399#discussion_r1792328733

From mchung at openjdk.org  Tue Oct  8 18:38:01 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 8 Oct 2024 18:38:01 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v4]
In-Reply-To: <CsrcEvhoyJWWa4M_xLPfcgUL7K2Lbb-hv_kwW3PBYzE=.b2540caf-4880-4e76-a4bd-7ec1d59e6baa@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <CsrcEvhoyJWWa4M_xLPfcgUL7K2Lbb-hv_kwW3PBYzE=.b2540caf-4880-4e76-a4bd-7ec1d59e6baa@github.com>
Message-ID: <7oTQ9Q-LEmZ8w677fanxoRfN7oESwNa0-zTF2QuxXyA=.0ae4e7b9-889b-4ec3-a447-6de8b023fcee@github.com>

On Tue, 8 Oct 2024 01:36:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mandy's review - remove since JDK 24

Should we leave the man page change be part of the bulk update near the end of the release?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21380#issuecomment-2400556954

From cushon at openjdk.org  Tue Oct  8 19:00:58 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 8 Oct 2024 19:00:58 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: <q9mzdhCsdFiWbmjvDFK4m1ytfWxH-6cJHBnZdTBQJd8=.76a0e34e-cf91-4538-8861-016c56c316c6@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>

Please keep this open for now

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2400599924

From liach at openjdk.org  Tue Oct  8 19:19:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 19:19:00 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <x7MTEJpurK6gmVssJh73bsRvW3Gfy1yXrHaiKBQlCtY=.363cff7d-ade9-4fa4-ab22-fafbd6c470fb@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
 <x7MTEJpurK6gmVssJh73bsRvW3Gfy1yXrHaiKBQlCtY=.363cff7d-ade9-4fa4-ab22-fafbd6c470fb@github.com>
Message-ID: <gR8of34alScpxrbk6yFBi4uyNxC0u1MsY8BJrjVkKuU=.9f9f21d1-54f5-4ace-82e8-1f52fd4da2a9@github.com>

On Tue, 8 Oct 2024 18:16:34 GMT, Mandy Chung <mchung 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 nine commits:
>> 
>>  - class or interface descriptor renamed for clarity
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>>  - Cleanup after merge
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>>  - Compile error
>>  - Redundant import
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>>  - 8338544: Dedicated Array class descriptor implementation
>
> src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 81:
> 
>> 79:             throw new IllegalStateException(
>> 80:                 "Cannot create an array type descriptor with more than "
>> 81:                         + MAX_ARRAY_TYPE_DESC_DIMENSIONS + " dimensions");
> 
> Suggestion:
> 
>         ConstantUtils.validateArrayDepth(rank + 1);

Unfortunately, this has to throw ISE while `validateArrayDepth` throws IAE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792386369

From jbhateja at openjdk.org  Tue Oct  8 19:25:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 8 Oct 2024 19:25:24 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v23]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'JDK-8338201' of http://github.com/jatin-bhateja/jdk into JDK-8338201
 - Update VectorMath.java
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Typographical error fixups
 - Doc fixups
 - Typographic error
 - Merge stashing and re-commit
 - Tuning extra spaces.
 - Tests for newly added VectorMath.* operations
 - Test cleanups.
 - ... and 16 more: https://git.openjdk.org/jdk/compare/7312eea3...ce76c3e5

-------------

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=22
  Stats: 9206 lines in 51 files changed: 8778 ins; 27 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From liach at openjdk.org  Tue Oct  8 19:32:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 19:32:34 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v3]
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  mlchung suggestions: elementType, improve utility methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20665/files
  - new: https://git.openjdk.org/jdk/pull/20665/files/a1d14186..f6964d1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=01-02

  Stats: 32 lines in 2 files changed: 9 ins; 4 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20665/head:pull/20665

PR: https://git.openjdk.org/jdk/pull/20665

From liach at openjdk.org  Tue Oct  8 19:32:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 19:32:36 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
Message-ID: <rDUkVlkDoNeKU1bHmtHxS1wWsHJFJ2oyqPf9R7rDOqE=.ad7f6360-f88f-4ca3-9ee8-4132dd467d7c@github.com>

On Tue, 8 Oct 2024 01:13:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - class or interface descriptor renamed for clarity
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Cleanup after merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Compile error
>  - Redundant import
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - 8338544: Dedicated Array class descriptor implementation

Thanks for the reviews; can anyone review the associated CSR at https://bugs.openjdk.org/browse/JDK-8340963 as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20665#issuecomment-2400661092

From liach at openjdk.org  Tue Oct  8 19:32:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 19:32:36 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <gR8of34alScpxrbk6yFBi4uyNxC0u1MsY8BJrjVkKuU=.9f9f21d1-54f5-4ace-82e8-1f52fd4da2a9@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
 <x7MTEJpurK6gmVssJh73bsRvW3Gfy1yXrHaiKBQlCtY=.363cff7d-ade9-4fa4-ab22-fafbd6c470fb@github.com>
 <gR8of34alScpxrbk6yFBi4uyNxC0u1MsY8BJrjVkKuU=.9f9f21d1-54f5-4ace-82e8-1f52fd4da2a9@github.com>
Message-ID: <LwHRUoqXkVWFhy4edYLtQXDPVWG6U_TpbSIYN2LjlOk=.507f43a0-7fd6-4a69-95eb-813d31050c3b@github.com>

On Tue, 8 Oct 2024 19:16:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java line 81:
>> 
>>> 79:             throw new IllegalStateException(
>>> 80:                 "Cannot create an array type descriptor with more than "
>>> 81:                         + MAX_ARRAY_TYPE_DESC_DIMENSIONS + " dimensions");
>> 
>> Suggestion:
>> 
>>         ConstantUtils.validateArrayDepth(rank + 1);
>
> Unfortunately, this has to throw ISE while `validateArrayDepth` throws IAE.

I have extracted this to a new utility method, with a switch on the thrown exception type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792400368

From liach at openjdk.org  Tue Oct  8 19:34:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 19:34:58 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v3]
In-Reply-To: <C9y5pN6s6Qp28T8LmDz42JJhFypygpSTigsNiOZF9cg=.ca7689bf-6cfe-48c8-be05-0a76d98b3920@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <C9y5pN6s6Qp28T8LmDz42JJhFypygpSTigsNiOZF9cg=.ca7689bf-6cfe-48c8-be05-0a76d98b3920@github.com>
Message-ID: <eVn-cyoxI9XV3mB8tYoildYTOWd3jeJipy0GFVYbSsI=.490617e3-f39a-4853-8d81-2a593d2316e6@github.com>

On Tue, 8 Oct 2024 18:35:46 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21399#pullrequestreview-2355366688

From liach at openjdk.org  Tue Oct  8 19:43:57 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 19:43:57 GMT
Subject: RFR: 8341548: More concise use of classfile API [v3]
In-Reply-To: <mXyMN_E7IPa7o0qpEItTWpXZAODEJ7qI5s0YamLud5c=.84264695-3119-475b-8c19-5b6309db6730@github.com>
References: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
 <mXyMN_E7IPa7o0qpEItTWpXZAODEJ7qI5s0YamLud5c=.84264695-3119-475b-8c19-5b6309db6730@github.com>
Message-ID: <OAAWIbQphTCdXCf4PwxXp7Unxgh_0hozxRmbGGtZGlM=.7566ed39-b7e3-46bb-b53f-0db279e7e8ff@github.com>

On Mon, 7 Oct 2024 01:25:31 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> java.base should provide best practices for Class File API
>> 
>> 1. Use fluent coding style
>> 2. Use aconst_null instead of oadConstant(null)
>> 3. use astore intead of 'storeLocal(REFERENCE'
>> 4. use aload instead of 'loadLocal(REFERENCE'
>> 5. 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(LONG)'
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more fluent coding style

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21355#pullrequestreview-2355382324

From mchung at openjdk.org  Tue Oct  8 19:44:58 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 8 Oct 2024 19:44:58 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v3]
In-Reply-To: <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
Message-ID: <5MJzVXplOUb-odJPDlLzwvrsnn4T4r2QjA69bbcP60E=.26701d57-80b1-4dc6-8713-8623ddf480d0@github.com>

On Tue, 8 Oct 2024 19:32:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mlchung suggestions: elementType, improve utility methods

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 313:

> 311:             throw new IllegalArgumentException("rank " + rank + " is not a positive value");
> 312:         }
> 313:     }

Suggest to inline the rank argument check in the caller method which makes the check explicit to the reader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792414077

From naoto at openjdk.org  Tue Oct  8 19:48:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Oct 2024 19:48:57 GMT
Subject: RFR: 8340488: Clarify LocaleServiceProvider deployment on
 application module path
In-Reply-To: <8_f0tTi0mlYkIlVcvmQdnvp2W8S_tgcV-ZC5sodPC1U=.b8dff2ab-b8a6-457f-901d-0bea567a65fb@github.com>
References: <8_f0tTi0mlYkIlVcvmQdnvp2W8S_tgcV-ZC5sodPC1U=.b8dff2ab-b8a6-457f-901d-0bea567a65fb@github.com>
Message-ID: <oTZM-Q39NtUs_ULG0mjfqnXpSU3CSCym2zwFq4V6caY=.f8d12002-4509-4709-8b60-5357775258e9@github.com>

On Tue, 1 Oct 2024 17:28:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8341285) which clarifies that a Locale sensitive service provider can be deployed as a module.
> 
> This mainly follows the same format as the work done for [JDK-8340404](https://bugs.openjdk.org/browse/JDK-8340404), by providing a brief example, and pointing to the Deploying Service Providers section under ServiceLoader.
> 
> There is no test added, since there already exists java.text tests that deploy SPIs as a module.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21294#pullrequestreview-2355390231

From mchung at openjdk.org  Tue Oct  8 19:49:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 8 Oct 2024 19:49:59 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v3]
In-Reply-To: <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
Message-ID: <VQQPIvUh0tcisLt9tDVX8vQ1u71dpUO-BgzRAXmfj2A=.decd3829-58a1-45d6-8349-8ea63fc2cff1@github.com>

On Tue, 8 Oct 2024 19:32:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mlchung suggestions: elementType, improve utility methods

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 281:

> 279:      *
> 280:      * @implSpec
> 281:      * <p>The implementations return the simple name

Suggestion:

     * <p>The implementation returns the simple name


I think this can be singular as it's not required to have more than 1 implementation class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792419383

From rriggs at openjdk.org  Tue Oct  8 19:54:01 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Oct 2024 19:54:01 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust
In-Reply-To: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
Message-ID: <DbUP95GxAnTQ2f-TTF65ooCYlMZsIb8yqTGxkaKsOMc=.7c53fb62-7607-4378-ad5c-f38aa8d1da47@github.com>

On Tue, 8 Oct 2024 17:10:43 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
> 
> Testing: The test was run for 100 times with -Xcomp option.

test/jdk/java/time/tck/java/time/TCKInstant.java line 193:

> 191:         Instant test = Instant.now();
> 192:         long diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
> 193:         assertTrue(diff < 10_000);  // less than 10 secs

Given arbitrary delays between the two executions; the premise of the test itself is suspect; especially if the allowed time is increased.  I think the test is supposed to be testing that the default clock for Instant.now() is the SystemUTC clock.
I'd expect expected to be less than or equal to test.
The use of math.abs allows the clock to go backwards; that might happen if the time was re-set manually.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1792423559

From rriggs at openjdk.org  Tue Oct  8 20:07:03 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Oct 2024 20:07:03 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v6]
In-Reply-To: <7Di2YTFOv-Q0OzRYMgHEfjP-K0LXYJnvTE7KZ0zFJ-g=.9afcf33b-9e18-4822-ae5e-6c91cb338ce4@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <7Di2YTFOv-Q0OzRYMgHEfjP-K0LXYJnvTE7KZ0zFJ-g=.9afcf33b-9e18-4822-ae5e-6c91cb338ce4@github.com>
Message-ID: <egkX7NVSjyy2kH0tOVrLJxTkVmKQGLN5bC6xiLxeXsY=.b232df4b-d7be-409f-a5c9-7cf1450aa191@github.com>

On Wed, 25 Sep 2024 12:58:20 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:
> 
>   Address review feedback

I think this is looking pretty good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2400721240

From redestad at openjdk.org  Tue Oct  8 20:21:58 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 20:21:58 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v3]
In-Reply-To: <C9y5pN6s6Qp28T8LmDz42JJhFypygpSTigsNiOZF9cg=.ca7689bf-6cfe-48c8-be05-0a76d98b3920@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <C9y5pN6s6Qp28T8LmDz42JJhFypygpSTigsNiOZF9cg=.ca7689bf-6cfe-48c8-be05-0a76d98b3920@github.com>
Message-ID: <ONCglyS1dt1rENamDQysLnPTbXTtnmYHlJ93DfI6fjA=.f2fdf9bc-80e5-43e3-a398-b995a735d01b@github.com>

On Tue, 8 Oct 2024 18:35:46 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21399#pullrequestreview-2355446348

From jvernee at openjdk.org  Tue Oct  8 20:29:03 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Oct 2024 20:29:03 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v2]
In-Reply-To: <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-9YzLS14d0jpvfgakfv37y3eINhhLL-0xPYzQXC0n8c=.0aa70a2c-7045-4f53-aa76-7b5b2665e16e@github.com>
Message-ID: <oClRVxQZCQnTU2-SgVuOjRUj0owXIqsBROWji_bX630=.7dd1f536-14a1-4508-a474-15429ede09c3@github.com>

On Tue, 8 Oct 2024 01:13:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - class or interface descriptor renamed for clarity
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Cleanup after merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Compile error
>  - Redundant import
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - 8338544: Dedicated Array class descriptor implementation

Latest version looks good

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2355460439

From naoto at openjdk.org  Tue Oct  8 20:33:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Oct 2024 20:33:58 GMT
Subject: RFR: 8341445: DecimalFormatSymbols can throw NPE for equals() [v2]
In-Reply-To: <e710dGskXiHkLRBCQpuuc0WWjHab84cIaTWPjtsp4a4=.909a2a04-0e27-47d3-80c2-62ee0f1ff280@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
 <e710dGskXiHkLRBCQpuuc0WWjHab84cIaTWPjtsp4a4=.909a2a04-0e27-47d3-80c2-62ee0f1ff280@github.com>
Message-ID: <2Yoj9EgR85m-ECZpvU_q8PwW3gJtm89hhx_bNLZVJ1E=.f261d2f1-eb40-4d48-a6da-2f2682d0d534@github.com>

On Thu, 3 Oct 2024 21:02:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols.
>> 
>> DecimalFormatSymbols via its setters, allows certain instance variables to be set as null. (Note that some variables are allowed to be null, and others are not.) However, non null safe comparisons are used for all variables during the equality check. This can lead to an unexpected NPE when `DecimalFormatSymbols.equals()` is invoked.
>> 
>> The nullable variables in question should be equality checked via the static `Object.equals()`. An associated regression test is added to confirm the change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address Chen's comment - provide a NPE setter whitelist in test

I am not sure allowing null for those setters just because not to throw exceptions in equals() is the right solutoin. The distinction is made purely based on the existing behavior (which I believe is just an overlook in the first place). My preference is to null check in the setter methods, as there is no reason to set them null. That is just a misuse of the setters.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21315#issuecomment-2400765289

From swen at openjdk.org  Tue Oct  8 20:38:03 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 20:38:03 GMT
Subject: Integrated: 8341548: More concise use of classfile API
In-Reply-To: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
References: <j5n6_wHm7PURD7U16ethgwo5HPqbTcE2wziHruVXWcM=.b3f110d5-10ba-4593-806b-fe8f739ef5bb@github.com>
Message-ID: <zFudv4jU1DROeDSO2nc_jY8OwaYD89lZFkEH-dH64qo=.d43988ad-df7a-49c9-8ab6-d0ea435f6dc0@github.com>

On Fri, 4 Oct 2024 12:05:02 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> java.base should provide best practices for Class File API
> 
> 1. Use fluent coding style
> 2. Use aconst_null instead of oadConstant(null)
> 3. use astore intead of 'storeLocal(REFERENCE'
> 4. use aload instead of 'loadLocal(REFERENCE'
> 5. 'lload/lstore' instead of 'loadLocal(LONG)/storeLocal(LONG)'

This pull request has now been integrated.

Changeset: 62acc9c1
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62acc9c174f23acd2807c8214ffc28d73799da16
Stats:     348 lines in 5 files changed: 6 ins; 25 del; 317 mod

8341548: More concise use of classfile API

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21355

From liach at openjdk.org  Tue Oct  8 20:48:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 20:48:58 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v3]
In-Reply-To: <VQQPIvUh0tcisLt9tDVX8vQ1u71dpUO-BgzRAXmfj2A=.decd3829-58a1-45d6-8349-8ea63fc2cff1@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
 <VQQPIvUh0tcisLt9tDVX8vQ1u71dpUO-BgzRAXmfj2A=.decd3829-58a1-45d6-8349-8ea63fc2cff1@github.com>
Message-ID: <iRFt-qY-krHSfsMQT_6qTgROk-7RKvD3peY5rHBlUMw=.f0229d81-a2a7-4470-80ae-cc3925d233b9@github.com>

On Tue, 8 Oct 2024 19:47:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mlchung suggestions: elementType, improve utility methods
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 281:
> 
>> 279:      *
>> 280:      * @implSpec
>> 281:      * <p>The implementations return the simple name
> 
> Suggestion:
> 
>      * <p>The implementation returns the simple name
> 
> 
> I think this can be singular as it's not required to have more than 1 implementation class.

Hmm, in fact, should we still have this `@implSpec` if we make this default?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792488546

From jlu at openjdk.org  Tue Oct  8 20:51:57 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Oct 2024 20:51:57 GMT
Subject: RFR: 8341445: DecimalFormatSymbols can throw NPE for equals() [v2]
In-Reply-To: <2Yoj9EgR85m-ECZpvU_q8PwW3gJtm89hhx_bNLZVJ1E=.f261d2f1-eb40-4d48-a6da-2f2682d0d534@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
 <e710dGskXiHkLRBCQpuuc0WWjHab84cIaTWPjtsp4a4=.909a2a04-0e27-47d3-80c2-62ee0f1ff280@github.com>
 <2Yoj9EgR85m-ECZpvU_q8PwW3gJtm89hhx_bNLZVJ1E=.f261d2f1-eb40-4d48-a6da-2f2682d0d534@github.com>
Message-ID: <fDtfZ8Qft7dskC8WHitnh-VyqqgkKS0WXaMk3I3PHfA=.6d40ce90-74e8-4039-afd2-48b9509cb18b@github.com>

On Tue, 8 Oct 2024 20:31:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I am not sure allowing null for those setters just because not to throw exceptions in equals() is the right solutoin. The distinction is made purely based on the existing behavior (which I believe is just an overlook in the first place). My preference is to null check in the setter methods, as there is no reason to set them null. That is just a misuse of the setters.

OK, if we are fine with the behavioral change, I will change the direction of this PR to instead be an update to the setters to ensure NPEs for the offending methods. Will file a CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21315#issuecomment-2400795454

From liach at openjdk.org  Tue Oct  8 20:59:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 20:59:00 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v25]
In-Reply-To: <7Y4K8fhMRRaLlg3jF__2poKiMRwKwHggUE0iepmjFbg=.6e67168d-968b-4981-8618-2d274bba3835@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <7Y4K8fhMRRaLlg3jF__2poKiMRwKwHggUE0iepmjFbg=.6e67168d-968b-4981-8618-2d274bba3835@github.com>
Message-ID: <pvk00kpmOT8To11A_SuB9CKwfXJLx5c8f-_64i7pQCE=.e0343221-17a0-44d5-8279-da5c46495d75@github.com>

On Tue, 8 Oct 2024 09:57:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Fold opcode.bytecode() in writeLoadConstant
>  - A few missed places, U1U2U2 seem common enough too to be included
>  - Rename writeUtfEntry
>  - Fold TAG_UTF8 write into writeUTF

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21243#pullrequestreview-2355521521

From mchung at openjdk.org  Tue Oct  8 21:09:58 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 8 Oct 2024 21:09:58 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v3]
In-Reply-To: <iRFt-qY-krHSfsMQT_6qTgROk-7RKvD3peY5rHBlUMw=.f0229d81-a2a7-4470-80ae-cc3925d233b9@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
 <VQQPIvUh0tcisLt9tDVX8vQ1u71dpUO-BgzRAXmfj2A=.decd3829-58a1-45d6-8349-8ea63fc2cff1@github.com>
 <iRFt-qY-krHSfsMQT_6qTgROk-7RKvD3peY5rHBlUMw=.f0229d81-a2a7-4470-80ae-cc3925d233b9@github.com>
Message-ID: <GC6WxAMHAB_IfCQNymgYCCIslHJVvXqK4mNjyLrhQPs=.20cd81e7-4ba9-4d2a-b6f6-53de95a29753@github.com>

On Tue, 8 Oct 2024 20:46:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 281:
>> 
>>> 279:      *
>>> 280:      * @implSpec
>>> 281:      * <p>The implementations return the simple name
>> 
>> Suggestion:
>> 
>>      * <p>The implementation returns the simple name
>> 
>> 
>> I think this can be singular as it's not required to have more than 1 implementation class.
>
> Hmm, in fact, should we still have this `@implSpec` if we make this default?

I think this can be dropped as `ClassDesc` as well.   It can say "This method returns....".   See what CSR review would say.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792509783

From liach at openjdk.org  Tue Oct  8 21:10:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 21:10:00 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v3]
In-Reply-To: <5MJzVXplOUb-odJPDlLzwvrsnn4T4r2QjA69bbcP60E=.26701d57-80b1-4dc6-8713-8623ddf480d0@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
 <5MJzVXplOUb-odJPDlLzwvrsnn4T4r2QjA69bbcP60E=.26701d57-80b1-4dc6-8713-8623ddf480d0@github.com>
Message-ID: <bj7FLJ29QdKbGbK1SEHpc11NQGMXcH7xLW15p1gKqn4=.18feb48a-b77e-46b4-b464-481ebe14d636@github.com>

On Tue, 8 Oct 2024 19:42:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   mlchung suggestions: elementType, improve utility methods
>
> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 313:
> 
>> 311:             throw new IllegalArgumentException("rank " + rank + " is not a positive value");
>> 312:         }
>> 313:     }
> 
> Suggest to inline the rank argument check in the caller method which makes the check explicit to the reader.

So like `if (rank <= 0) throw ConstantUtils.rankNotPositive(rank);` at individual use sites?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792507736

From mchung at openjdk.org  Tue Oct  8 21:15:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 8 Oct 2024 21:15:59 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v3]
In-Reply-To: <bj7FLJ29QdKbGbK1SEHpc11NQGMXcH7xLW15p1gKqn4=.18feb48a-b77e-46b4-b464-481ebe14d636@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
 <5MJzVXplOUb-odJPDlLzwvrsnn4T4r2QjA69bbcP60E=.26701d57-80b1-4dc6-8713-8623ddf480d0@github.com>
 <bj7FLJ29QdKbGbK1SEHpc11NQGMXcH7xLW15p1gKqn4=.18feb48a-b77e-46b4-b464-481ebe14d636@github.com>
Message-ID: <E08k_oGBlIEXC0c3Hpn06sJdDHeSnXTzejFCxS_2epQ=.b3fc2d7c-9ce2-41fb-a5ce-fd306156fcd6@github.com>

On Tue, 8 Oct 2024 21:04:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 313:
>> 
>>> 311:             throw new IllegalArgumentException("rank " + rank + " is not a positive value");
>>> 312:         }
>>> 313:     }
>> 
>> Suggest to inline the rank argument check in the caller method which makes the check explicit to the reader.
>
> So like `if (rank <= 0) throw ConstantUtils.rankNotPositive(rank);` at individual use sites?

I meant no need to have a utility method.   Just do this:

Suggestion:

    public static void validateArrayDepth(int rank) {
        if (rank <= 0) {
            throw new IllegalArgumentException("rank " + rank + " is not a positive value");
        }
        validateMaxArrayDepth(rank, true);
    }


Same change in `ArrayClassDescImpl::arrayType(int)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1792516398

From naoto at openjdk.org  Tue Oct  8 21:27:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Oct 2024 21:27:56 GMT
Subject: RFR: 8341658: RISC-V: Test DateFormatProviderTest.java run
 timeouted
In-Reply-To: <XjeBa45z_vYwst-etRxuo0rGc4QB_4nxsWEnFGtmTmw=.9c98106f-d3f7-4cc2-8179-9c54c24acc2d@github.com>
References: <XjeBa45z_vYwst-etRxuo0rGc4QB_4nxsWEnFGtmTmw=.9c98106f-d3f7-4cc2-8179-9c54c24acc2d@github.com>
Message-ID: <6r1rTuzM_OJlxHu6vkc27-B2zPqAWZD9NXpW5nTSbfc=.4ab89b3e-db81-4697-9e62-0c46f79e414d@github.com>

On Mon, 7 Oct 2024 15:49:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The test `java/util/PluggableLocale/DateFormatProviderTest.java` run timeout on riscv64 physic machine. This test has 4496 sub-tests, and riscv64 has poor single core performance, so this test run timeouted on riscv64 seems acceptable.
> Thus, to make less test noisy, I think we should add more timeout value for this test.
> Test-fix only, no risk.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21393#pullrequestreview-2355569490

From naoto at openjdk.org  Tue Oct  8 21:37:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Oct 2024 21:37:02 GMT
Subject: RFR: 8341366: Suspicious check in Locale.getDisplayName(Locale
 inLocale)
In-Reply-To: <mV3B1kRYE7kcvVEsIHe_4DcvT99kxlx0m7ELKGxZAfc=.166246cd-5fc2-4c0a-83e5-9e30a399ec1b@github.com>
References: <mV3B1kRYE7kcvVEsIHe_4DcvT99kxlx0m7ELKGxZAfc=.166246cd-5fc2-4c0a-83e5-9e30a399ec1b@github.com>
Message-ID: <OflU3dawX3AH_J2m6g-UWQdgj7bguEzNL69Xzz7IIlU=.f2bcf32d-dec4-4873-a537-4d55d4035de6@github.com>

On Tue, 1 Oct 2024 21:46:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which modifies a suspicious check in the fallback of `Locale.getDisplayName(Locale inLocale)`.
> 
> As a fallback, a hard coded pattern is used. The previous code outputted the qualifiers if the `displayNames` array had length greater than 2. Just a few lines above, the array is initialized with a length of 3 and so the check is pointless.
> 
> It would be better, if replaced with a null check for the last element of the `displayNames` array, as that element may be null if there are no qualifiers. See L2317 ,
> 
> `qualifierNames.length != 0 ? formatList(qualifierNames, listCompositionPattern) : null`
> 
> For example, now a fallback (with no qualifiers) might look like: `German` instead of `German (null)`.
> But will remain the same (with qualifiers): `German (Germany)`.

LGTM

src/java.base/share/classes/java/util/Locale.java line 2331:

> 2329:                 result.append(" (");
> 2330:                 result.append((String) displayNames[2]);
> 2331:                 result.append(')');

These `append`s can be chained, but probably it's my preference.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21298#pullrequestreview-2355583322
PR Review Comment: https://git.openjdk.org/jdk/pull/21298#discussion_r1792537903

From jlu at openjdk.org  Tue Oct  8 21:42:38 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Oct 2024 21:42:38 GMT
Subject: RFR: 8341366: Suspicious check in Locale.getDisplayName(Locale
 inLocale) [v2]
In-Reply-To: <mV3B1kRYE7kcvVEsIHe_4DcvT99kxlx0m7ELKGxZAfc=.166246cd-5fc2-4c0a-83e5-9e30a399ec1b@github.com>
References: <mV3B1kRYE7kcvVEsIHe_4DcvT99kxlx0m7ELKGxZAfc=.166246cd-5fc2-4c0a-83e5-9e30a399ec1b@github.com>
Message-ID: <xdQjuwmOfgKAY-TSRMxRBpmoMFFj3bgf6tK-Ii-JGJM=.f162e522-aec1-4620-a376-6e474ebc96f2@github.com>

> Please review this PR which modifies a suspicious check in the fallback of `Locale.getDisplayName(Locale inLocale)`.
> 
> As a fallback, a hard coded pattern is used. The previous code outputted the qualifiers if the `displayNames` array had length greater than 2. Just a few lines above, the array is initialized with a length of 3 and so the check is pointless.
> 
> It would be better, if replaced with a null check for the last element of the `displayNames` array, as that element may be null if there are no qualifiers. See L2317 ,
> 
> `qualifierNames.length != 0 ? formatList(qualifierNames, listCompositionPattern) : null`
> 
> For example, now a fallback (with no qualifiers) might look like: `German` instead of `German (null)`.
> But will remain the same (with qualifiers): `German (Germany)`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review - chain appends

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21298/files
  - new: https://git.openjdk.org/jdk/pull/21298/files/e50424bb..2cfa9de7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21298&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21298&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21298/head:pull/21298

PR: https://git.openjdk.org/jdk/pull/21298

From iklam at openjdk.org  Tue Oct  8 21:47:19 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Oct 2024 21:47:19 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression and
 string concat
Message-ID: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>

This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).

This PR implements the AOT-linking of invokedynamic callsites:
- We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
- The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.

**Review Notes:**

- Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
- `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
- In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
- Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).

**Rough Edges:**

- Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
- If the identity is significant for a static field in a complex class, but not all of the static fields of this class can be archived, I use the `AOTHolder` pattern to break out the fields that need to be archived. See discussion on [leyden-dev](https://mail.openjdk.org/pipermail/leyden-dev/2024-August/000911.html).

---
See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

-------------

Depends on: https://git.openjdk.org/jdk/pull/21049

Commit messages:
 - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
 - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
 - Limit the use of AOTHolder
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Merge branch 'remerge' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - more clean up
 - Cleaned up AOTClassInitializer::can_archive_initialized_mirror()
 - more clean up
 - ... and 14 more: https://git.openjdk.org/jdk/compare/1b067b7b...195303f2

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293336
  Stats: 1674 lines in 52 files changed: 1534 ins; 39 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From shade at openjdk.org  Tue Oct  8 21:47:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 8 Oct 2024 21:47:19 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>

On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Cursory review:

src/hotspot/share/cds/aotClassInitializer.cpp line 47:

> 45: 
> 46:   Symbol* name = ik->name();
> 47:   if (name->equals("jdk/internal/constant/PrimitiveClassDescImpl") ||

Could we / should we start using `vmSymbols` constants for these? I think you can directly compare the `Symbol*`-s then, like `name == vmSymbols::jdk_internal_constant_PrimitiveClassDescImpl_Holder() `.

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 476:

> 474:   if (bsm_klass->equals("java/lang/invoke/StringConcatFactory") &&
> 475:       bsm_name->equals("makeConcatWithConstants")) {
> 476:     return true;

I think all BSM entries in SCF are deterministic, really. So we can just check for the class?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21143#pullrequestreview-2331919072
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1777490992
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1777474219

From iklam at openjdk.org  Tue Oct  8 21:47:19 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Oct 2024 21:47:19 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>
Message-ID: <WFaOtqxYIjBq6-E2QljiquEPRoSBM9fHuLcC8n7CV98=.db56426c-1d44-4301-ac53-69a3e3dad136@github.com>

On Thu, 26 Sep 2024 17:29:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> src/hotspot/share/cds/aotClassInitializer.cpp line 47:
> 
>> 45: 
>> 46:   Symbol* name = ik->name();
>> 47:   if (name->equals("jdk/internal/constant/PrimitiveClassDescImpl") ||
> 
> Could we / should we start using `vmSymbols` constants for these? I think you can directly compare the `Symbol*`-s then, like `name == vmSymbols::jdk_internal_constant_PrimitiveClassDescImpl_Holder() `.

Not every class in this table is inside vmSymbols, and I don't want to have to edit vmSymbols whenever a new class is added here (and having to do garbage collection in vmSymbols when a class is removed from here).

I pushed a new version that's more table driven, and avoid most strcmp calls by filtering with the symbol length.

> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 476:
> 
>> 474:   if (bsm_klass->equals("java/lang/invoke/StringConcatFactory") &&
>> 475:       bsm_name->equals("makeConcatWithConstants")) {
>> 476:     return true;
> 
> I think all BSM entries in SCF are deterministic, really. So we can just check for the class?

We haven't done much testing with the other SCF BSMs, so I think it's better to do that in a follow-up REF.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1782287180
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1782282918

From adinn at openjdk.org  Tue Oct  8 21:47:20 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 8 Oct 2024 21:47:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>

On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 450:

> 448: 
> 449:   Symbol* mh_sig = cp->method_handle_signature_ref_at(mh_index);
> 450:   if (!check_lambda_metafactory_signature(cp, mh_sig, false)) {

This appears to be rerunning the previous check without a log message -- or am I missing something here?

src/hotspot/share/cds/archiveBuilder.cpp line 234:

> 232:       _klasses->append(klass);
> 233:       if (klass->is_hidden() && klass->is_instance_klass()) {
> 234:         update_hidden_class_loader_type(InstanceKlass::cast(klass));

Can you explain why this 'update' is needed. Are the shared classloader type and classpath index not already set? Or do they need adjusting? Perhaps a comment would help.

src/hotspot/share/cds/cdsConfig.cpp line 486:

> 484: bool CDSConfig::allow_only_single_java_thread() {
> 485:   // See comments in JVM_StartThread()
> 486:   return is_dumping_static_archive();

The test in `JVM_StartThread()` calls `CDSConfig::is_dumping_static_archive()`. Should it be updated to call `CDSConfig::allow_only_single_java_thread()`?

src/hotspot/share/cds/cdsHeapVerifier.cpp line 126:

> 124: 
> 125:   // Integer for 0 and 1 are in java/lang/Integer$IntegerCache and are archived
> 126:   ADD_EXCL("sun/invoke/util/ValueConversions",           "ONE_INT",                // E

At line 46 the example that explains how the verifier works discusses save and restore of field `Foo#archivedFoo`. I believe that field was supposed to be declared as `static` but it is actually declared as an instance field.

src/hotspot/share/cds/cdsHeapVerifier.cpp line 274:

> 272:     char* class_name = info->_holder->name()->as_C_string();
> 273:     char* field_name = info->_name->as_C_string();
> 274:     if (strstr(class_name, "java/lang/invoke/BoundMethodHandle$Species_") == class_name &&

Can we have a comment to explain this special case?

src/hotspot/share/cds/classListParser.cpp line 609:

> 607:   // We store a pre-generated version of the lambda proxy class in the AOT cache,
> 608:   // which will be loaded via JVM_LookupLambdaProxyClassFromArchive().
> 609:   // This eliminate dynamic class generation of the proxy class, but we still need to

"This eliminate" --> "This eliminates"

src/hotspot/share/cds/heapShared.cpp line 893:

> 891: void KlassSubGraphInfo::check_allowed_klass(InstanceKlass* ik) {
> 892:   if (CDSConfig::is_dumping_invokedynamic()) {
> 893:     // We allow LambdaProxy classes in platform and app loaders as well.

Do we not want an assert here to describe the extra classes we are allowing?

Also, does the comment at line 1975 now need to be updated -- it refers to this check which has been widened.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1790514322
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791663789
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791897685
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791917239
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791947118
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1791952296
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792002443

From liach at openjdk.org  Tue Oct  8 21:47:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 21:47:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <V_rbtXm-D51NI2k-OYr4NgPiy4E9IEpyeeail9xpZVs=.970a7142-15d6-4df9-8ed4-509b129659f1@github.com>

On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

src/java.base/share/classes/java/lang/invoke/MethodType.java line 404:

> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
> 403:         if (AOTHolder.archivedMethodTypes != null) {
> 404:             MethodType mt = AOTHolder.archivedMethodTypes.get(primordialMT);

Can we populate these AOT MTs into the internTable so we only look up once?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1775644045

From iklam at openjdk.org  Tue Oct  8 21:47:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Oct 2024 21:47:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <V_rbtXm-D51NI2k-OYr4NgPiy4E9IEpyeeail9xpZVs=.970a7142-15d6-4df9-8ed4-509b129659f1@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <V_rbtXm-D51NI2k-OYr4NgPiy4E9IEpyeeail9xpZVs=.970a7142-15d6-4df9-8ed4-509b129659f1@github.com>
Message-ID: <CN7Hdbyjs1viSsFMNtZ-9slELL9R8kBJ-LhvSVBf5Xo=.3e167a5a-3dbe-43fc-be21-3c35c66538a3@github.com>

On Wed, 25 Sep 2024 17:14:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 404:
> 
>> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
>> 403:         if (AOTHolder.archivedMethodTypes != null) {
>> 404:             MethodType mt = AOTHolder.archivedMethodTypes.get(primordialMT);
> 
> Can we populate these AOT MTs into the internTable so we only look up once?

There's a trade off here -- start-up will be slowed down if the archivedMethodTypes table is big. Also, `internTable` uses more memory as it wraps every entry inside a weak reference.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1782292378

From aturbanov at openjdk.org  Tue Oct  8 21:47:20 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 8 Oct 2024 21:47:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <tRBuAYS4zPRHHpFEZ--9YqSiU8Q-_dKmRaqQ3_-sg04=.21e766a9-f4db-4bcd-839a-e748bbaaa2ad@github.com>

On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

test/lib/jdk/test/lib/cds/CDSTestUtils.java line 877:

> 875:             }
> 876:         }
> 877:         if (lastMatch != null && lastMatch.equals("-XX:+" +  optionName)) {

Suggestion:

        if (lastMatch != null && lastMatch.equals("-XX:+" + optionName)) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1777059374

From swen at openjdk.org  Tue Oct  8 22:14:29 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 22:14:29 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v4]
In-Reply-To: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
Message-ID: <odBsCizmnT4sJR5fWBnPZ9NbVI7iDZIUwAW3-sM_Cq4=.a7021a73-7059-4d5a-9d3b-14d34ea261fd@github.com>

> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into optim_inner_class_lamba_meta_factory_202410
 - Update src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Lazy initialization of ARG_NAME_CACHE
 - Use global cache, don't need per-instance array
 - Merge remote-tracking branch 'upstream/master' into optim_inner_class_lamba_meta_factory_202410
 - suggestion from @liach
 - optimize InnerClassLambdaMetafactory init

-------------

Changes: https://git.openjdk.org/jdk/pull/21399/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=03
  Stats: 33 lines in 1 file changed: 18 ins; 8 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21399/head:pull/21399

PR: https://git.openjdk.org/jdk/pull/21399

From redestad at openjdk.org  Tue Oct  8 22:17:59 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 22:17:59 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v24]
In-Reply-To: <xQZk_VHNGcOM2rfbgu1jNi0QpQtIZGjFhtXvHq1Slq8=.0ba2be55-a510-46c9-b8b6-de0fea9cefa3@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <xQZk_VHNGcOM2rfbgu1jNi0QpQtIZGjFhtXvHq1Slq8=.0ba2be55-a510-46c9-b8b6-de0fea9cefa3@github.com>
Message-ID: <Y-wtWsM4DpIRdrB_6yN02_uOHTmm9j31LjzpFgHd6qs=.1ccf3c9e-6db7-4c32-b612-088d3c42d6ee@github.com>

On Mon, 7 Oct 2024 22:54:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @liach

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 706:

> 704:     public void writeLoadConstant(Opcode opcode, LoadableConstantEntry value) {
> 705:         // Make sure Long and Double have LDC2_W and
> 706:         // rewrite to _W if index is > 256

Pre-existing.. 
- Comment should say >= 256. 
- As we're cloning from a pre-existing pool I assume there's a (perhaps unlikely) possibility we go from a wide to a lower index? In that case the opcode could profitably be "rewritten" to `Opcode.LDC` in an else clause. (I assume `LDC_W` with an index in the 0-255 range works fine functionally; it just wastes a byte.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1791544609

From redestad at openjdk.org  Tue Oct  8 22:17:58 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 22:17:58 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v25]
In-Reply-To: <7Y4K8fhMRRaLlg3jF__2poKiMRwKwHggUE0iepmjFbg=.6e67168d-968b-4981-8618-2d274bba3835@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <7Y4K8fhMRRaLlg3jF__2poKiMRwKwHggUE0iepmjFbg=.6e67168d-968b-4981-8618-2d274bba3835@github.com>
Message-ID: <C8xtVAobytN3k1blLBEortnH5e9O6kzg19Qug6_VDqI=.c9926ed0-3430-4e1e-9b6e-54c6596aea77@github.com>

On Tue, 8 Oct 2024 09:57:43 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Fold opcode.bytecode() in writeLoadConstant
>  - A few missed places, U1U2U2 seem common enough too to be included
>  - Rename writeUtfEntry
>  - Fold TAG_UTF8 write into writeUTF

LGTM. 

I spotted places outside of the DirectCodeBuilder paths that could benefit from using these new coalescing writers, but write-only cases is a good focus point for now.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21243#pullrequestreview-2353954741

From naoto at openjdk.org  Tue Oct  8 22:18:59 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Oct 2024 22:18:59 GMT
Subject: RFR: 8341366: Suspicious check in Locale.getDisplayName(Locale
 inLocale) [v2]
In-Reply-To: <xdQjuwmOfgKAY-TSRMxRBpmoMFFj3bgf6tK-Ii-JGJM=.f162e522-aec1-4620-a376-6e474ebc96f2@github.com>
References: <mV3B1kRYE7kcvVEsIHe_4DcvT99kxlx0m7ELKGxZAfc=.166246cd-5fc2-4c0a-83e5-9e30a399ec1b@github.com>
 <xdQjuwmOfgKAY-TSRMxRBpmoMFFj3bgf6tK-Ii-JGJM=.f162e522-aec1-4620-a376-6e474ebc96f2@github.com>
Message-ID: <q7LoJ1MNdfLwZuOnOKTuW0oLOVDbSQRZbvFusVRAgi0=.27418ec4-8087-4695-9d5a-298bd05179e9@github.com>

On Tue, 8 Oct 2024 21:42:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which modifies a suspicious check in the fallback of `Locale.getDisplayName(Locale inLocale)`.
>> 
>> As a fallback, a hard coded pattern is used. The previous code outputted the qualifiers if the `displayNames` array had length greater than 2. Just a few lines above, the array is initialized with a length of 3 and so the check is pointless.
>> 
>> It would be better, if replaced with a null check for the last element of the `displayNames` array, as that element may be null if there are no qualifiers. See L2317 ,
>> 
>> `qualifierNames.length != 0 ? formatList(qualifierNames, listCompositionPattern) : null`
>> 
>> For example, now a fallback (with no qualifiers) might look like: `German` instead of `German (null)`.
>> But will remain the same (with qualifiers): `German (Germany)`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review - chain appends

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21298#pullrequestreview-2355635836

From swen at openjdk.org  Tue Oct  8 22:22:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 22:22:37 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v26]
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <yf4yrm7RzhpOqLR7I7IJnnqthyTPZr24rE2RN1fSBFQ=.641b4cfb-7088-491b-9cf3-5520282061bc@github.com>

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21243/files
  - new: https://git.openjdk.org/jdk/pull/21243/files/cd597a2a..894f7948

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21243&range=24-25

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21243.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21243/head:pull/21243

PR: https://git.openjdk.org/jdk/pull/21243

From swen at openjdk.org  Tue Oct  8 22:27:59 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 22:27:59 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v25]
In-Reply-To: <C8xtVAobytN3k1blLBEortnH5e9O6kzg19Qug6_VDqI=.c9926ed0-3430-4e1e-9b6e-54c6596aea77@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <7Y4K8fhMRRaLlg3jF__2poKiMRwKwHggUE0iepmjFbg=.6e67168d-968b-4981-8618-2d274bba3835@github.com>
 <C8xtVAobytN3k1blLBEortnH5e9O6kzg19Qug6_VDqI=.c9926ed0-3430-4e1e-9b6e-54c6596aea77@github.com>
Message-ID: <S5LCyPHEBj9ygGL4VJkZEkm1D1ycO9rvl7lrd_c_tvE=.e3433bb8-9cd2-46c8-857d-46a5b0b6ac3b@github.com>

On Tue, 8 Oct 2024 22:15:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> LGTM.
> 
> I spotted places outside of the DirectCodeBuilder paths that could benefit from using these new coalescing writers, but write-only cases is a good focus point for now.

Are you talking about merging multiple writeU2 in places like AbstractAttributeMapper? I am planning to make a new PR to complete these works, because this PR has too many changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21243#issuecomment-2400925030

From swen at openjdk.org  Tue Oct  8 22:34:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 22:34:38 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v5]
In-Reply-To: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
Message-ID: <Ls9J6PgibL1RUFEcCj-LmTvQULi_kMK2aYD5omt5p2Q=.1e413f9f-d099-45cb-bc63-d24a1e13c423@github.com>

> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix merge error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21399/files
  - new: https://git.openjdk.org/jdk/pull/21399/files/6cdc01a7..f905cc67

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21399/head:pull/21399

PR: https://git.openjdk.org/jdk/pull/21399

From liach at openjdk.org  Tue Oct  8 22:35:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 22:35:05 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v26]
In-Reply-To: <yf4yrm7RzhpOqLR7I7IJnnqthyTPZr24rE2RN1fSBFQ=.641b4cfb-7088-491b-9cf3-5520282061bc@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <yf4yrm7RzhpOqLR7I7IJnnqthyTPZr24rE2RN1fSBFQ=.641b4cfb-7088-491b-9cf3-5520282061bc@github.com>
Message-ID: <FPkY7Szrej5cISj2j29vQ3jp7lArUKoVTqjbnMm2xp0=.47a5142f-3a37-4d92-9eae-894ae305bbc7@github.com>

On Tue, 8 Oct 2024 22:22:37 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Some DirectCodeBuilder related optimizations to improve startup and running performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 instead of writeBytecode
>> 4. Rewrite the implementation of load and store
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21243#pullrequestreview-2355652343

From liach at openjdk.org  Tue Oct  8 22:35:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 22:35:06 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v24]
In-Reply-To: <Y-wtWsM4DpIRdrB_6yN02_uOHTmm9j31LjzpFgHd6qs=.1ccf3c9e-6db7-4c32-b612-088d3c42d6ee@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <xQZk_VHNGcOM2rfbgu1jNi0QpQtIZGjFhtXvHq1Slq8=.0ba2be55-a510-46c9-b8b6-de0fea9cefa3@github.com>
 <Y-wtWsM4DpIRdrB_6yN02_uOHTmm9j31LjzpFgHd6qs=.1ccf3c9e-6db7-4c32-b612-088d3c42d6ee@github.com>
Message-ID: <SnNSOkrmkSPhQeeX0dbeDHX03yXQsB_7eIgCQdouzpk=.42466423-7f78-4a9a-8f6d-5823e4e48c62@github.com>

On Tue, 8 Oct 2024 09:34:42 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   suggestion from @liach
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 706:
> 
>> 704:     public void writeLoadConstant(Opcode opcode, LoadableConstantEntry value) {
>> 705:         // Make sure Long and Double have LDC2_W and
>> 706:         // rewrite to _W if index is > 256
> 
> Pre-existing.. 
> - Comment should say >= 256. 
> - As we're cloning from a pre-existing pool I assume there's a (perhaps unlikely) possibility we go from a wide to a lower index? In that case the opcode could profitably be "rewritten" to `Opcode.LDC` in an else clause. (I assume `LDC_W` with an index in the 0-255 range works fine functionally; it just wastes a byte.)

Indeed, the opcode here is pointless if we have a pool adaption; in that case we should just use `ldc(LoadableConstantEntry)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1792580876

From liach at openjdk.org  Tue Oct  8 22:37:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 22:37:58 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v5]
In-Reply-To: <Ls9J6PgibL1RUFEcCj-LmTvQULi_kMK2aYD5omt5p2Q=.1e413f9f-d099-45cb-bc63-d24a1e13c423@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <Ls9J6PgibL1RUFEcCj-LmTvQULi_kMK2aYD5omt5p2Q=.1e413f9f-d099-45cb-bc63-d24a1e13c423@github.com>
Message-ID: <ETcpzMzR5mLttaMOaaA0LIfSW49GrXHTljo0LjEzgO8=.77a739a5-a0db-4b80-b448-64eb71777bc2@github.com>

On Tue, 8 Oct 2024 22:34:38 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge error

Trivial merge.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21399#pullrequestreview-2355655137

From redestad at openjdk.org  Tue Oct  8 22:49:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Oct 2024 22:49:01 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v25]
In-Reply-To: <S5LCyPHEBj9ygGL4VJkZEkm1D1ycO9rvl7lrd_c_tvE=.e3433bb8-9cd2-46c8-857d-46a5b0b6ac3b@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <7Y4K8fhMRRaLlg3jF__2poKiMRwKwHggUE0iepmjFbg=.6e67168d-968b-4981-8618-2d274bba3835@github.com>
 <C8xtVAobytN3k1blLBEortnH5e9O6kzg19Qug6_VDqI=.c9926ed0-3430-4e1e-9b6e-54c6596aea77@github.com>
 <S5LCyPHEBj9ygGL4VJkZEkm1D1ycO9rvl7lrd_c_tvE=.e3433bb8-9cd2-46c8-857d-46a5b0b6ac3b@github.com>
Message-ID: <Ds9jzHl_jc4jWQveP6MtlUZKAOkrbAH11oE_rHj9Yp8=.2ac81aee-887c-4f9c-b6b9-ba6a8f7da95d@github.com>

On Tue, 8 Oct 2024 22:25:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Are you talking about merging multiple writeU2 in places like AbstractAttributeMapper? I am planning to make a new PR to complete these works, because this PR has too many changes.

Good. I would have suggested the same.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21243#issuecomment-2400947102

From swen at openjdk.org  Tue Oct  8 22:54:01 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 8 Oct 2024 22:54:01 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v24]
In-Reply-To: <SnNSOkrmkSPhQeeX0dbeDHX03yXQsB_7eIgCQdouzpk=.42466423-7f78-4a9a-8f6d-5823e4e48c62@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <xQZk_VHNGcOM2rfbgu1jNi0QpQtIZGjFhtXvHq1Slq8=.0ba2be55-a510-46c9-b8b6-de0fea9cefa3@github.com>
 <Y-wtWsM4DpIRdrB_6yN02_uOHTmm9j31LjzpFgHd6qs=.1ccf3c9e-6db7-4c32-b612-088d3c42d6ee@github.com>
 <SnNSOkrmkSPhQeeX0dbeDHX03yXQsB_7eIgCQdouzpk=.42466423-7f78-4a9a-8f6d-5823e4e48c62@github.com>
Message-ID: <YGfvTDaBoVO8ALbEdGIii45BdF05NPNMuT2oI2n6nkc=.91fd98ed-1da2-435a-a410-29d12a99bb22@github.com>

On Tue, 8 Oct 2024 22:32:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 706:
>> 
>>> 704:     public void writeLoadConstant(Opcode opcode, LoadableConstantEntry value) {
>>> 705:         // Make sure Long and Double have LDC2_W and
>>> 706:         // rewrite to _W if index is > 256
>> 
>> Pre-existing.. 
>> - Comment should say >= 256. 
>> - As we're cloning from a pre-existing pool I assume there's a (perhaps unlikely) possibility we go from a wide to a lower index? In that case the opcode could profitably be "rewritten" to `Opcode.LDC` in an else clause. (I assume `LDC_W` with an index in the 0-255 range works fine functionally; it just wastes a byte.)
>
> Indeed, the opcode here is pointless if we have a pool adaption; in that case we should just use `ldc(LoadableConstantEntry)`.

Here in writeLoadConstant, some branches have curly braces, and some don't. The style is inconsistent. Should I change it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1792593521

From iklam at openjdk.org  Tue Oct  8 22:54:59 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Oct 2024 22:54:59 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>
Message-ID: <H0JcdmiiOBaDQVFyTCDQ6ynQnyRaPc3gbQ9O6qP2Cj4=.7cf7a669-cd73-47bc-9d79-c1d8f031b993@github.com>

On Mon, 7 Oct 2024 16:09:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 450:
> 
>> 448: 
>> 449:   Symbol* mh_sig = cp->method_handle_signature_ref_at(mh_index);
>> 450:   if (!check_lambda_metafactory_signature(cp, mh_sig, false)) {
> 
> This appears to be rerunning the previous check without a log message -- or am I missing something here?

It was a cut-and-paste mistake. I've removed this line in [195303f](https://github.com/openjdk/jdk/pull/21143/commits/195303f2c6939b93b6152c6610bd38faff5ae3c7) , where I also fixed some minor bugs with `AOTConstantPoolResolver::is_indy_resolution_deterministic()` and added more comments in the C++ code about what checks are being made.

I also added tests code in AOTLinkedLambdas.java to cover all the type checks that happen inside `is_indy_resolution_deterministic()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792594084

From jlu at openjdk.org  Tue Oct  8 23:04:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Oct 2024 23:04:18 GMT
Subject: RFR: 8341445: DecimalFormatSymbols setters should throw NPE [v3]
In-Reply-To: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
Message-ID: <uSoWS-55Ty3zyDbtBD07hRqEwjKGxNf8s7U07raBmNI=.ac342e15-e17a-48a1-bf0b-29462b9e889d@github.com>

> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols. As certain setters did not throw NPE, this allowed for NPE in the equality method. This PR now updates the setters to throw NPE.
> 
> In addition to the NPEs, there is also a behavioral change that `setInternationalCurrencySymbol` no longer sets currency to null if the `currencyCode` is invalid. Instead, it simply does not update `currency`. This must be done, because we do not want to allow nullable instance variables post `initalizeCurrency`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review - setters throw NPE

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21315/files
  - new: https://git.openjdk.org/jdk/pull/21315/files/bd6b021c..91b1c78f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21315&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21315&range=01-02

  Stats: 263 lines in 3 files changed: 100 ins; 148 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21315/head:pull/21315

PR: https://git.openjdk.org/jdk/pull/21315

From jlu at openjdk.org  Tue Oct  8 23:10:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Oct 2024 23:10:59 GMT
Subject: RFR: 8341445: DecimalFormatSymbols setters should throw NPE [v3]
In-Reply-To: <uSoWS-55Ty3zyDbtBD07hRqEwjKGxNf8s7U07raBmNI=.ac342e15-e17a-48a1-bf0b-29462b9e889d@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
 <uSoWS-55Ty3zyDbtBD07hRqEwjKGxNf8s7U07raBmNI=.ac342e15-e17a-48a1-bf0b-29462b9e889d@github.com>
Message-ID: <TSZ4mvpj0OO2nt0jYaeCG29vuECdEbQfb3diIvqZPRM=.5efa053f-d529-4a04-997e-54da457f3a45@github.com>

On Tue, 8 Oct 2024 23:04:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols. As certain setters did not throw NPE, this allowed for NPE in the equality method. This PR now updates the setters to throw NPE.
>> 
>> In addition to the NPEs, there is also a behavioral change that `setInternationalCurrencySymbol` no longer sets currency to null if the `currencyCode` is invalid. Instead, it simply does not update `currency`. This must be done, because we do not want to allow nullable instance variables post `initalizeCurrency`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review - setters throw NPE

https://github.com/openjdk/jdk/pull/21315/commits/91b1c78f0cfe4fe866c5eca3e84bf42e4c45adf1 updates this PR to take the throws NPE for all setters route. Please see the CSR filed: https://bugs.openjdk.org/browse/JDK-8341801.

Also note that there is an additional behavioral change that `setInternationalCurrencySymbol(String currencyCode)` will now not update the currency field if currencyCode is invalid, rather than nulling the currency field. This must be done to ensure that currency is not null (post lazy loading of the currency fields).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21315#issuecomment-2400968309

From liach at openjdk.org  Tue Oct  8 23:17:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 23:17:59 GMT
Subject: RFR: 8341141: Optimize DirectCodeBuilder [v24]
In-Reply-To: <YGfvTDaBoVO8ALbEdGIii45BdF05NPNMuT2oI2n6nkc=.91fd98ed-1da2-435a-a410-29d12a99bb22@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
 <xQZk_VHNGcOM2rfbgu1jNi0QpQtIZGjFhtXvHq1Slq8=.0ba2be55-a510-46c9-b8b6-de0fea9cefa3@github.com>
 <Y-wtWsM4DpIRdrB_6yN02_uOHTmm9j31LjzpFgHd6qs=.1ccf3c9e-6db7-4c32-b612-088d3c42d6ee@github.com>
 <SnNSOkrmkSPhQeeX0dbeDHX03yXQsB_7eIgCQdouzpk=.42466423-7f78-4a9a-8f6d-5823e4e48c62@github.com>
 <YGfvTDaBoVO8ALbEdGIii45BdF05NPNMuT2oI2n6nkc=.91fd98ed-1da2-435a-a410-29d12a99bb22@github.com>
Message-ID: <ooYxb83dkgI2rqtjowmj_lS9g5IvwEmfNuo7UaW1pB8=.c2ecd1d9-7f8e-4ca6-a1b0-c2bf5a3fb3f9@github.com>

On Tue, 8 Oct 2024 22:51:46 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Indeed, the opcode here is pointless if we have a pool adaption; in that case we should just use `ldc(LoadableConstantEntry)`.
>
> Here in writeLoadConstant, some branches have curly braces, and some don't. The style is inconsistent. Should I change it?

I think we can do it in a later cleanup that fixes writeLoadConstant. This patch is already huge.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21243#discussion_r1792606829

From jlu at openjdk.org  Tue Oct  8 23:29:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 8 Oct 2024 23:29:11 GMT
Subject: RFR: 8341684: Typo in External Specifications link of
 java.util.Currency
Message-ID: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>

A trivial correction to the  _j.util.Currency_ external specification ISO currency codes link. Browsers will auto resolve and correct the link, but it should still be fixed regardless.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21416/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21416&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341684
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21416/head:pull/21416

PR: https://git.openjdk.org/jdk/pull/21416

From liach at openjdk.org  Tue Oct  8 23:50:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 8 Oct 2024 23:50:56 GMT
Subject: RFR: 8341684: Typo in External Specifications link of
 java.util.Currency
In-Reply-To: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
References: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
Message-ID: <9MUkJjDJCgta7ewUrp7XnhIftgATon7lJQUUgw5I1QI=.0546e1d6-794f-441e-b0d2-bcedbbfbbea9@github.com>

On Tue, 8 Oct 2024 23:11:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A trivial correction to the  _j.util.Currency_ external specification ISO currency codes link. Browsers will auto resolve and correct the link, but it should still be fixed regardless.

Isn't the right link
https://www.iso.org/iso-4217-currency-codes.html
while simply changing the extension (and yes, the link in this PR) leads to a 404 page?

Also note that we prefer https links over http if possible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21416#issuecomment-2401002549

From jlu at openjdk.org  Wed Oct  9 00:08:30 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Oct 2024 00:08:30 GMT
Subject: RFR: 8341684: Typo in External Specifications link of
 java.util.Currency [v2]
In-Reply-To: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
References: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
Message-ID: <5AJODTHIiCtv26Vq-gWk8VNLyz4eQ7he0zWGPmMEnhU=.a4efb69b-5399-4524-8433-75c7386b7921@github.com>

> A trivial correction to the  _j.util.Currency_ external specification ISO currency codes link. Browsers will auto resolve and correct the link, but it should still be fixed regardless.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review: correct link

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21416/files
  - new: https://git.openjdk.org/jdk/pull/21416/files/59258bd4..d5ae8d6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21416&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21416&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21416/head:pull/21416

PR: https://git.openjdk.org/jdk/pull/21416

From liach at openjdk.org  Wed Oct  9 00:08:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 00:08:30 GMT
Subject: RFR: 8341684: Typo in External Specifications link of
 java.util.Currency [v2]
In-Reply-To: <5AJODTHIiCtv26Vq-gWk8VNLyz4eQ7he0zWGPmMEnhU=.a4efb69b-5399-4524-8433-75c7386b7921@github.com>
References: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
 <5AJODTHIiCtv26Vq-gWk8VNLyz4eQ7he0zWGPmMEnhU=.a4efb69b-5399-4524-8433-75c7386b7921@github.com>
Message-ID: <HFlzUyEkPA4qFOp-ayaL2YG_R4UMtV9FcydGqw4FrPI=.ffd38de0-24c0-4618-873f-a432e7d210a7@github.com>

On Wed, 9 Oct 2024 00:05:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> A trivial correction to the  _j.util.Currency_ external specification ISO currency codes link. Browsers will auto resolve and correct the link, but it should still be fixed regardless.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct link

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21416#pullrequestreview-2355727724

From jlu at openjdk.org  Wed Oct  9 00:08:30 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Oct 2024 00:08:30 GMT
Subject: RFR: 8341684: Typo in External Specifications link of
 java.util.Currency
In-Reply-To: <9MUkJjDJCgta7ewUrp7XnhIftgATon7lJQUUgw5I1QI=.0546e1d6-794f-441e-b0d2-bcedbbfbbea9@github.com>
References: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
 <9MUkJjDJCgta7ewUrp7XnhIftgATon7lJQUUgw5I1QI=.0546e1d6-794f-441e-b0d2-bcedbbfbbea9@github.com>
Message-ID: <lZl2aNYcO-HTLNK0ByxhJOiXsQUCtZYlbvIP-RKBmbI=.8369d609-6702-4b26-95df-4f2512281bcb@github.com>

On Tue, 8 Oct 2024 23:48:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> Isn't the right link https://www.iso.org/iso-4217-currency-codes.html while simply changing the extension (and yes, the link in this PR) leads to a 404 page?
> 
> Also note that we prefer https links over http if possible.

Thanks Chen, you're indeed correct. I did not notice that the old link was re-directing to the new one. Fixed in https://github.com/openjdk/jdk/pull/21416/commits/d5ae8d6f3432ec45283cb187522d6130106d497d.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21416#issuecomment-2401012890

From iklam at openjdk.org  Wed Oct  9 00:43:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Oct 2024 00:43:25 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <jkeNe6K_JLN5TuwnQqdIa4uQoMrU76QEhlokU-U4G8I=.fcc14767-5caf-443c-9ba3-bc876c7d3718@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @adinn comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/195303f2..ebfbb238

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=00-01

  Stats: 115 lines in 8 files changed: 52 ins; 50 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Wed Oct  9 01:00:02 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Oct 2024 01:00:02 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <MHZUtbf86c6NgzUyHS4oOTVEYUDTmklSInaOXl50spY=.ea363435-5079-46af-8af8-7300b04eb11d@github.com>
Message-ID: <oNj2jiOmoXcwc1q_uC6_OL0fN_gieQu3CZjkDLEX3L4=.007c03d4-4a94-4278-ba4e-cb3f0a166bda@github.com>

On Tue, 8 Oct 2024 11:01:45 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @adinn comments
>
> src/hotspot/share/cds/archiveBuilder.cpp line 234:
> 
>> 232:       _klasses->append(klass);
>> 233:       if (klass->is_hidden() && klass->is_instance_klass()) {
>> 234:         update_hidden_class_loader_type(InstanceKlass::cast(klass));
> 
> Can you explain why this 'update' is needed. Are the shared classloader type and classpath index not already set? Or do they need adjusting? Perhaps a comment would help.

Thanks for pointing this out. This code was necessary because `ClassLoader::record_result()` was not handling hidden classes. I fixed this by moving the logic from `update_hidden_class_loader_type()` to `ClassLoader::record_hidden_class()`.

> src/hotspot/share/cds/cdsConfig.cpp line 486:
> 
>> 484: bool CDSConfig::allow_only_single_java_thread() {
>> 485:   // See comments in JVM_StartThread()
>> 486:   return is_dumping_static_archive();
> 
> The test in `JVM_StartThread()` calls `CDSConfig::is_dumping_static_archive()`. Should it be updated to call `CDSConfig::allow_only_single_java_thread()`?

I updated `JVM_StartThread()`  to call `CDSConfig::allow_only_single_java_thread()`

> src/hotspot/share/cds/cdsHeapVerifier.cpp line 126:
> 
>> 124: 
>> 125:   // Integer for 0 and 1 are in java/lang/Integer$IntegerCache and are archived
>> 126:   ADD_EXCL("sun/invoke/util/ValueConversions",           "ONE_INT",                // E
> 
> At line 46 the example that explains how the verifier works discusses save and restore of field `Foo#archivedFoo`. I believe that field was supposed to be declared as `static` but it is actually declared as an instance field.

I edited the comment to add `static` to the declaration of `Foo#archivedFoo`.

> src/hotspot/share/cds/cdsHeapVerifier.cpp line 274:
> 
>> 272:     char* class_name = info->_holder->name()->as_C_string();
>> 273:     char* field_name = info->_name->as_C_string();
>> 274:     if (strstr(class_name, "java/lang/invoke/BoundMethodHandle$Species_") == class_name &&
> 
> Can we have a comment to explain this special case?

This check is no longer necessary, the Species_XXX classes are now added to the aot-init list in `AOTClassInitializer::can_archive_initialized_mirror()`. I've removed these two lines.

> src/hotspot/share/cds/classListParser.cpp line 609:
> 
>> 607:   // We store a pre-generated version of the lambda proxy class in the AOT cache,
>> 608:   // which will be loaded via JVM_LookupLambdaProxyClassFromArchive().
>> 609:   // This eliminate dynamic class generation of the proxy class, but we still need to
> 
> "This eliminate" --> "This eliminates"

Fixed

> src/hotspot/share/cds/heapShared.cpp line 893:
> 
>> 891: void KlassSubGraphInfo::check_allowed_klass(InstanceKlass* ik) {
>> 892:   if (CDSConfig::is_dumping_invokedynamic()) {
>> 893:     // We allow LambdaProxy classes in platform and app loaders as well.
> 
> Do we not want an assert here to describe the extra classes we are allowing?
> 
> Also, does the comment at line 1975 now need to be updated -- it refers to this check which has been widened.

I updated `KlassSubGraphInfo::check_allowed_klass()` to do proper checks for lambda proxy classes that are allowed. I also update the comment at at line 1975 to be consistent with `check_allowed_klass()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792659021
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792659000
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792658987
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792658960
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792658948
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792658912

From rsunderbabu at openjdk.org  Wed Oct  9 01:14:08 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 9 Oct 2024 01:14:08 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust
In-Reply-To: <DbUP95GxAnTQ2f-TTF65ooCYlMZsIb8yqTGxkaKsOMc=.7c53fb62-7607-4378-ad5c-f38aa8d1da47@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <DbUP95GxAnTQ2f-TTF65ooCYlMZsIb8yqTGxkaKsOMc=.7c53fb62-7607-4378-ad5c-f38aa8d1da47@github.com>
Message-ID: <s-OkA8ZCdhMrg-UuxirJeT8rU7K-av_F5GG0cWu2XmM=.3d0a78e4-b513-4e7c-93cb-726bd3d9dae3@github.com>

On Tue, 8 Oct 2024 19:50:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
>> 
>> Testing: The test was run for 100 times with -Xcomp option.
>
> test/jdk/java/time/tck/java/time/TCKInstant.java line 193:
> 
>> 191:         Instant test = Instant.now();
>> 192:         long diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
>> 193:         assertTrue(diff < 10_000);  // less than 10 secs
> 
> Given arbitrary delays between the two executions; the premise of the test itself is suspect; especially if the allowed time is increased.  I think the test is supposed to be testing that the default clock for Instant.now() is the SystemUTC clock.
> I'd expect expected to be less than or equal to test.
> The use of math.abs allows the clock to go backwards; that might happen if the time was re-set manually.

Thanks @RogerRiggs for the comments. I increased the diff allowance to absorb any compilation related delays. What would you propose here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1792666022

From jpai at openjdk.org  Wed Oct  9 01:19:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 01:19:56 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v4]
In-Reply-To: <CsrcEvhoyJWWa4M_xLPfcgUL7K2Lbb-hv_kwW3PBYzE=.b2540caf-4880-4e76-a4bd-7ec1d59e6baa@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <CsrcEvhoyJWWa4M_xLPfcgUL7K2Lbb-hv_kwW3PBYzE=.b2540caf-4880-4e76-a4bd-7ec1d59e6baa@github.com>
Message-ID: <Y0WaYx1l1PjVdCYihv8gx-hh_JToEWDOIUh0_8QOObY=.b812bd08-6f2d-4090-aaa4-c4a2220ee6e3@github.com>

On Tue, 8 Oct 2024 01:36:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mandy's review - remove since JDK 24

Thank you for the review Mandy.

> Should we leave the man page change be part of the bulk update near the end of the release?

In recent times we have been updating the man page as and when necessary instead of doing it just once in bulk. I suspect there will still be some bulk changes at the end of the release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21380#issuecomment-2401083183

From rsunderbabu at openjdk.org  Wed Oct  9 01:29:56 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 9 Oct 2024 01:29:56 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust
In-Reply-To: <s-OkA8ZCdhMrg-UuxirJeT8rU7K-av_F5GG0cWu2XmM=.3d0a78e4-b513-4e7c-93cb-726bd3d9dae3@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <DbUP95GxAnTQ2f-TTF65ooCYlMZsIb8yqTGxkaKsOMc=.7c53fb62-7607-4378-ad5c-f38aa8d1da47@github.com>
 <s-OkA8ZCdhMrg-UuxirJeT8rU7K-av_F5GG0cWu2XmM=.3d0a78e4-b513-4e7c-93cb-726bd3d9dae3@github.com>
Message-ID: <O4Qew8_cYY2HnEBpIgAf7jYiYLZI82RTix4H1uDk8YQ=.20f4ae77-7bee-4e2f-be22-33c3b2a93f1a@github.com>

On Wed, 9 Oct 2024 01:10:54 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> test/jdk/java/time/tck/java/time/TCKInstant.java line 193:
>> 
>>> 191:         Instant test = Instant.now();
>>> 192:         long diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
>>> 193:         assertTrue(diff < 10_000);  // less than 10 secs
>> 
>> Given arbitrary delays between the two executions; the premise of the test itself is suspect; especially if the allowed time is increased.  I think the test is supposed to be testing that the default clock for Instant.now() is the SystemUTC clock.
>> I'd expect expected to be less than or equal to test.
>> The use of math.abs allows the clock to go backwards; that might happen if the time was re-set manually.
>
> Thanks @RogerRiggs for the comments. I increased the diff allowance to absorb any compilation related delays. What would you propose here?

If your objection is primarily on Math.abs, is this ok?
`
        long diff = test.toEpochMilli() - expected.toEpochMilli();
        assertTrue(diff >= 0 && diff < 10_000);  // less than 10 secs
 `

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1792673474

From redestad at openjdk.org  Wed Oct  9 03:50:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 9 Oct 2024 03:50:01 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v5]
In-Reply-To: <Ls9J6PgibL1RUFEcCj-LmTvQULi_kMK2aYD5omt5p2Q=.1e413f9f-d099-45cb-bc63-d24a1e13c423@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <Ls9J6PgibL1RUFEcCj-LmTvQULi_kMK2aYD5omt5p2Q=.1e413f9f-d099-45cb-bc63-d24a1e13c423@github.com>
Message-ID: <UkUvV7I2jj5vU2Pv56vKHSP_xcYLYHK-3mTD_seUrnk=.d5f7b065-63f4-4eae-aafe-901474c8a3a0@github.com>

On Tue, 8 Oct 2024 22:34:38 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge error

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 191:

> 189: 
> 190:     private static String argName(int i) {
> 191:         String argName = i < ARG_NAME_CACHE_SIZE ? ARG_NAME_CACHE[i] : null;

Just an idea, but perhaps could constant init `ARG_NAME_CACHE = { "arg$0", "arg$1", .. , "arg$7" };` and simplify this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21399#discussion_r1792744321

From duke at openjdk.org  Wed Oct  9 03:59:58 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 9 Oct 2024 03:59:58 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <jkeNe6K_JLN5TuwnQqdIa4uQoMrU76QEhlokU-U4G8I=.fcc14767-5caf-443c-9ba3-bc876c7d3718@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <jkeNe6K_JLN5TuwnQqdIa4uQoMrU76QEhlokU-U4G8I=.fcc14767-5caf-443c-9ba3-bc876c7d3718@github.com>
Message-ID: <mAbClDkMiSSo8BuA_JfwKzrlh1kV3iddZW945-Mvt2U=.6ff76f65-38c3-40a0-982d-94370e67dcd6@github.com>

On Wed, 9 Oct 2024 00:43:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @adinn comments

-------------

PR Review: https://git.openjdk.org/jdk/pull/21143#pullrequestreview-2355889520

From duke at openjdk.org  Wed Oct  9 03:59:59 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 9 Oct 2024 03:59:59 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <WFaOtqxYIjBq6-E2QljiquEPRoSBM9fHuLcC8n7CV98=.db56426c-1d44-4301-ac53-69a3e3dad136@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>
 <WFaOtqxYIjBq6-E2QljiquEPRoSBM9fHuLcC8n7CV98=.db56426c-1d44-4301-ac53-69a3e3dad136@github.com>
Message-ID: <72Bo7ZIdbj2kt7jz282D-eWtaJQPWiuIZr9FvaYWAC8=.1ac0cf97-427c-4562-a2e4-b87b47372698@github.com>

On Tue, 1 Oct 2024 07:53:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 476:
>> 
>>> 474:   if (bsm_klass->equals("java/lang/invoke/StringConcatFactory") &&
>>> 475:       bsm_name->equals("makeConcatWithConstants")) {
>>> 476:     return true;
>> 
>> I think all BSM entries in SCF are deterministic, really. So we can just check for the class?
>
> We haven't done much testing with the other SCF BSMs, so I think it's better to do that in a follow-up REF.

`StringConcatFactory?::makeConcat(?)` is?definitely deterministic, as?it simply?delegates to?`StringConcatFactory?::makeConcatWithConstants(?)` with?the?recipe being?based on?the?number of?`MethodType` parameters:
https://github.com/openjdk/jdk/blob/de90204b60c408ef258a2d2515ad252de4b23536/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java#L231-L240

And?there is?no?other bootstrap?method in?`StringConcatFactory` at?the?moment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792745509

From swen at openjdk.org  Wed Oct  9 04:03:11 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 04:03:11 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v6]
In-Reply-To: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
Message-ID: <q0vGBm6NItPrKn9of_MGHEefjT5iFxg2cKu_xrAifBk=.cde005f0-f851-4ab6-8396-def6a74d7bca@github.com>

> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  suggestion from @cl4es

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21399/files
  - new: https://git.openjdk.org/jdk/pull/21399/files/f905cc67..fc8b71ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=04-05

  Stats: 10 lines in 1 file changed: 0 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21399/head:pull/21399

PR: https://git.openjdk.org/jdk/pull/21399

From swen at openjdk.org  Wed Oct  9 04:09:33 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 04:09:33 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v7]
In-Reply-To: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
Message-ID: <tSm2vbAHFq_OMihDN2mrdH-diF3KiTEuVsOw852eWWM=.fcc6f73a-427b-4e98-a6a9-44d49ccedb0e@github.com>

> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  suggestion from @cl4es

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21399/files
  - new: https://git.openjdk.org/jdk/pull/21399/files/fc8b71ed..3d696618

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21399&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21399/head:pull/21399

PR: https://git.openjdk.org/jdk/pull/21399

From liach at openjdk.org  Wed Oct  9 04:23:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 04:23:00 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v7]
In-Reply-To: <tSm2vbAHFq_OMihDN2mrdH-diF3KiTEuVsOw852eWWM=.fcc6f73a-427b-4e98-a6a9-44d49ccedb0e@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <tSm2vbAHFq_OMihDN2mrdH-diF3KiTEuVsOw852eWWM=.fcc6f73a-427b-4e98-a6a9-44d49ccedb0e@github.com>
Message-ID: <DMs3VC8tpnntU74LPvLAEN63LOsY_Bsi6BfZW_UFMRw=.bcefe9c6-118f-4a7b-9cc9-8424ccfd30ac@github.com>

On Wed, 9 Oct 2024 04:09:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggestion from @cl4es

Back to precomputed constants :)

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21399#pullrequestreview-2355985946

From swen at openjdk.org  Wed Oct  9 05:19:02 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 05:19:02 GMT
Subject: RFR: 8341755: Optimize argNames in InnerClassLambdaMetafactory
 [v7]
In-Reply-To: <DMs3VC8tpnntU74LPvLAEN63LOsY_Bsi6BfZW_UFMRw=.bcefe9c6-118f-4a7b-9cc9-8424ccfd30ac@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
 <tSm2vbAHFq_OMihDN2mrdH-diF3KiTEuVsOw852eWWM=.fcc6f73a-427b-4e98-a6a9-44d49ccedb0e@github.com>
 <DMs3VC8tpnntU74LPvLAEN63LOsY_Bsi6BfZW_UFMRw=.bcefe9c6-118f-4a7b-9cc9-8424ccfd30ac@github.com>
Message-ID: <W51Iqa89xzpUDnBzWtpkdwtufie8Ba2NDR1duoQs_D4=.643eb44a-0b1a-46f6-a0eb-54052c2cc148@github.com>

On Wed, 9 Oct 2024 04:20:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Back to precomputed constants :)

Manual shift computation! The code is also simplified based on precomputed constants.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21399#issuecomment-2401334988

From alanb at openjdk.org  Wed Oct  9 05:34:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Oct 2024 05:34:03 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <s0VZnbN4VkoY7DMLvb2CXMsgMRrbM5SGFMh_ElWILgk=.76d22034-65f5-458a-8f98-c294ff355cb3@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
 <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
 <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>
 <kRXktNf1JWHEqBKKCHiBSC_tpAcEKuEhEstpVIf8ofI=.7e87860e-3de2-4ff2-90ca-f3759cc9e823@github.com>
 <BF9tP3Qy6N1xub8xyjky5ZfSideN1833h4R3XNg6uao=.9b62fee2-f5f6-4082-b78a-273029189e34@github.com>
 <yTDgfvNrZU1d4Iug9uzoYC7Ur6rfnZFLLrEYzlMsq_U=.d1f7c76a-51c3-4dc8-ad40-32c9665cea59@github.com>
 <_VSLUFJJhDuKwt62-0OR8QYXBd3Q5DvxhdpgqfasGPI=.8cf22f15-0a68-4868-86f3-81a7bae65510@github.com>
 <s0VZnbN4VkoY7DMLvb2CXMsgMRrbM5SGFMh_ElWILgk=.76d22034-65f5-458a-8f98-c294ff355cb3@github.com>
Message-ID: <BzpBm5WNlZQZRue7NSfXKHdRpmKh57M2SQp4gSHI5Bc=.aa4ba05f-ed9d-4efb-897a-c0f99f980686@github.com>

On Tue, 8 Oct 2024 17:38:14 GMT, Markus KARG <duke at openjdk.org> wrote:

>>> @AlanBateman WDYT?
>> 
>> It's good question as a CharSequence's length can change over time, e.g. StringBuilder. This scenario comes up regularly with InputStreams and Readers connected to files as the file may be growing and shrinking as bytes are read. It would not be surprising to read to EOF/-1 and to not read any further chars, even if the underlying sequence has grow.
>
> I have updated the source code so that it looks up `cs.length()` live each time. Nevertheless, this does not necessarily imply any predictable outcome due to the natur of an interface: Custom implementations could concurrently replace already read characters, but we need to step on with `next` for each `read()`/`skip()`, and `CharSequence` itself does not provide any read cursor means (like files have with `position()`). Because of that, I have added a warning in the JavaDocs, paraphrased from `CharSequence::chars` and `CharSequence::codePoints`: `If the sequence is concurrently modified then the result is undefined.`

The sentence "If the sequence is modified .." in the these methods is in the context of the methods. For ofReader(CharSequence) then it is any modification, doesn't have to be concurrent. Maybe something like "If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792864530

From duke at openjdk.org  Wed Oct  9 05:50:18 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 05:50:18 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Improved wording: 'If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/7d285bec..75cb4fc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From duke at openjdk.org  Wed Oct  9 05:50:18 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 05:50:18 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v4]
In-Reply-To: <BzpBm5WNlZQZRue7NSfXKHdRpmKh57M2SQp4gSHI5Bc=.aa4ba05f-ed9d-4efb-897a-c0f99f980686@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <8MGhR70b_8nFSsp1r5YBgwgTyrVzP57J3hkR34ASU4I=.79814b1b-b4fe-40e5-a6b5-205f6c08f4fb@github.com>
 <WtcNZa2saku9Yka_aBnpo9hvNenpMf48ahI_KAdjUP8=.5382a3c8-97b4-4580-9d4c-83e5e642656a@github.com>
 <n1O7N2_npxmxTuinBaEyLKLqySqYxqnBbV85Mmhk9NY=.c4e97e26-8dcb-4b2d-ad1e-957ee3c05b81@github.com>
 <hRuhgohyqyU_RgsApMI9pMKAeWG3fxJZJiee1j2Euco=.07828fda-5560-443b-9d5b-a1786ed83c60@github.com>
 <kRXktNf1JWHEqBKKCHiBSC_tpAcEKuEhEstpVIf8ofI=.7e87860e-3de2-4ff2-90ca-f3759cc9e823@github.com>
 <BF9tP3Qy6N1xub8xyjky5ZfSideN1833h4R3XNg6uao=.9b62fee2-f5f6-4082-b78a-273029189e34@github.com>
 <yTDgfvNrZU1d4Iug9uzoYC7Ur6rfnZFLLrEYzlMsq_U=.d1f7c76a-51c3-4dc8-ad40-32c9665cea59@github.com>
 <_VSLUFJJhDuKwt62-0OR8QYXBd3Q5DvxhdpgqfasGPI=.8cf22f15-0a68-4868-86f3-81a7bae65510@github.com>
 <s0VZnbN4VkoY7DMLvb2CXMsgMRrbM5SGFMh_ElWILgk=.76d22034-65f5-458a-8f98-c294ff355cb3@github.com>
 <BzpBm5WNlZQZRue7NSfXKHdRpmKh57M2SQp
 4gSHI5Bc=.aa4ba05f-ed9d-4efb-897a-c0f99f980686@github.com>
Message-ID: <d7uQxqLnQ1GGzo66l2cBI-uDw7T6Ep3YMpHJwvezc_k=.a8639618-42ba-4d20-aa5f-29a68ce94fda@github.com>

On Wed, 9 Oct 2024 05:30:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I have updated the source code so that it looks up `cs.length()` live each time. Nevertheless, this does not necessarily imply any predictable outcome due to the natur of an interface: Custom implementations could concurrently replace already read characters, but we need to step on with `next` for each `read()`/`skip()`, and `CharSequence` itself does not provide any read cursor means (like files have with `position()`). Because of that, I have added a warning in the JavaDocs, paraphrased from `CharSequence::chars` and `CharSequence::codePoints`: `If the sequence is concurrently modified then the result is undefined.`
>
> The sentence "If the sequence is modified .." in the these methods is in the context of the methods. For ofReader(CharSequence) then it is any modification, doesn't have to be concurrent. Maybe something like "If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined".

Thank you, Alan. I have copied your wording.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792880212

From syan at openjdk.org  Wed Oct  9 05:51:03 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 05:51:03 GMT
Subject: RFR: 8341658: RISC-V: Test DateFormatProviderTest.java run
 timeouted
In-Reply-To: <XjeBa45z_vYwst-etRxuo0rGc4QB_4nxsWEnFGtmTmw=.9c98106f-d3f7-4cc2-8179-9c54c24acc2d@github.com>
References: <XjeBa45z_vYwst-etRxuo0rGc4QB_4nxsWEnFGtmTmw=.9c98106f-d3f7-4cc2-8179-9c54c24acc2d@github.com>
Message-ID: <LMngCG8KhjosmLicjskDskJ2RtZxVZE2a4oJ5_HlPQc=.c2873b72-6449-499f-9bbf-ef883c090e41@github.com>

On Mon, 7 Oct 2024 15:49:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The test `java/util/PluggableLocale/DateFormatProviderTest.java` run timeout on riscv64 physic machine. This test has 4496 sub-tests, and riscv64 has poor single core performance, so this test run timeouted on riscv64 seems acceptable.
> Thus, to make less test noisy, I think we should add more timeout value for this test.
> Test-fix only, no risk.

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21393#issuecomment-2401368550

From syan at openjdk.org  Wed Oct  9 05:51:03 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 9 Oct 2024 05:51:03 GMT
Subject: Integrated: 8341658: RISC-V: Test DateFormatProviderTest.java run
 timeouted
In-Reply-To: <XjeBa45z_vYwst-etRxuo0rGc4QB_4nxsWEnFGtmTmw=.9c98106f-d3f7-4cc2-8179-9c54c24acc2d@github.com>
References: <XjeBa45z_vYwst-etRxuo0rGc4QB_4nxsWEnFGtmTmw=.9c98106f-d3f7-4cc2-8179-9c54c24acc2d@github.com>
Message-ID: <csg38TDp0HUO_CDb_eCIToYppuwtUwI1srxeN1glrrQ=.34193c63-6364-4bfe-abaa-bbfe043c0111@github.com>

On Mon, 7 Oct 2024 15:49:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The test `java/util/PluggableLocale/DateFormatProviderTest.java` run timeout on riscv64 physic machine. This test has 4496 sub-tests, and riscv64 has poor single core performance, so this test run timeouted on riscv64 seems acceptable.
> Thus, to make less test noisy, I think we should add more timeout value for this test.
> Test-fix only, no risk.

This pull request has now been integrated.

Changeset: d809bc0e
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d809bc0e21b145758f21c4324772faf6aa6a276a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8341658: RISC-V: Test DateFormatProviderTest.java run timeouted

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21393

From iklam at openjdk.org  Wed Oct  9 05:55:59 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Oct 2024 05:55:59 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v2]
In-Reply-To: <72Bo7ZIdbj2kt7jz282D-eWtaJQPWiuIZr9FvaYWAC8=.1ac0cf97-427c-4562-a2e4-b87b47372698@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <u4HbtxYUyhW9a78huNOxUX8liIsTsSQtn2OcxtReInE=.dcc59671-9cec-455e-9a28-e7b114bbd835@github.com>
 <WFaOtqxYIjBq6-E2QljiquEPRoSBM9fHuLcC8n7CV98=.db56426c-1d44-4301-ac53-69a3e3dad136@github.com>
 <72Bo7ZIdbj2kt7jz282D-eWtaJQPWiuIZr9FvaYWAC8=.1ac0cf97-427c-4562-a2e4-b87b47372698@github.com>
Message-ID: <vAIoiCdG5bfF08cocrFBjWAz2u2hDGC5mhh_xt5DdKE=.be66c604-6dc8-430c-af58-2a9270b3f284@github.com>

On Wed, 9 Oct 2024 03:49:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> We haven't done much testing with the other SCF BSMs, so I think it's better to do that in a follow-up REF.
>
> [`StringConcatFactory?::makeConcat(?)`] is?definitely deterministic, as?it simply?delegates to?[`StringConcatFactory?::makeConcatWithConstants(?)`] with?the?recipe being?based on?the?number of?[`MethodType`] parameters:
> https://github.com/openjdk/jdk/blob/de90204b60c408ef258a2d2515ad252de4b23536/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java#L231-L240
> 
> And?there is?no?other bootstrap?method in?[`StringConcatFactory`] at?the?moment.
> 
> [`MethodType`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/invoke/MethodType.html
> [`StringConcatFactory`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/invoke/StringConcatFactory.html
> [`StringConcatFactory?::makeConcat(?)`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/invoke/StringConcatFactory.html#makeConcat(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.invoke.MethodType)
> [`StringConcatFactory?::makeConcatWithConstants(?)`]: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/invoke/StringConcatFactory.html#makeConcatWithConstants(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.invoke.MethodType,java.lang.String,java.lang.Object...)

Since the comment says "This bootstrap method is unlikely to be used in practice", I am not sure if we can sufficiently test it (with aot-linking).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1792884101

From aph at openjdk.org  Wed Oct  9 05:57:08 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 05:57:08 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <mgOY64rd3_MhQGa03f0FJJg3OrvDtxIpGR4VPWyHzpA=.39a0949a-c050-49d0-a7f6-0bbb6c79c32d@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

On 8 Oct 2024, at 4:07, Andrew Haley wrote:

> On 9/10/24 12:42, Coleen Phillimore wrote:
>> Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.
>
> I'm a bit concerned about this one.
>
> I'm working on megamorphic dispatch, and a uniform representation of
> compressed class pointers allows me to squeeze klass+offset into a
> single 64-bit word. This in turn allows fast and simple method
> lookups. I need, at least, to be able to use compressed interface
> pointers. If interfaces are "somewhere else", and thus incompressible,
> I can't do what I need to do.

This is an interesting use of compressed klass pointers.

It looks like the compression needs to be partial, down to about 32 bits.

A motivation of this work is to compress concrete klass indexes into LESS than 32 bits, to take up less room in object layout.

So it looks like (a) having ALL klass IDs fit in 32 bits, and (b) having all CONCRETE klass IDs fit into a smaller part of the same range, would meet all requirements.  Doing it right might require TWO new companion types for Klass*, a compact concrete klass ID, and a 32-bit klass ID (supertype to compact concrete klass ID).  I think the larger one could be called narrowKlass (current name), and maybe the narrower concrete ID could be called narrowConcreteKlass or narrowestKlass or something like that.

(Because of CDS, and maybe other factors, some compact concrete klass IDs will actually point to interfaces or abstract classes.  So narrowConcreteKlass suggests a property of its referents that isn?t exactly true.)

> ? If, however, klass and non-klass
> metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
> rather use compressed klass pointers without having to decode them.

The way I read this is to think about putting, not klass and non-klass, but concrete-klass and non-concrete-klass IDs in the same range.  (By ID I mean a compressed Klass pointer, or alternatively an index into some sort of special table that we haven?t needed to invent.)

> All I need is a way to represent interface pointers in a compact way
> in lookup tables, and to be able to get from compressed class pointers
> to the address. As long as interface pointers are in a 32-bit range
> and there's a fast way to get from compressed class to address that's
> OK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401375521

From qamai at openjdk.org  Wed Oct  9 06:03:04 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 9 Oct 2024 06:03:04 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <mgOY64rd3_MhQGa03f0FJJg3OrvDtxIpGR4VPWyHzpA=.39a0949a-c050-49d0-a7f6-0bbb6c79c32d@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
 <mgOY64rd3_MhQGa03f0FJJg3OrvDtxIpGR4VPWyHzpA=.39a0949a-c050-49d0-a7f6-0bbb6c79c32d@github.com>
Message-ID: <ve9dW2jlxfWmaZ1jHQLWFRKs7GQi1GmH21rRiVjJV1Y=.e3599398-cc21-47f0-ac7f-77f8539c4b25@github.com>

On Wed, 9 Oct 2024 05:53:51 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.
>
> On 8 Oct 2024, at 4:07, Andrew Haley wrote:
> 
>> On 9/10/24 12:42, Coleen Phillimore wrote:
>>> Thanks for reviewing Ioi and Thomas, and thank you Thomas for the suggested changes.
>>
>> I'm a bit concerned about this one.
>>
>> I'm working on megamorphic dispatch, and a uniform representation of
>> compressed class pointers allows me to squeeze klass+offset into a
>> single 64-bit word. This in turn allows fast and simple method
>> lookups. I need, at least, to be able to use compressed interface
>> pointers. If interfaces are "somewhere else", and thus incompressible,
>> I can't do what I need to do.
> 
> This is an interesting use of compressed klass pointers.
> 
> It looks like the compression needs to be partial, down to about 32 bits.
> 
> A motivation of this work is to compress concrete klass indexes into LESS than 32 bits, to take up less room in object layout.
> 
> So it looks like (a) having ALL klass IDs fit in 32 bits, and (b) having all CONCRETE klass IDs fit into a smaller part of the same range, would meet all requirements.  Doing it right might require TWO new companion types for Klass*, a compact concrete klass ID, and a 32-bit klass ID (supertype to compact concrete klass ID).  I think the larger one could be called narrowKlass (current name), and maybe the narrower concrete ID could be called narrowConcreteKlass or narrowestKlass or something like that.
> 
> (Because of CDS, and maybe other factors, some compact concrete klass IDs will actually point to interfaces or abstract classes.  So narrowConcreteKlass suggests a property of its referents that isn?t exactly true.)
> 
>> ? If, however, klass and non-klass
>> metaspaces are contiguous I guess it'd be OK, if not ideal. I'd much
>> rather use compressed klass pointers without having to decode them.
> 
> The way I read this is to think about putting, not klass and non-klass, but concrete-klass and non-concrete-klass IDs in the same range.  (By ID I mean a compressed Klass pointer, or alternatively an index into some sort of special table that we haven?t needed to invent.)
> 
>> All I need is a way to represent interface pointers in a compact way
>> in lookup tables, and to be able to get from compressed class pointers
>> to the address. As long as interface pointers are in a 32-bit range
>> and there's a fast way to get from compressed class to address that's
>> OK.

@theRealAph I do not know your idea regarding this matter but does compressing interface pointers independently from concrete class pointers help?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401380082

From jrose at openjdk.org  Wed Oct  9 06:10:05 2024
From: jrose at openjdk.org (John R Rose)
Date: Wed, 9 Oct 2024 06:10:05 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <AOROIqOqf-5g2WScT9sCslfWmvwYLKRLS7UFMnVpI5E=.0feba64a-0a5f-49cf-bd13-fdb094bf295c@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

If the interfaces had a compact numbering, and there were a side table mapping the compact numbers to interface Klass* pointers, then I think Andrew's code would still work (with natural adjustments).

But managing such a side table is at least as complicated as just doing the pointer compression stuff we do.  (Hence my comment that we haven't had to invent side tables yet.)

Because of CDS I don't think we can treat concretes and abstracts (or even just classes and interfaces) as disjoint metadata types with separate independent compression tactics or representations.  I think we need a subtype/supertype relation between the "narrowest" and merely "narrower" klass IDs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401391441

From mbaesken at openjdk.org  Wed Oct  9 06:27:59 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 06:27:59 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
Message-ID: <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>

On Tue, 8 Oct 2024 16:30:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 393:
> 
>> 391: 
>> 392:       hcreate_r(htab_sz, symtab->hash_table);
>> 393:       // guarantee(rslt, "unexpected failure: hcreate_r");
> 
> The commented out guarantee line references rslt. I'm not so sure why it was commented out, but it goes back to the initial load of the file 17 years ago. It looks like the correct thing to do if rslt is null is to "goto bad;" but that change is probably beyond the scope of this PR. Maybe file a new CR.

Hi Chris , I created https://bugs.openjdk.org/browse/JDK-8341820 for the return value checking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1792911176

From rkennke at openjdk.org  Wed Oct  9 06:37:07 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 9 Oct 2024 06:37:07 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
 <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
 <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>
 <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>
 <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>
Message-ID: <xf8xFVs7FxitPbz2_I4a-pq5gnu_IPVyvmAtjci2Xs8=.433d8116-a466-4561-a6f6-7bd27aca8d94@github.com>

On Tue, 3 Sep 2024 15:50:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> > I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
>>> 
>>> MethodData does a lot of deallocations from metaspace because it's allocated racily. It might be using Metaspace wrong.
>> 
>> I think that should be okay. This should still be an exception. I have never seen that many deallocations happening in customer cases.
>
>> @tstuefe Do you have more comments on this PR?
> 
> Sorry, I was swamped the past days. I'll take a look tomorrow.

AFAIK, @tstuefe (currently on vacation) has a working prototype of a Klass-lookup-table with good performance and reasonable ?management cost?. This would make make many things much simpler and also help solve this problem because it makes irrelevant where a Klass lives.

Roman

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401435370

From john.r.rose at oracle.com  Wed Oct  9 06:40:19 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 08 Oct 2024 23:40:19 -0700
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat
In-Reply-To: <CN7Hdbyjs1viSsFMNtZ-9slELL9R8kBJ-LhvSVBf5Xo=.3e167a5a-3dbe-43fc-be21-3c35c66538a3@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <V_rbtXm-D51NI2k-OYr4NgPiy4E9IEpyeeail9xpZVs=.970a7142-15d6-4df9-8ed4-509b129659f1@github.com>
 <CN7Hdbyjs1viSsFMNtZ-9slELL9R8kBJ-LhvSVBf5Xo=.3e167a5a-3dbe-43fc-be21-3c35c66538a3@github.com>
Message-ID: <1AE115AD-52F1-4E64-B878-E512B3E9158A@oracle.com>

On 8 Oct 2024, at 14:47, Ioi Lam wrote:

> On Wed, 25 Sep 2024 17:14:54 GMT, Chen Liang <liach at openjdk.org> wrote:
>
>>> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
>>> 403:         if (AOTHolder.archivedMethodTypes != null) {
>>> 404:             MethodType mt = AOTHolder.archivedMethodTypes.get(primordialMT);
>>
>> Can we populate these AOT MTs into the internTable so we only look up once?
>
> There's a trade off here --
> start-up will be slowed down if the archivedMethodTypes table is big. Also, `internTable` uses more memory as it wraps every entry inside a weak reference.

I think there is a design pattern should be thinking about,
which I have been calling the ?Three Table Solution?.  (And
there might be just Two Tables.)  The runtime table is the
existing intern table with its weak references.  It is
designed for fast queries, fast updates, and good relations
with the GC.  It does not have the best possible footprint.
The AOT table is archivedMethodTypes.  It is designed for
compactness, fast static boot-up, and reasonably fast queries.
It is read-only.  (It is permitted to have slower queries,
such as in a log N tree instead of O(1) hash table, but if
that is the case then entries should be migrated into the
main runtime table as they are extracted.)

A third table, maybe, is the startup table; it collects
entries at startup before the big main runtime table can
be created.  It might also serve instead of the runtime
table during the assembly phase.  Its main property is
simplicity, meaning lack of complex init-dependencies
on the rest of the JDK.  It does not need weak refs,
or any other kind of scalability, because it will
be quickly retired when the system boots up.  In
fact, the AOT table is likely to fulfill all early
queries, so the startup table is probably empty,
as long as an AOT cache is available.  The startup
table might be useful for exploded builds, as well
as for the assembly phase.  Note that while the
startup table exists, the main runtime table is
not yet created; its static reference is null.
(It should be a @Stable field!)

That third table is not very useful if we can figure
out how to use the main runtime table (with its
weak refs) at all init phases.  So maybe this design
pattern is the Two Table Solution, if we can tame
weak refs for Leyden.

But I do think we have a long-term need for two
tables, with an AOT one optimized for fast boot-up
and compactness (and slow to create, and not mutated
during startup).

The order of operations could be:

A. check AOT table; if present, return
B. check main table or startup table; if present, return
C. make new object, install in appropriate table, return

But in some cases it is better to always check the main
table first, if it exists.  (A @Stable reference will
make the query method inline, after the JIT gets ahold
of the object.)  Like this:

A. check main table; if present, return
B. check AOT table or startup table
B1. if present, and if main table exists, move to main table
B2. if present, then return
C. make new object, install in appropriate table, return

> PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1782292378

From jpai at openjdk.org  Wed Oct  9 06:46:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 06:46:01 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
Message-ID: <orHTgkDu-0zcXrYvCrOtB-iUCKFXkROpS4szSpxscb0=.aaac08eb-6f3e-46a0-b9b1-23e187c884dc@github.com>

On Wed, 9 Oct 2024 05:50:18 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording: 'If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.'

src/java.base/share/classes/java/io/Reader.java line 182:

> 180:             private void ensureOpen() throws IOException {
> 181:                 if (isClosed)
> 182:                     throw new IOException("Stream closed");

Should the exception text instead be "Reader closed" and also the code comment a couple of lines above, replace "stream" to "reader"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792936385

From jpai at openjdk.org  Wed Oct  9 07:00:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 07:00:21 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v5]
In-Reply-To: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
Message-ID: <RVqTDqexv9ICI2fzagkynzzJBJkVpEZ5NlrpUk5070k=.2aebc7a0-e88d-4205-84c9-71ba37c6f913@github.com>

> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
> 
> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
> 
> 
> $> jrunscript
> script engine for language js can not be found
> 
> 
> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Mandy's review suggestion for man page

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21380/files
  - new: https://git.openjdk.org/jdk/pull/21380/files/b045f298..f2318263

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21380&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21380&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21380/head:pull/21380

PR: https://git.openjdk.org/jdk/pull/21380

From alanb at openjdk.org  Wed Oct  9 07:02:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Oct 2024 07:02:59 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>
Message-ID: <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>

On Sun, 6 Oct 2024 13:14:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Reader.of(CharSequence) looks much better than introducing CharSequenceReader. It won't have an equivalent on Writer but I think that is okay. Also it means that the user will need to deal with close throwing IOException but anything using Reader has to do this already.
> 
> I think it would be better to drop "API compatible with StringReader" from the method description. An apiNote in StringReader can direct readers to the static factory method.
> 
> Also I think drop the  "lock" field from the API docs as it's a protected field and only interesting to subclasses.  The Reader class does not specify if Reader is thread-safe so the method description doesn't need to say too much. For clarify then it could just say something like "the resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization".
> 
> The parameter name is currently "c", maybe you mean "cs"? The method will need to specify NPE for the of(null) case.

> @AlanBateman Can you please review [the CSR request](https://bugs.openjdk.org/browse/JDK-8341596) so I can finish it? Thanks!

Latest API docs looks good, will you update the CSR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2401489513

From duke at openjdk.org  Wed Oct  9 07:03:02 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 07:03:02 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <orHTgkDu-0zcXrYvCrOtB-iUCKFXkROpS4szSpxscb0=.aaac08eb-6f3e-46a0-b9b1-23e187c884dc@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
 <orHTgkDu-0zcXrYvCrOtB-iUCKFXkROpS4szSpxscb0=.aaac08eb-6f3e-46a0-b9b1-23e187c884dc@github.com>
Message-ID: <vB6FMxn0TrZwEsqi9wJmETeoOmEKSFDQUqgH9nUIap0=.5544bad6-db9a-49b4-b5cd-87b3e2f7c3e2@github.com>

On Wed, 9 Oct 2024 06:43:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved wording: 'If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.'
>
> src/java.base/share/classes/java/io/Reader.java line 182:
> 
>> 180:             private void ensureOpen() throws IOException {
>> 181:                 if (isClosed)
>> 182:                     throw new IOException("Stream closed");
> 
> Should the exception text instead be "Reader closed" and also the code comment a couple of lines above, replace "stream" to "reader"?

The complete implementation was copied from "StringReader" (see https://github.com/openjdk/jdk/blob/d809bc0e21b145758f21c4324772faf6aa6a276a/src/java.base/share/classes/java/io/StringReader.java#L57), so it was "Stream closed" there already, and "StringReader" now refers to this new code location. I deliberately did not modify anything else but the essentially needed parts. If we change this text here, this might be unexpected by existing applications.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792973262

From jpai at openjdk.org  Wed Oct  9 07:11:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 07:11:59 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <vB6FMxn0TrZwEsqi9wJmETeoOmEKSFDQUqgH9nUIap0=.5544bad6-db9a-49b4-b5cd-87b3e2f7c3e2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
 <orHTgkDu-0zcXrYvCrOtB-iUCKFXkROpS4szSpxscb0=.aaac08eb-6f3e-46a0-b9b1-23e187c884dc@github.com>
 <vB6FMxn0TrZwEsqi9wJmETeoOmEKSFDQUqgH9nUIap0=.5544bad6-db9a-49b4-b5cd-87b3e2f7c3e2@github.com>
Message-ID: <RgSOCWSRvDaoNDHNrUAm22omr7MXgZWOWAo5hO1tmY4=.721e3178-02b9-4cee-8c5e-1fdfcd593c94@github.com>

On Wed, 9 Oct 2024 06:59:25 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 182:
>> 
>>> 180:             private void ensureOpen() throws IOException {
>>> 181:                 if (isClosed)
>>> 182:                     throw new IOException("Stream closed");
>> 
>> Should the exception text instead be "Reader closed" and also the code comment a couple of lines above, replace "stream" to "reader"?
>
> The complete implementation was copied from "StringReader" (see https://github.com/openjdk/jdk/blob/d809bc0e21b145758f21c4324772faf6aa6a276a/src/java.base/share/classes/java/io/StringReader.java#L57), so it was "Stream closed" there already, and "StringReader" now refers to this new code location. I deliberately did not modify anything else but the essentially needed parts. If we change this text here, this might be unexpected by existing applications.

Okay, it's reasonable to keep it in this form then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792984990

From duke at openjdk.org  Wed Oct  9 07:23:58 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 07:23:58 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>
 <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>
Message-ID: <poJzIOKv1s_0w5nv71y0A6n8LnNTFFd7L1OmHAJ48II=.360fafad-37f3-45af-b550-35de6a38e4c7@github.com>

On Wed, 9 Oct 2024 06:57:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman Can you please review [the CSR request](https://bugs.openjdk.org/browse/JDK-8341596) so I can finish it? Thanks!
> 
> Latest API docs looks good, will you update the CSR?

Done. I have replaced the "Specification" section of the [CSR](https://bugs.openjdk.org/browse/JDK-8341596) a minute ago. If you agree, I will switch the CRS from Draft to Finalized now to start the CSR Review Process. Ok?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2401530880

From jpai at openjdk.org  Wed Oct  9 07:23:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 07:23:59 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
Message-ID: <yUwCOkrg_-tF_SwpowW87cY_Ze4GGwmbQupG20t4iDE=.08ac42d2-77bf-452a-b6ae-7786c32ed38f@github.com>

On Wed, 9 Oct 2024 05:50:18 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording: 'If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.'

test/jdk/java/io/Reader/Of.java line 40:

> 38:  * @bug 8341566
> 39:  * @run testng Of
> 40:  * @summary Check for expected behavior of Reader.of().

Nit - the jtreg documentation recommends the following order of these tags https://openjdk.org/jtreg/tag-spec.html#ORDER. For newly introduced tests, like this one, it will be good to follow that recommendation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1792999932

From jwaters at openjdk.org  Wed Oct  9 07:28:58 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 9 Oct 2024 07:28:58 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
 <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>
Message-ID: <0phEjRhdkzoktdn5f-VmwNddCFABbKUw0XKgLENxsII=.44778b32-2039-4b52-9b97-40b5ee690675@github.com>

On Wed, 9 Oct 2024 06:25:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 393:
>> 
>>> 391: 
>>> 392:       hcreate_r(htab_sz, symtab->hash_table);
>>> 393:       // guarantee(rslt, "unexpected failure: hcreate_r");
>> 
>> The commented out guarantee line references rslt. I'm not so sure why it was commented out, but it goes back to the initial load of the file 17 years ago. It looks like the correct thing to do if rslt is null is to "goto bad;" but that change is probably beyond the scope of this PR. Maybe file a new CR.
>
> Hi Chris , I created https://bugs.openjdk.org/browse/JDK-8341820 for the return value checking.

Might be a good idea to have rslt commented out rather than removed outright if we don't want to forget about it. guarantee on a variable that doesn't exist will be rather confusing to anyone reading through the code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1793006705

From jpai at openjdk.org  Wed Oct  9 07:30:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 07:30:00 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
Message-ID: <vXqQKZJaN-9y_jx8tUBD4saZEb_bCAnKmlAz6sq9mVE=.010a5946-e5de-42bb-94b7-6da977a33332@github.com>

On Wed, 9 Oct 2024 05:50:18 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording: 'If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.'

test/jdk/java/io/Reader/Of.java line 42:

> 40:  * @summary Check for expected behavior of Reader.of().
> 41:  */
> 42: public class Of {

Would it be possible to include a test which creates and operates on a `Reader` which is backed by a `CharSequence` of zero length. Similarly, a test which creates and operates on a `Reader` which is backed by a `CharSequence` of `Integer.MAX_VALUE` length? I think that should give us good coverage for the implementation of the returned `Reader` for these corner cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793007673

From jpai at openjdk.org  Wed Oct  9 07:38:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 07:38:08 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
Message-ID: <sk2ihRjrHfD-dsgyGXR8eUetSVrMz4TOPRSabsisV84=.47a1e122-f75b-4b80-9747-f61d28c847b6@github.com>

On Wed, 9 Oct 2024 05:50:18 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording: 'If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.'

test/jdk/java/io/Reader/Of.java line 168:

> 166:     }
> 167: 
> 168:     @Test(dataProvider = "readers", expectedExceptions = IOException.class)

Instead of `expectedExceptions` at the method level, I think it would be better to use something like:


org.testng.Assert.assertThrows(IOException.class,
                               () -> {reader.read();});

That way it's clear which operation within the test method is expected to throw this exception and it also prevents unexpected `IOException` (for example, from reader.close()) from going unnoticed.

test/jdk/java/io/Reader/Of.java line 174:

> 172:     }
> 173: 
> 174:     @Test(dataProvider = "readers", expectedExceptions = IOException.class)

Same comment as above, here and the other test methods, about using assertThrows instead of expectedExceptions at the method level.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793015110
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793017336

From sspitsyn at openjdk.org  Wed Oct  9 07:41:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 07:41:01 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
Message-ID: <l62MaX_wTbJ-eaAjO6fRx2W3DgWyZNY1IusPNj7Nxas=.7f90107c-8597-4c50-b6da-7ff399886812@github.com>

On Mon, 7 Oct 2024 22:41:06 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test id=virtual
> 
> Having 'id=virtual' not needed and might confuse people. They expect to have other test variations for platform.

Good suggestion, thanks. Removed.

> test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 32:
> 
>> 30: 
>> 31: public class CheckHiddenFrames {
>> 32:     private static final String AGENT_LIB = "CheckHiddenFrames";
> 
> It is not used?

Thanks, removed. I saw it but forgot to remove.

> test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 43:
> 
>> 41: 
>> 42:     public static void main(String[] args) throws Exception {
>> 43:         Thread thread = Thread.ofVirtual().unstarted(CheckHiddenFrames::test);
> 
> You can use 
> startVirtualThread
> to save one line.

Good suggestion, thanks.
Changed to use startVirtualThread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793023718
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793024733
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793023025

From jlahoda at openjdk.org  Wed Oct  9 07:46:58 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Oct 2024 07:46:58 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell
In-Reply-To: <YppxZnLfQP_sxc5bWKJiVtyT10-t6VPAuK9rz0ST2PY=.36fff337-c25f-42c2-80dc-e066910534b9@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <YppxZnLfQP_sxc5bWKJiVtyT10-t6VPAuK9rz0ST2PY=.36fff337-c25f-42c2-80dc-e066910534b9@github.com>
Message-ID: <1CC9kr0VJsQaorRX3B7032qT7sPPPCYYKfKBSzmRXoc=.d858c464-eb27-4085-a9d0-12be800ea0f2@github.com>

On Tue, 8 Oct 2024 15:38:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Yay! This looks so much better than the default blob. I think you are on the right track, but the actual message can do with some fine tuning. For instance, `<what to execute>` seems a bit ... untypically non-formal. What about just `<target>`?

I am not insisting on any of the wording, and suggestions are welcome, of course. But `<what to execute>` (to me) describes fairly specifically what the part of the command line is doing. `<target>` seems much less descriptive/specific. I was thinking of a different way to say `<what to execute>`, that would not loose the descriptiveness, but none so far. Any more descriptive/specific suggestions than `<target>`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2401581360

From mbaesken at openjdk.org  Wed Oct  9 07:50:20 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 07:50:20 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8340801
 - move ub.h to a better location
 - remove ubsan changes from jni_md.h
 - JDK-8340801

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21184/files
  - new: https://git.openjdk.org/jdk/pull/21184/files/cfbf904b..0ada81d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21184&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21184&range=02-03

  Stats: 43717 lines in 740 files changed: 35146 ins; 4910 del; 3661 mod
  Patch: https://git.openjdk.org/jdk/pull/21184.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21184/head:pull/21184

PR: https://git.openjdk.org/jdk/pull/21184

From jpai at openjdk.org  Wed Oct  9 07:53:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 07:53:59 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
Message-ID: <D4M0BKwgtrBqvn011a3pFboWpm3syZwn-WxT56VoWhk=.65c83d22-f40b-47b7-9f6c-b0951cb38d03@github.com>

On Wed, 9 Oct 2024 05:50:18 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved wording: 'If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.'

In a different discussion, I have been told previously that the title of the CSR and the JBS issue for which the CSR is created, should match. I think we should change the title of https://bugs.openjdk.org/browse/JDK-8341566 to match what you have for the CSR, since that one is more clear.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2401594697

From sspitsyn at openjdk.org  Wed Oct  9 07:57:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 07:57:57 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
Message-ID: <iHBB9WaX2eRMLqSEU9AljvIf2Uijye3ShZFidwO4A5Q=.5e5f20b7-fac9-4ed8-953c-2ce4e231da17@github.com>

On Mon, 7 Oct 2024 23:43:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2009:
> 
>> 2007:   bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
>> 2008: 
>> 2009:   // Target can be virtual or platform thread.
> 
> Can you please explain in comment why is it needed to disable all threads for platform target thread.

Thank you for suggestion. Explained comment.
Now, it looks as below:

  // Target can be virtual or platform thread.
  // Disable VTMS transition for one thread if it is virtual.
  // Otherwise, disable VTMS transitions for all threads
  // to protect against VTMS transitions in carrier threads.
  // For the latter VTMS transitions are disabled for all threads by several reasons:
  // - carrier threads can mount virtual threads which may cause incorrect behavior
  // - it is good invariant if we can ensure no VTMS transition might happen at some points 
  // - there is no mechanism to disable transitions for a specific carrier threads yet

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793048247

From jpai at openjdk.org  Wed Oct  9 07:59:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Oct 2024 07:59:57 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell
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: <ufAfmDlM2yBdU6aFuIzND3KU4CCbbFOmqHosppy6HE4=.09ad6a0c-41d9-4b69-9a2c-d7807e0643d5@github.com>

On Tue, 8 Oct 2024 15:28:17 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` launcher, 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 launcher 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:
> 
> $ java
> openjdk 24-internal 2025-03-18
> 
> Usage: java [options...] <what to execute> [arguments to main method...]
> 
> Where <what to execute> is one of:
>   <MainClass>                to execute the main method of a compiled class
>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>   -m <module>[/<MainClass>]  to execute the main class of a module
>   <SourceFile.java>          to compile and execute a single-file program
> 
> Where key options include:
>   --class-path <class path>
>       a : separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a : separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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!

Hello Jan,

> Any more descriptive/specific suggestions than target?

I suspect you might already know this - internally, in the launcher implementation, this is called "launch mode" (represented as "Unknown", "Main class", "JAR file", "Module", "Source" modes). I however don't know if it will be appropriate to use `<launch mode>` here in the help text.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2401612115

From sspitsyn at openjdk.org  Wed Oct  9 08:01:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 08:01:58 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
Message-ID: <kXRB8fBrS6h55TTpQDt1H0xBGjOgpHze4_6DFOGznjo=.c1a91b7a-f5d5-43d1-aa75-0334e1f57dd7@github.com>

On Tue, 8 Oct 2024 00:11:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 691:
> 
>> 689: 
>> 690:   if (is_virtual || jt->is_in_VTMS_transition()) { // filter out pure continuations
>> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
> 
> Wouldn't be easier to split method `check_and_skip_hidden_frames` to skip_yeilds and skip_transition frames? 
> BTW Also it is unclear shouldn't the `@Hidden` methods be skipped from all jvmti frame streams?

Good suggestion, thanks. I was also thinking about it but was not sure it can be simplified.
JVMTI does not support @Hidden annotation which is used in Java `printStackTrace()` api implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793054337

From duke at openjdk.org  Wed Oct  9 08:09:02 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 08:09:02 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader [v6]
In-Reply-To: <D4M0BKwgtrBqvn011a3pFboWpm3syZwn-WxT56VoWhk=.65c83d22-f40b-47b7-9f6c-b0951cb38d03@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
 <D4M0BKwgtrBqvn011a3pFboWpm3syZwn-WxT56VoWhk=.65c83d22-f40b-47b7-9f6c-b0951cb38d03@github.com>
Message-ID: <8WNaFyct5O-0f3LWlQXAsdRw90w8CwzQBCs22tPqE70=.f71c65d0-446a-47f8-8689-ae4e1724f2a3@github.com>

On Wed, 9 Oct 2024 07:51:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> In a different discussion, I have been told previously that the title of the CSR and the JBS issue for which the CSR is created, should match. I think we should change the title of https://bugs.openjdk.org/browse/JDK-8341566 to match what you have for the CSR, since that one is more clear.

I have no strong feelings, but the reason for deviation is that the JBS proposes to introduce "some" factory (the outcome is open at time of JBS creation and was found _later_, while discussing the PR), while the CSR is explicitly about the exact wish for literally `Reader.of(final CharSequence cs)`. I do not know the intentions of the team that has set up the process rules for JBS and CSR. If both need to be exact the same, then I wonder why JIRA allows to modify the CSR title manually...? The sole answer I could imagine was: Because of exact that difference between "some" factory and exactly `Reader.of`. ? 

@AlanBateman WDYT?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2401630172

From shade at openjdk.org  Wed Oct  9 08:44:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Oct 2024 08:44:34 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Simplify: just do keep alive checks
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - More precise bit-unmasks
 - Reconcile with late barrier expansion in G1
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Review comments
 - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
 - Also dispatch to slow-path on other arches
 - Fix other arches
 - Tighten up comments in Reference javadoc
 - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

-------------

Changes: https://git.openjdk.org/jdk/pull/20139/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=08
  Stats: 361 lines in 25 files changed: 340 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/20139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139

PR: https://git.openjdk.org/jdk/pull/20139

From shade at openjdk.org  Wed Oct  9 08:44:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Oct 2024 08:44:35 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v8]
In-Reply-To: <1wozINQzLtWk9n5DJDqTW_BBQgwmOGQpJAfOJR70uC0=.7668e905-c863-4e69-bca1-695de43cb80a@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <rNpimPcUXtS9bRuyB4dBKbuMRfEGkRaW4JAno8hEme4=.34a58972-e703-4ae3-9c8e-da3406819b85@github.com>
 <1wozINQzLtWk9n5DJDqTW_BBQgwmOGQpJAfOJR70uC0=.7668e905-c863-4e69-bca1-695de43cb80a@github.com>
Message-ID: <N9Uf3-NXRx83CwpY5v4BVueYU3bfaN33tiODxBt_mBc=.fa0a6ff5-d945-44c5-ab70-1d484bb1c8af@github.com>

On Mon, 7 Oct 2024 08:15:21 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More precise bit-unmasks
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 342:
> 
>> 340:   }
>> 341:   if ((on_weak || on_phantom) && no_keepalive) {
>> 342:     // Be extra paranoid around this path. Only accept null stores,
> 
> I think there might be some orthogonal stuff that is unnecessarily mixed up here. When no_keepalive is manually specified, then we shouldn't do the pre-write barrier, regardless of reference strength. Similarly, when the new value is null, we don't need to perform the post write barrier, regardless of reference strength. Roberto added some code in refine_barrier_by_new_val_type that already *should* take care of the latter part. It allows types to flow around a bit, and then checks if the type of the new value is provably null, and then removes the post write barrier. The existing logic for that should be strictly more powerful than the new check you added, I think.
> 
> Based on the above explanation, I think I'm proposing this block is replaced with this simpler condition:
> 
> if (no_keepalive) {
>   access.set_barrier_data(access.barrier_data() & ~G1C2BarrierPre);
> }

Right. We also do not need this complexity in Shenandoah barriers. This check was dragged here from the load barriers that _want_ to check if we are reading the `Reference.referent` and feed it to SATB _unless_ there is a no-keep-alive. For store barriers it is unnecessary, and we can just do keep-alive checks straight up. Should be done in new commit, testing now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1793115683

From aph at openjdk.org  Wed Oct  9 09:03:09 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 09:03:09 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <_VdTzvXOhImLlu7ZA9PRxqK3TSrKYWAyQGXWr-XYsO0=.d8f8f09f-b655-4514-a536-1066a0dddc68@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

On 10/9/24 06:53, John Rose wrote:

 > It looks like the compression needs to be partial, down to about 32 bits.

Yes, that's true. Slightly fewer bits would be nice, for tags.

 > So it looks like (a) having ALL klass IDs fit in 32 bits, and (b)
 > having all CONCRETE klass IDs fit into a smaller part of the same
 > range, would meet all requirements. Doing it right might require TWO
 > new companion types for Klass*, a compact concrete klass ID, and a
 > 32-bit klass ID (supertype to compact concrete klass ID). I think
 > the larger one could be called narrowKlass (current name), and maybe
 > the narrower concrete ID could be called narrowConcreteKlass or
 > narrowestKlass or something like that.

I see, I think.

Simply keeping all of metadata in a single 32-bit range would be very
useful. We could have instantiable Klasses in one region, followed by
non-instantiable Klasses.

 > (Because of CDS, and maybe other factors, some compact concrete
 > klass IDs will actually point to interfaces or abstract classes. So
 > narrowConcreteKlass suggests a property of its referents that isn?t
 > exactly true.)

 > The way I read this is to think about putting, not klass and
 > non-klass, but concrete-klass and non-concrete-klass IDs in the same
 > range. (By ID I mean a compressed Klass pointer, or alternatively an
 > index into some sort of special table that we haven?t needed to
 > invent.)

While I've now thought of a way to encode Klass pointers that doesn't
need them all to be in the same 32-bit range, it may well be very
useful in other contexts to ensure that they will be.

Maybe we could reduce the footprint of Klass instances. Right now,
though, my invokeinterface prototypes *increase* the size of Klass
instances, so I really want to have the possibility of using
compressed metadata pointers.

For what it's worth, I'm relieved that we're not yet making Klass
pointers a table index. Another chained load in the path of method
dispatch, at a time when I'm trying to get rid of chained loads, would
be a Bad Thing for me.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401747594

From jbhateja at openjdk.org  Wed Oct  9 09:59:11 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 9 Oct 2024 09:59:11 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
Message-ID: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>

> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>   
> 
>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>  
> VPMULUDQ 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
> VectorXXH3HashingB...

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
 - 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=01
  Stats: 354 lines in 12 files changed: 343 ins; 0 del; 11 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  Wed Oct  9 10:04:07 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 10:04:07 GMT
Subject: Integrated: 8341141: Optimize DirectCodeBuilder
In-Reply-To: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
References: <bf4M9IEAqjQtkvCL9-uXSPOF9PsooK7wybLqt4LwAPQ=.296099d4-b119-4cea-8b09-e14c13a21a08@github.com>
Message-ID: <l-Nc7-bFQ-irPDHnMhyRjLk7l7TxBgbWI24acp5n_j8=.b89f7851-2ba7-4078-a14f-ededb6bd365e@github.com>

On Sun, 29 Sep 2024 00:02:38 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Some DirectCodeBuilder related optimizations to improve startup and running performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load and store

This pull request has now been integrated.

Changeset: 047c2d7f
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/047c2d7f2676b8c3c8b5645134fb5c00c540e43f
Stats:     1012 lines in 19 files changed: 599 ins; 131 del; 282 mod

8341141: Optimize DirectCodeBuilder

Co-authored-by: Claes Redestad <redestad at openjdk.org>
Co-authored-by: Chen Liang <liach at openjdk.org>
Reviewed-by: liach, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/21243

From jbhateja at openjdk.org  Wed Oct  9 10:11:03 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 9 Oct 2024 10:11:03 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
Message-ID: <QFyjgifYwi6F953gcME5Zz2m4gczLO5wKt2oUabgNZo=.73cace81-7e0e-4c02-844e-9ad9240454ea@github.com>

On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

Hi @iwanowww , @sviswa7, @merykitty, Can you kindly review this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2401895553

From mbaesken at openjdk.org  Wed Oct  9 10:38:57 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 10:38:57 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <0phEjRhdkzoktdn5f-VmwNddCFABbKUw0XKgLENxsII=.44778b32-2039-4b52-9b97-40b5ee690675@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
 <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>
 <0phEjRhdkzoktdn5f-VmwNddCFABbKUw0XKgLENxsII=.44778b32-2039-4b52-9b97-40b5ee690675@github.com>
Message-ID: <hTF-irWGYZkkbPeiwSvWNBp6N_UiGJdWRlwJ5UXBoQA=.a6ab4ebc-26d2-4c39-924e-00643f031756@github.com>

On Wed, 9 Oct 2024 07:26:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Might be a good idea to have rslt commented out 

Why not; Chris what do you say ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1793282296

From alanb at openjdk.org  Wed Oct  9 10:43:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Oct 2024 10:43:59 GMT
Subject: RFR: 8341566: Adding factory for non-synchronized CharSequence
 Reader
In-Reply-To: <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>
 <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>
Message-ID: <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>

On Wed, 9 Oct 2024 06:57:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Reader.of(CharSequence) looks much better than introducing CharSequenceReader. It won't have an equivalent on Writer but I think that is okay. Also it means that the user will need to deal with close throwing IOException but anything using Reader has to do this already.
>> 
>> I think it would be better to drop "API compatible with StringReader" from the method description. An apiNote in StringReader can direct readers to the static factory method.
>> 
>> Also I think drop the  "lock" field from the API docs as it's a protected field and only interesting to subclasses.  The Reader class does not specify if Reader is thread-safe so the method description doesn't need to say too much. For clarify then it could just say something like "the resulting Reader is not safe for use by multiple concurrent threads. If the Reader is to be used by more than one thread it should be controlled by appropriate synchronization".
>> 
>> The parameter name is currently "c", maybe you mean "cs"? The method will need to specify NPE for the of(null) case.
>
>> @AlanBateman Can you please review [the CSR request](https://bugs.openjdk.org/browse/JDK-8341596) so I can finish it? Thanks!
> 
> Latest API docs looks good, will you update the CSR?

> @AlanBateman WDYT?

A title like "Add Reader.of(CharSequence)" would make it clear to everyone what this issue, and the CSR, is about.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2401960681

From galder at openjdk.org  Wed Oct  9 11:07:59 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Wed, 9 Oct 2024 11:07:59 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <HV0EXWSdcCOAoBfxHSoFZMqfBVhMAJj0Fr55gbi8HQo=.914bb5da-62fe-487b-bbcb-a7ece87e1d58@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
 <HV0EXWSdcCOAoBfxHSoFZMqfBVhMAJj0Fr55gbi8HQo=.914bb5da-62fe-487b-bbcb-a7ece87e1d58@github.com>
Message-ID: <1hqzRjRFI8wC_c65Nc0rDAni6sxkuSqMdMeGEDZLcXo=.30446bbb-0646-4830-b840-82c0a7d882b6@github.com>

On Mon, 30 Sep 2024 10:35:35 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> You've probably seen this but the new test is failing IR verification:
> 
> ```
> Failed IR Rules (4) of Methods (4)
> ----------------------------------
> 1) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMax(double,double)" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 1: "(\\d+(\\s){2}(MaxD.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 0 = 1 [given]
>            - No nodes matched!
> 
> 2) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMin(double,double)" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 1: "(\\d+(\\s){2}(MinD.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 0 = 1 [given]
>            - No nodes matched!
> 
> 3) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMax(float,float)" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 1: "(\\d+(\\s){2}(MaxF.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 0 = 1 [given]
>            - No nodes matched!
> 
> 4) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMin(float,float)" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>      > Phase "PrintIdeal":
>        - counts: Graph contains wrong number of nodes:
>          * Constraint 1: "(\\d+(\\s){2}(MinF.*)+(\\s){2}===.*)"
>            - Failed comparison: [found] 0 = 1 [given]
>            - No nodes matched!
> ```

@TobiHartmann the reason for this failure is that hotspot doesn't check whether max/min[F,D] intrinsics are available for x86. E.g.


  case vmIntrinsics::_maxD:
  case vmIntrinsics::_maxD_strict:
    if (!Matcher::match_rule_supported(Op_MaxD)) return false;
    break;


I tried to replicate the test failures with the latest master, but it doesn't build with x86:


* For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/g/1/jdk-intrinsify-max-min-long/src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp:747), pid=319052, tid=319399
#  Error: Unimplemented()
#
# JRE version: OpenJDK Runtime Environment (24.0) (fastdebug build 24-internal-adhoc.g.jdk-intrinsify-max-min-long)
# Java VM: OpenJDK Server VM (fastdebug 24-internal-adhoc.g.jdk-intrinsify-max-min-long, mixed mode, tiered, g1 gc, linux-x86)
# Problematic frame:
# V  [libjvm.so+0x529eca]  BarrierSetAssembler::refine_register(Node const*, int)+0x1a


This build failure is caused by the late barrier expansion work, which is unimplemented for x86:


OptoReg::Name BarrierSetAssembler::refine_register(const Node* node, OptoReg::Name opto_reg) {
  Unimplemented(); // This must be implemented to support late barrier expansion.
}


Looking at some other recent PRs, seems like there's no full build of x86 done any more, with only hotspot being build, and there is no testing executed. E.g. https://github.com/rwestrel/jdk/actions/runs/11145151555.

So, if x86 builds are not run, seems like there's no need to fix this? Otherwise there are several ways this can be fixed: disable test for x86, or to check max/min[F,D] intrinsics are available for x86 before adding the nodes to the IR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2402013495

From mcimadamore at openjdk.org  Wed Oct  9 11:24:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Oct 2024 11:24:43 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v8]
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <0WeR12j3CDMiE5v6OT8XA0uiSok4bCtpN7NP26AQdc0=.15131fa1-930c-4c61-85d1-d9a999d4b64d@github.com>

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

Maurizio Cimadamore 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 'master' into restricted_better_javadoc
 - Merge pull request #22 from hns/restricted_better_javadoc
   
   Only link restricted method doc-file if it is available
 - Only link restricted method doc-file if it is available
 - Fix paths to links
 - Fix javadoc test failure
 - Revert reference to caller stack
 - Update src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Move restricted method page to `java.lang`
   Update restricted method page
 - Initial push

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21067/files
  - new: https://git.openjdk.org/jdk/pull/21067/files/af0a13c0..75fc7f50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21067&range=06-07

  Stats: 202084 lines in 1478 files changed: 187422 ins; 7775 del; 6887 mod
  Patch: https://git.openjdk.org/jdk/pull/21067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21067/head:pull/21067

PR: https://git.openjdk.org/jdk/pull/21067

From mbaesken at openjdk.org  Wed Oct  9 11:44:35 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 11:44:35 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
Message-ID: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>

> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust gcc warning settings; bring back rslt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21407/files
  - new: https://git.openjdk.org/jdk/pull/21407/files/ee3546b1..705bd07b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21407&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21407&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21407/head:pull/21407

PR: https://git.openjdk.org/jdk/pull/21407

From mbaesken at openjdk.org  Wed Oct  9 11:47:00 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 11:47:00 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
Message-ID: <-lxjK9aLbWpegpHr8XKWFqLck4OShpBuuBpWrLMkMyk=.5450dde8-025f-4a94-8f50-605f246e3578@github.com>

On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

I brought back `rslt`  but uncommented, as suggested.

Additionally I removed some special gcc warning setting; those disabled the symtab.c and LinuxDebuggerLocal.cpp  related warnings when compiling with gcc (brings clang and gcc behavior a bit closer together).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21407#issuecomment-2402092775

From duke at openjdk.org  Wed Oct  9 11:49:47 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 11:49:47 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with two additional commits since the last revision:

 - assertThrows instead of expectedExceptions
 - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/75cb4fc6..c0729baf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=05-06

  Stats: 16 lines in 1 file changed: 1 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From duke at openjdk.org  Wed Oct  9 11:49:48 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 11:49:48 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence)
In-Reply-To: <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>
 <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>
 <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>
Message-ID: <B83azR728AZ30YcgvYjMrykpEgYvkO9cH9g1QIbhao8=.a44da26b-d58c-42a8-853f-4ebfb539bf81@github.com>

On Wed, 9 Oct 2024 10:40:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman WDYT?
> 
> A title like "Add Reader.of(CharSequence)" would make it clear to everyone what this issue, and the CSR, is about.

Changed in PR, RFE and CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2402095168

From duke at openjdk.org  Wed Oct  9 11:49:48 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 11:49:48 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v6]
In-Reply-To: <yUwCOkrg_-tF_SwpowW87cY_Ze4GGwmbQupG20t4iDE=.08ac42d2-77bf-452a-b6ae-7786c32ed38f@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <-mAQXWiJvzZ6gk2e88dzb986d1gpXU71VsqwHqfxYHA=.a5ff9711-d914-468c-80fd-0f17eee6a3b2@github.com>
 <yUwCOkrg_-tF_SwpowW87cY_Ze4GGwmbQupG20t4iDE=.08ac42d2-77bf-452a-b6ae-7786c32ed38f@github.com>
Message-ID: <WUUCR6tZ9jivu0TVAQRoVDKMa7YPNSaQl7L7Q_PHAC8=.e80bf400-bedc-42ee-81af-615037af930a@github.com>

On Wed, 9 Oct 2024 07:21:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improved wording: 'If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.'
>
> test/jdk/java/io/Reader/Of.java line 40:
> 
>> 38:  * @bug 8341566
>> 39:  * @run testng Of
>> 40:  * @summary Check for expected behavior of Reader.of().
> 
> Nit - the jtreg documentation recommends the following order of these tags https://openjdk.org/jtreg/tag-spec.html#ORDER. For newly introduced tests, like this one, it will be good to follow that recommendation.

done

> test/jdk/java/io/Reader/Of.java line 42:
> 
>> 40:  * @summary Check for expected behavior of Reader.of().
>> 41:  */
>> 42: public class Of {
> 
> Would it be possible to include a test which creates and operates on a `Reader` which is backed by a `CharSequence` of zero length. Similarly, a test which creates and operates on a `Reader` which is backed by a `CharSequence` of `Integer.MAX_VALUE` length? I think that should give us good coverage for the implementation of the returned `Reader` for these corner cases.

Zero-case is partically covered by the existing test code. Your request looks like a real lot of work, as it implies a complete rewrite of the overall structure of the test - and frankly spoken, my budget for this issue is near to spent already. Does that *really* provide a justifying benefit, given the fact that these are literally edge cases (and given the fact, that the code is a 1:1 copy of `StringReader`, which we all used since decades, including those edge cases)? If you think it is really necessary, can you please post the modified version of `Of.java` here? I will then post it into the PR. Thanks.

> test/jdk/java/io/Reader/Of.java line 168:
> 
>> 166:     }
>> 167: 
>> 168:     @Test(dataProvider = "readers", expectedExceptions = IOException.class)
> 
> Instead of `expectedExceptions` at the method level, I think it would be better to use something like:
> 
> 
> org.testng.Assert.assertThrows(IOException.class,
>                                () -> {reader.read();});
> 
> That way it's clear which operation within the test method is expected to throw this exception and it also prevents unexpected `IOException` (for example, from reader.close()) from going unnoticed.

done.

Does it makes sense to keep the close tests as separate methods then? IMHO their sole existence was due to using `expectedExceptions` instead of `assertThrows`. So now that we *have* `assertThrows`, shall we move the test code itself at the end of the non-close test methods simply? ?

> test/jdk/java/io/Reader/Of.java line 174:
> 
>> 172:     }
>> 173: 
>> 174:     @Test(dataProvider = "readers", expectedExceptions = IOException.class)
> 
> Same comment as above, here and the other test methods, about using assertThrows instead of expectedExceptions at the method level.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793220813
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793313049
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793236618
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793236979

From aboldtch at openjdk.org  Wed Oct  9 11:50:17 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 9 Oct 2024 11:50:17 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational Mode
Message-ID: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>

This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

-------------

Commit messages:
 - Remove XCollectedHeap from HSDB
 - Fix typo in TestZUncommitEvent.java
 - Add missing problem-listing
 - Remove x from jdk.hotspot.agent
 - 8341692: Implement JEP 490: ZGC: Remove the Non-Generational Mode

Changes: https://git.openjdk.org/jdk/pull/21401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341692
  Stats: 39423 lines in 406 files changed: 152 ins; 39003 del; 268 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

PR: https://git.openjdk.org/jdk/pull/21401

From duke at openjdk.org  Wed Oct  9 11:54:01 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 11:54:01 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence)
In-Reply-To: <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>
 <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>
 <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>
Message-ID: <B_Mcxt-2S27sg4qTopBq0lr1Deb1sGkYmWQDViumuIU=.8ffda44d-7bd6-4917-8c4c-e8597ed66ef7@github.com>

On Wed, 9 Oct 2024 10:40:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @AlanBateman Can you please review [the CSR request](https://bugs.openjdk.org/browse/JDK-8341596) so I can finish it? Thanks!
>> 
>> Latest API docs looks good, will you update the CSR?
>
>> @AlanBateman WDYT?
> 
> A title like "Add Reader.of(CharSequence)" would make it clear to everyone what this issue, and the CSR, is about.

> > > @AlanBateman Can you please review [the CSR request](https://bugs.openjdk.org/browse/JDK-8341596) so I can finish it? Thanks!
> > 
> > 
> > Latest API docs looks good, will you update the CSR?
> 
> Done. I have replaced the "Specification" section of the [CSR](https://bugs.openjdk.org/browse/JDK-8341596) a minute ago. If you agree, I will switch the CRS from Draft to Finalized now to start the CSR Review Process. Ok?

@AlanBateman Alan, according to https://wiki.openjdk.org/display/csr, "at least one engineer familiar with that technology area" MUST review the CSR before I may update its state from "Draft" to "Finalized". I would be happy if you would be that engineer, so I have just updated the assignee of this CSR from me to you. Thanks for your help! :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2402103004

From weijun at openjdk.org  Wed Oct  9 11:54:01 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 9 Oct 2024 11:54:01 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell
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: <rReBQ2p6Sjsx-aE747oUcwJndnEPaHg0z9bkIocH4UI=.cf532e46-a396-4384-9731-440a93f4a870@github.com>

On Tue, 8 Oct 2024 15:28:17 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` launcher, 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 launcher 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:
> 
> $ java
> openjdk 24-internal 2025-03-18
> 
> Usage: java [options...] <what to execute> [arguments to main method...]
> 
> Where <what to execute> is one of:
>   <MainClass>                to execute the main method of a compiled class
>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>   -m <module>[/<MainClass>]  to execute the main class of a module
>   <SourceFile.java>          to compile and execute a single-file program
> 
> Where key options include:
>   --class-path <class path>
>       a : separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a : separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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!

I understand what `: separated list` means but in the line it looks like a key and a value. What about `:-separated list` or `list separated by ":"`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2402102939

From ihse at openjdk.org  Wed Oct  9 12:13:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Oct 2024 12:13:00 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell
In-Reply-To: <1CC9kr0VJsQaorRX3B7032qT7sPPPCYYKfKBSzmRXoc=.d858c464-eb27-4085-a9d0-12be800ea0f2@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <YppxZnLfQP_sxc5bWKJiVtyT10-t6VPAuK9rz0ST2PY=.36fff337-c25f-42c2-80dc-e066910534b9@github.com>
 <1CC9kr0VJsQaorRX3B7032qT7sPPPCYYKfKBSzmRXoc=.d858c464-eb27-4085-a9d0-12be800ea0f2@github.com>
Message-ID: <rradLvpPPUA0qeCamCzArsn8rmRoA1g0aFp0lEoBFNU=.87cc788e-10c1-44e3-829c-a1d6464b235a@github.com>

On Wed, 9 Oct 2024 07:44:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>  I was thinking of a different way to say <what to execute>, that would not loose the descriptiveness, but none so far. Any more descriptive/specific suggestions than <target>?

I understand why you ended up with that choice of words, since it is not trivial to find a better phrase. `target` was just the first word that popped up in my mind.

I thought about this for a while now, and I ended up asking ChatGPT. It suggested the (in retrospect obvious) combination `execution target`. I think that's okay. It has the somewhat more formal nuance than `what to execute`, but still gets the preciseness of `what to execute`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2402144178

From ihse at openjdk.org  Wed Oct  9 12:18:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Oct 2024 12:18:56 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell
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: <q9C3_Gwe7a5NufXp-xIssGaVYhLhG-BnI-SNegqiAEw=.feef39a9-c7ef-4c2f-9fb4-fa263591fa87@github.com>

On Tue, 8 Oct 2024 15:28:17 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` launcher, 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 launcher 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:
> 
> $ java
> openjdk 24-internal 2025-03-18
> 
> Usage: java [options...] <what to execute> [arguments to main method...]
> 
> Where <what to execute> is one of:
>   <MainClass>                to execute the main method of a compiled class
>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>   -m <module>[/<MainClass>]  to execute the main class of a module
>   <SourceFile.java>          to compile and execute a single-file program
> 
> Where key options include:
>   --class-path <class path>
>       a : separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a : separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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!

Also `[arguments to main method...]` is very programmer-centric. A typical user does not know that command line arguments are sent to the `main` method; and most likely do not even know what a method is.

Maybe something like:

Usage: java [java options...] <execution target> [application arguments]


or, hm, perhaps even


Usage: java [java options...] <application> [application arguments]

to clarify the tie between options to `java` itself, and to the application you are "actually" running.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2402156707

From duke at openjdk.org  Wed Oct  9 12:18:56 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Wed, 9 Oct 2024 12:18:56 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell
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: <akn0V8ITXJA7ciPNG-6BhTpPeiHL-2HT9UYHW019l8w=.ef2d75db-c0e9-4bdd-bc10-af911330615d@github.com>

On Tue, 8 Oct 2024 15:28:17 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` launcher, 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 launcher 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:
> 
> $ java
> openjdk 24-internal 2025-03-18
> 
> Usage: java [options...] <what to execute> [arguments to main method...]
> 
> Where <what to execute> is one of:
>   <MainClass>                to execute the main method of a compiled class
>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>   -m <module>[/<MainClass>]  to execute the main class of a module
>   <SourceFile.java>          to compile and execute a single-file program
> 
> Where key options include:
>   --class-path <class path>
>       a : separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a : separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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!

fwiw, I'd still like to advocate for "what to execute" as being the easiest to understand; I think a little informality is a small price to pay for that clarity!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2402158047

From duke at openjdk.org  Wed Oct  9 12:27:00 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 9 Oct 2024 12:27:00 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v32]
In-Reply-To: <3FoydNfCzRhNL5Fts7M-30uB-QwPJyZq-DkWlF4NVtk=.b28f509b-15f5-4f16-aff5-9b91f6506246@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <3FoydNfCzRhNL5Fts7M-30uB-QwPJyZq-DkWlF4NVtk=.b28f509b-15f5-4f16-aff5-9b91f6506246@github.com>
Message-ID: <JfOIt-rsXb4fVmgIE7QrR2Sok1rExPwlzsNPMM8TJdI=.28f8776b-b73c-493d-b713-082927e3479d@github.com>

On Mon, 7 Oct 2024 19:35:10 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use log cache of BigInteger

src/java.base/share/classes/java/math/BigDecimal.java line 5268:

> 5266:         intVal = intVal.shiftRight(powsOf2); // remove powers of 2
> 5267:         // maxPowsOf5 == ceil(log5(intVal)) roughly
> 5268:         long maxPowsOf5 = (long) Math.ceil(intVal.bitLength() * BigInteger.LOG_TWO / BigInteger.logCache[5]);

@rgiulietti Can make sense using `Math.round()` instead of `Math.ceil()` to get better upper bound?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793425020

From goetz at openjdk.org  Wed Oct  9 12:34:57 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 9 Oct 2024 12:34:57 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell
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: <0AK7XdiCZOx-PIHhQjGFDiO0d7OuRgITVnMe72DimvA=.41f522bf-be94-4e3f-bc0a-d8da5305e588@github.com>

On Tue, 8 Oct 2024 15:28:17 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` launcher, 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 launcher 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:
> 
> $ java
> openjdk 24-internal 2025-03-18
> 
> Usage: java [options...] <what to execute> [arguments to main method...]
> 
> Where <what to execute> is one of:
>   <MainClass>                to execute the main method of a compiled class
>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>   -m <module>[/<MainClass>]  to execute the main class of a module
>   <SourceFile.java>          to compile and execute a single-file program
> 
> Where key options include:
>   --class-path <class path>
>       a : separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a : separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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!

Hi,
I think this information can be very helpful for people that are not used to Java. 
But I doubt that such people know about the launcher architecture, i.e. that there are several launcher programs that load the libjvm.  So I would avoid the term "launcher" in the documentation and maybe replace it by "program" or "java virtual machine".
Just my 5 cents...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2402195817

From aboldtch at openjdk.org  Wed Oct  9 12:57:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 9 Oct 2024 12:57:36 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:

 - LargeWindowPaintTest.java fix id typo
 - Fix problem-listed @requires typo
 - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
 - Reorder z_globals options: product > diagnostic product > develop
 - Consistent albite special code style
 - Consistent order between ZArguments and GCArguments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21401/files
  - new: https://git.openjdk.org/jdk/pull/21401/files/e5865bc8..22c243a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=00-01

  Stats: 53 lines in 8 files changed: 21 ins; 23 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

PR: https://git.openjdk.org/jdk/pull/21401

From ihse at openjdk.org  Wed Oct  9 13:25:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Oct 2024 13:25:48 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <ZNzx_44LSlFCNk8TdkJ50MT6nE4-OEyrOeK4sBvjPik=.14a10996-5b1d-4c59-8f8a-4c494153ca44@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

Build changes look good.

Are you on a direct track towards winning over the title of Dr Deprecator? ;-)

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2357082736

From stefank at openjdk.org  Wed Oct  9 13:25:49 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 9 Oct 2024 13:25:49 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <QxLgeCEPB2-nU4a4iX8D6-SCg-RZCJdzWa_IJJlcaAg=.88feee12-f9a0-484f-98b2-2d60b8709d5b@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

src/hotspot/share/runtime/arguments.cpp line 523:

> 521: 
> 522:   { "MetaspaceReclaimPolicy",       JDK_Version::undefined(), JDK_Version::jdk(21), JDK_Version::undefined() },
> 523:   { "ZGenerational",                JDK_Version::jdk(23), JDK_Version::jdk(24), JDK_Version::undefined() },

FTR: This line depends on what version the JEP gets targeted to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21401#discussion_r1793510168

From stefank at openjdk.org  Wed Oct  9 13:27:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 9 Oct 2024 13:27:13 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <H2vRaCgFEUjFZxYtRvjgLuGLm1W1VpYOCpOafn2qGHg=.a8e84a0f-b072-4212-a5e2-f659792e1945@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

Looks good to me!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21401#issuecomment-2402271738

From rgiulietti at openjdk.org  Wed Oct  9 14:13:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Oct 2024 14:13:06 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnrwS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
Message-ID: <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>

On Mon, 7 Oct 2024 19:48:20 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> `BigDecimal` was not designed to do astronomical computations. One would probably use other libraries for that, e.g., [GMP](https://gmplib.org/) and would not be interested too much in "stripping trailing zeros".
>> The focus of this class is mainly commercial applications, where decimal arithmetic is sometimes mandated by regulators.
>> 
>> So I'd expect that most usages, for example SQL or commercial application workloads, will process numbers with a few dozens of digits, maybe sometimes some hundreds digits for intermediate results. So I think that accelerating for these sizes makes the most practical sense.
>> 
>> With modest memory and CPU costs, I think even one million digits or so might be processed reasonably fast.
>> My point is that there's room for improvement in these range of sizes, but perhaps not for larger ones.
>> 
>> More importantly, though, I'd like to avoid one single computation to affect the resident memory footprint of a JVM instance for its entire lifetime.
>
> @rgiulietti FYI, I have found that `BigInteger` has already a cache for the repeated squares that uses in radix string conversion, and it is provided by the method `BigInteger.getRadixConversionCache(int radix, int exponent)`. Although, I don't know if it would be a good idea to use it, because it computes all the squares up to `radix^(2^exponent)`, and this may not be necessary but could cost a lot of running time and memory if the number to strip is very large...

Seems like `BigInteger`s division either takes care of removing common powers of 2 in the dividend and divisor (Knuth division), or removing them has no practical benefit (Burnikel-Ziegler).

Thus, I'm wondering if using powers of 10 rather than powers of 5 in the stripping logic could simplify the code while retaining comparable performance.

The powers of 10 are already indirectly kept in the class by method `bigTenToThe()` (although they affect resident memory footprint). However, since that method is there to stay and used in other places as well, it might be worthwhile to profit from it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793603310

From duke at openjdk.org  Wed Oct  9 14:35:00 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 9 Oct 2024 14:35:00 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
Message-ID: <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>

On Wed, 9 Oct 2024 14:10:17 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti FYI, I have found that `BigInteger` has already a cache for the repeated squares that uses in radix string conversion, and it is provided by the method `BigInteger.getRadixConversionCache(int radix, int exponent)`. Although, I don't know if it would be a good idea to use it, because it computes all the squares up to `radix^(2^exponent)`, and this may not be necessary but could cost a lot of running time and memory if the number to strip is very large...
>
> Seems like `BigInteger`s division either takes care of removing common powers of 2 in the dividend and divisor (Knuth division), or removing them has no practical benefit (Burnikel-Ziegler).
> 
> Thus, I'm wondering if using powers of 10 rather than powers of 5 in the stripping logic could simplify the code while retaining comparable performance.
> 
> The powers of 10 are already indirectly kept in the class by method `bigTenToThe()` (although they affect resident memory footprint). However, since that method is there to stay and used in other places as well, it might be worthwhile to profit from it.

@rgiulietti 
- About powers of two, there is a difference here: all powers of two are removed, not only the common, to use numbers as small as possible.
- About `bigTenToThe()`: its shortcoming is that the powers are calculated multiplying by 10 each time, rather than using repeated squares trick, until the cache is completely filled.

These are the main reasons why I decided not to use `bigTenToThe()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793636240

From eosterlund at openjdk.org  Wed Oct  9 14:46:00 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 9 Oct 2024 14:46:00 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <YoFjg-VDCRuEpslSIZE7glzDpNJJWCxlA_c2DaIVgkk=.33c2f427-192d-4b85-8bff-4ed8ac666af4@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2357380323

From rgiulietti at openjdk.org  Wed Oct  9 14:50:05 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Oct 2024 14:50:05 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v32]
In-Reply-To: <3FoydNfCzRhNL5Fts7M-30uB-QwPJyZq-DkWlF4NVtk=.b28f509b-15f5-4f16-aff5-9b91f6506246@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <3FoydNfCzRhNL5Fts7M-30uB-QwPJyZq-DkWlF4NVtk=.b28f509b-15f5-4f16-aff5-9b91f6506246@github.com>
Message-ID: <lrI2lWKr4vPi5U44uEeghu-Dd2Fwp4HIVCh8XsdIW4Y=.b55b2fa6-29fd-44bc-a8f0-5d398a219e29@github.com>

On Mon, 7 Oct 2024 19:35:10 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use log cache of BigInteger

Small changes.

src/java.base/share/classes/java/math/BigInteger.java line 1299:

> 1297: 
> 1298:     /** The cache of logarithms of radices for base conversion. */
> 1299:     static final double[] logCache;

I'd prefer this to remain `private`.

It's not a big deal to have `private static final double LOG_5_OF_2 = Math.log(2) / Math.log(5)` in `BigDecimal`.

src/java.base/share/classes/java/math/BigInteger.java line 1302:

> 1300: 
> 1301:     /** The natural log of 2.  This is used in computing cache indices. */
> 1302:     static final double LOG_TWO = Math.log(2.0);

Same here, please revert to `private`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21323#pullrequestreview-2357388419
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793666210
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793666261

From lancea at openjdk.org  Wed Oct  9 15:03:03 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 9 Oct 2024 15:03:03 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header [v3]
In-Reply-To: <raG3xH3qjZqvc0BUJv_wzRegIvq6Z6fDiXpUyWkR74I=.39544674-6f14-476a-a4a7-9ea57b322673@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
 <raG3xH3qjZqvc0BUJv_wzRegIvq6Z6fDiXpUyWkR74I=.39544674-6f14-476a-a4a7-9ea57b322673@github.com>
Message-ID: <wZKGRUyEgpMkdc_zkqwAgiauH-ZfPdsGuYPbzBdMEI4=.a93fbd96-f5cd-4e74-93bf-5d2dcfb67ac7@github.com>

On Tue, 8 Oct 2024 07:45:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which adds validation of the 'total entries' value when fetched from the 'ZIP64 End of Central Directory' header.
>> 
>> We should reject this value under the following conditions:
>> 
>> 1. It is too large to fit within the specified CEN size (considering each CEN header encodes as at least 46 bytes each)
>> 2. It is too large to create the `int[] entries` array safely (max value is `ArraysSupport.SOFT_MAX_ARRAY_LENGTH / 3`)
>> 
>> I claim that condition 2 here is already implicitly validated by the current maximum CEN size validation. (A CEN encoding such a large number of entries would exceed the maximum CEN size a lot and would already be rejected)
>> 
>> This change aims to protect the integrity of the implementation against specially crafted ZIP files. No sane ZIP tool will produce such files. 
>> 
>> Testing:
>> 
>> This PR adds a test `EndOfCenValidation.shouldRejectBadTotalEntries` which exercises the first condition above.
>> 
>> ZIP tests run locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reject "negative" 'total entries' values
>  - Convert EndOfCenValidation to JUnit 5

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21384#pullrequestreview-2357428844

From lancea at openjdk.org  Wed Oct  9 15:03:05 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 9 Oct 2024 15:03:05 GMT
Subject: RFR: 8341625: Improve ZipFile validation of the END header [v2]
In-Reply-To: <fbFrO59NPRGGWQHDrlTBjX71VP0MwP6MR7H_E-8LERY=.4889dece-ff3b-46cd-a1f0-235fb12be84b@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
 <kZikDHV8049i9eAoalXCWQYNDkQxhMcIdU1AtfaXotY=.aae0098a-7371-432d-85f8-c4c87aaee66c@github.com>
 <fbFrO59NPRGGWQHDrlTBjX71VP0MwP6MR7H_E-8LERY=.4889dece-ff3b-46cd-a1f0-235fb12be84b@github.com>
Message-ID: <7DcKfvBK5-tGha9QpCxF8Ka44awn0wb2StxHWaYYNls=.a1e9ef97-4ee1-474e-a3e9-7ee47dd186f5@github.com>

On Mon, 7 Oct 2024 20:00:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove trailing whitespace
>>  - Use a ZIP64 test vector which may be reproduced using InfoZIP
>
> Marked as reviewed by lancea (Reviewer).

> @LanceAndersen
> 
> I figured it would make sense to also reject "negative" values. These are not actually negative, just values larger than `Long.MAX_VALUE` can represent.
> 
> See the [11a275d](https://github.com/openjdk/jdk/commit/11a275d9cc9e8602ad3d190f1c0ca09ff6c04dcd) for the conversion to JUnit 5 and [0f0801c](https://github.com/openjdk/jdk/commit/0f0801c4cee09e36e772314d4343e8c15e39b1dd) which makes the test parameterized to verify that a bunch of bad entry count values are rejected.

No harm, with the extra validation IMHO

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21384#issuecomment-2402587265

From rsunderbabu at openjdk.org  Wed Oct  9 15:06:11 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 9 Oct 2024 15:06:11 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support
Message-ID: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>

The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".

Positive Testing:
tier1,tier2,tier3 - to check stability
tier5 - to run container tests

Negative Testing:
Ran the following groups in hosts where container is not present.
open/test/hotspot/jtreg/containers/
open/test/jdk/jdk/internal/platform/docker/
open/test/jdk/jdk/internal/platform/cgroup/

-------------

Commit messages:
 - corrected the copyright headers
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/21423/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21423&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341138
  Stats: 54 lines in 26 files changed: 6 ins; 0 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/21423.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21423/head:pull/21423

PR: https://git.openjdk.org/jdk/pull/21423

From duke at openjdk.org  Wed Oct  9 15:18:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 9 Oct 2024 15:18:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Store log5(2) in BigDecimal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/12200d55..5caa5651

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=31-32

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From cjplummer at openjdk.org  Wed Oct  9 15:38:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Oct 2024 15:38:01 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
Message-ID: <kWpzDLtOVJSNNs118tseqdQYE7FdENDFocw0gTXU84s=.a452b2f5-97ca-4d61-aacc-438cb747a719@github.com>

On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust gcc warning settings; bring back rslt

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21407#pullrequestreview-2357520081

From cjplummer at openjdk.org  Wed Oct  9 15:38:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Oct 2024 15:38:03 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <hTF-irWGYZkkbPeiwSvWNBp6N_UiGJdWRlwJ5UXBoQA=.a6ab4ebc-26d2-4c39-924e-00643f031756@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
 <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>
 <0phEjRhdkzoktdn5f-VmwNddCFABbKUw0XKgLENxsII=.44778b32-2039-4b52-9b97-40b5ee690675@github.com>
 <hTF-irWGYZkkbPeiwSvWNBp6N_UiGJdWRlwJ5UXBoQA=.a6ab4ebc-26d2-4c39-924e-00643f031756@github.com>
Message-ID: <z5f8EoUCOIWMfKH-bnR1qGPOcSMI8uCpNDPU84r9guI=.f50660b7-063a-432e-b88e-d4d16c5c4b61@github.com>

On Wed, 9 Oct 2024 10:36:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Might be a good idea to have rslt commented out rather than removed outright if we don't want to forget about it. guarantee on a variable that doesn't exist will be rather confusing to anyone reading through the code
>
>> Might be a good idea to have rslt commented out 
> 
> Why not; Chris what do you say ?

Yeah, I think it is good like this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1793746144

From aph at openjdk.org  Wed Oct  9 15:49:16 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 15:49:16 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <_VdTzvXOhImLlu7ZA9PRxqK3TSrKYWAyQGXWr-XYsO0=.d8f8f09f-b655-4514-a536-1066a0dddc68@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
 <_VdTzvXOhImLlu7ZA9PRxqK3TSrKYWAyQGXWr-XYsO0=.d8f8f09f-b655-4514-a536-1066a0dddc68@github.com>
Message-ID: <lAos3zp20SvqluCYMxKQF_YBZhu-UvK_DiBn1sRlhqc=.3da3dec3-d3f7-4f62-bd82-26520006ccac@github.com>

On Wed, 9 Oct 2024 09:00:06 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.
>
> On 10/9/24 06:53, John Rose wrote:
> 
>  > It looks like the compression needs to be partial, down to about 32 bits.
> 
> Yes, that's true. Slightly fewer bits would be nice, for tags.
> 
>  > So it looks like (a) having ALL klass IDs fit in 32 bits, and (b)
>  > having all CONCRETE klass IDs fit into a smaller part of the same
>  > range, would meet all requirements. Doing it right might require TWO
>  > new companion types for Klass*, a compact concrete klass ID, and a
>  > 32-bit klass ID (supertype to compact concrete klass ID). I think
>  > the larger one could be called narrowKlass (current name), and maybe
>  > the narrower concrete ID could be called narrowConcreteKlass or
>  > narrowestKlass or something like that.
> 
> I see, I think.
> 
> Simply keeping all of metadata in a single 32-bit range would be very
> useful. We could have instantiable Klasses in one region, followed by
> non-instantiable Klasses.
> 
>  > (Because of CDS, and maybe other factors, some compact concrete
>  > klass IDs will actually point to interfaces or abstract classes. So
>  > narrowConcreteKlass suggests a property of its referents that isn?t
>  > exactly true.)
> 
>  > The way I read this is to think about putting, not klass and
>  > non-klass, but concrete-klass and non-concrete-klass IDs in the same
>  > range. (By ID I mean a compressed Klass pointer, or alternatively an
>  > index into some sort of special table that we haven?t needed to
>  > invent.)
> 
> While I've now thought of a way to encode Klass pointers that doesn't
> need them all to be in the same 32-bit range, it may well be very
> useful in other contexts to ensure that they will be.
> 
> Maybe we could reduce the footprint of Klass instances. Right now,
> though, my invokeinterface prototypes *increase* the size of Klass
> instances, so I really want to have the possibility of using
> compressed metadata pointers.
> 
> For what it's worth, I'm relieved that we're not yet making Klass
> pointers a table index. Another chained load in the path of method
> dispatch, at a time when I'm trying to get rid of chained loads, would
> be a Bad Thing for me.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

> @theRealAph I do not know your idea regarding this matter but does compressing interface pointers independently from concrete class pointers help?

Of course that is possible, but it add complexity; and my goal is reducing complexity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402696292

From rgiulietti at openjdk.org  Wed Oct  9 15:49:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Oct 2024 15:49:06 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
Message-ID: <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>

On Wed, 9 Oct 2024 14:28:53 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Seems like `BigInteger`s division either takes care of removing common powers of 2 in the dividend and divisor (Knuth division), or removing them has no practical benefit (Burnikel-Ziegler).
>> 
>> Thus, I'm wondering if using powers of 10 rather than powers of 5 in the stripping logic could simplify the code while retaining comparable performance.
>> 
>> The powers of 10 are already indirectly kept in the class by method `bigTenToThe()` (although they affect resident memory footprint). However, since that method is there to stay and used in other places as well, it might be worthwhile to profit from it.
>
> @rgiulietti 
> - About powers of two, there is a difference here: all powers of two are removed, not only the common, to use numbers as small as possible, and the powers are removed all in once, while if not they were removed at each division and also in the divisor, which is a power of 10, slowing the time of every iteration.
> - About `bigTenToThe()`: its shortcoming is that the powers are calculated multiplying by 10 each time, rather than using repeated squares trick, until the cache is completely filled.
> 
> These are the main reasons why I decided not to use `bigTenToThe()`.

Oh right, `expandBigIntegerTenPowers()` indeed computes and stores a lot of values.

I'm thinking of opening an issue to rewrite it to just keep the values that are actually computed as intermediate results of a repeated squaring implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793763450

From duke at openjdk.org  Wed Oct  9 15:50:09 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 9 Oct 2024 15:50:09 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v6]
In-Reply-To: <7Di2YTFOv-Q0OzRYMgHEfjP-K0LXYJnvTE7KZ0zFJ-g=.9afcf33b-9e18-4822-ae5e-6c91cb338ce4@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <7Di2YTFOv-Q0OzRYMgHEfjP-K0LXYJnvTE7KZ0zFJ-g=.9afcf33b-9e18-4822-ae5e-6c91cb338ce4@github.com>
Message-ID: <gqpqqpXUmIW1z-fgvRe7yQ8xgDMsBKeyKyhLIwmFF3A=.bdef84c2-3f1b-4af8-8d3d-42ad575e8ced@github.com>

On Wed, 25 Sep 2024 12:58:20 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:
> 
>   Address review feedback

Could anyone provide a second review? I'm hoping to get this finished before rampdown for 24, which is about 8 weeks away now, and there are still a few steps to go yet.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2402700212

From eirbjo at openjdk.org  Wed Oct  9 15:59:16 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 9 Oct 2024 15:59:16 GMT
Subject: Integrated: 8341625: Improve ZipFile validation of the END header
In-Reply-To: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
References: <cFwVMR9b7bdjSSTqe_m4SVoyHA_PBoc43e90lMQdXL8=.1ed13ada-6fe6-4334-afa2-b18191ba9b07@github.com>
Message-ID: <aFQJfGS6jv98M32j_wMEwO1DBtr_yChzhBzouIfTEB4=.0f7b750b-e213-4cb3-8b8f-51558cc344db@github.com>

On Mon, 7 Oct 2024 09:13:57 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which adds validation of the 'total entries' value when fetched from the 'ZIP64 End of Central Directory' header.
> 
> We should reject this value under the following conditions:
> 
> 1. It is too large to fit within the specified CEN size (considering each CEN header encodes as at least 46 bytes each)
> 2. It is too large to create the `int[] entries` array safely (max value is `ArraysSupport.SOFT_MAX_ARRAY_LENGTH / 3`)
> 
> I claim that condition 2 here is already implicitly validated by the current maximum CEN size validation. (A CEN encoding such a large number of entries would exceed the maximum CEN size a lot and would already be rejected)
> 
> This change aims to protect the integrity of the implementation against specially crafted ZIP files. No sane ZIP tool will produce such files. 
> 
> Testing:
> 
> This PR adds a test `EndOfCenValidation.shouldRejectBadTotalEntries` which exercises the first condition above.
> 
> ZIP tests run locally. GHA results pending.

This pull request has now been integrated.

Changeset: 950e3a75
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/950e3a7587ed3269aab0c3b6625b9cc9149d34d8
Stats:     152 lines in 2 files changed: 135 ins; 0 del; 17 mod

8341625: Improve ZipFile validation of the END header

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/21384

From duke at openjdk.org  Wed Oct  9 16:06:09 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 9 Oct 2024 16:06:09 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
Message-ID: <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>

On Wed, 9 Oct 2024 15:46:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti 
>> - About powers of two, there is a difference here: all powers of two are removed, not only the common, to use numbers as small as possible, and the powers are removed all in once, while if not they were removed at each division and also in the divisor, which is a power of 10, slowing the time of every iteration.
>> - About `bigTenToThe()`: its shortcoming is that the powers are calculated multiplying by 10 each time, rather than using repeated squares trick, until the cache is completely filled.
>> 
>> These are the main reasons why I decided not to use `bigTenToThe()`.
>
> Oh right, `expandBigIntegerTenPowers()` indeed computes and stores a lot of values.
> 
> I'm thinking of opening an issue to rewrite it to just keep the values that are actually computed as intermediate results of a repeated squaring implementation.

@rgiulietti BTW of opening new issues, I've found that there are some optimizations and code simplifications that can be done in `BigInteger`'s bit operations that uses lowest non-zero word search, like `shiftRight()`, `getLowestSetBit()`, `bitLength()` and `bitCount()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793787866

From aph at openjdk.org  Wed Oct  9 16:10:11 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 16:10:11 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <AOROIqOqf-5g2WScT9sCslfWmvwYLKRLS7UFMnVpI5E=.0feba64a-0a5f-49cf-bd13-fdb094bf295c@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
 <AOROIqOqf-5g2WScT9sCslfWmvwYLKRLS7UFMnVpI5E=.0feba64a-0a5f-49cf-bd13-fdb094bf295c@github.com>
Message-ID: <j9uvo6mWz-7FcaaT1PD57iqUthx2SPo_94lg9kURbJ0=.7f9d6937-9af7-4a94-9809-6ae1eecb1472@github.com>

On Wed, 9 Oct 2024 06:07:13 GMT, John R Rose <jrose at openjdk.org> wrote:

> If the interfaces had a compact numbering, and there were a side table mapping the compact numbers to interface Klass* pointers, then I think Andrew's code would still work (with natural adjustments).

Probably, yes. I can pack klass ID+ [iv]table offset into a word to identify a method, or use a compressed metadata pointer. But I have a data dependency on a table load to get from a compressed Klass ID of some sort to a `Klass*`, that's a 3-to-5-cycle stall.

> But managing such a side table is at least as complicated as just doing the pointer compression stuff we do. (Hence my comment that we haven't had to invent side tables yet.)
> 
> Because of CDS I don't think we can treat concretes and abstracts (or even just classes and interfaces) as disjoint metadata types with separate independent compression tactics or representations. I think we need a subtype/supertype relation between the "narrowest" and merely "narrower" klass IDs.

I think that's right.

Notwithstanding any side tables etc., it would be nice to make sure that all metadata is reachable with a 4Gbyte offset from some base. It's not so hard to make sure that concrete and abstract `Klass*` (and all `Method*`s) can be in that range, simply(?) by allocating everything contiguously.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402742912

From jrose at openjdk.org  Wed Oct  9 16:17:12 2024
From: jrose at openjdk.org (John R Rose)
Date: Wed, 9 Oct 2024 16:17:12 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <j9uvo6mWz-7FcaaT1PD57iqUthx2SPo_94lg9kURbJ0=.7f9d6937-9af7-4a94-9809-6ae1eecb1472@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
 <AOROIqOqf-5g2WScT9sCslfWmvwYLKRLS7UFMnVpI5E=.0feba64a-0a5f-49cf-bd13-fdb094bf295c@github.com>
 <j9uvo6mWz-7FcaaT1PD57iqUthx2SPo_94lg9kURbJ0=.7f9d6937-9af7-4a94-9809-6ae1eecb1472@github.com>
Message-ID: <G4vSyXihlBRXEpQZCXgzbm7O9yRnGNtTrzBtHe2TBSA=.0894e8ef-1ee5-4ba8-93f0-bbff82a14aa6@github.com>

On Wed, 9 Oct 2024 16:07:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

> simply(?) by allocating everything contiguously

Suddenly I seem to hear Boromir and Yoda, in unison, saying, "One does not simply."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402756530

From aph at openjdk.org  Wed Oct  9 16:17:12 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 9 Oct 2024 16:17:12 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
 <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
 <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>
 <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>
 <xmv6JmVMj_OMC0gljTpGL6vkYt5sa1OwIGilqAzJFuc=.96bb3df3-98ae-4a68-972c-571c8126af98@github.com>
Message-ID: <b4yptr1YEYxD1xi5VOg5aDumkt0sqf9W7ZHQbmnSzXs=.300548ab-d396-42ef-8a3d-2211e0eb2a4a@github.com>

On Tue, 3 Sep 2024 15:50:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> > I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
>>> 
>>> MethodData does a lot of deallocations from metaspace because it's allocated racily. It might be using Metaspace wrong.
>> 
>> I think that should be okay. This should still be an exception. I have never seen that many deallocations happening in customer cases.
>
>> @tstuefe Do you have more comments on this PR?
> 
> Sorry, I was swamped the past days. I'll take a look tomorrow.

> AFAIK, @tstuefe (currently on vacation) has a working prototype of a Klass-lookup-table with good performance and reasonable ?management cost?. This would make make many things much simpler and also help solve this problem because it makes irrelevant where a Klass lives.

Yeah, I get that, and I'm sure @tstuefe has done a great job. But it goes to the fundamental theorem of software engineering (FTSE), Wheeler's statement that "We can solve any problem by introducing an extra level of indirection," often followed by "?except for the problem of too many levels of indirection."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402757801

From rgiulietti at openjdk.org  Wed Oct  9 16:23:03 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Oct 2024 16:23:03 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
 <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
Message-ID: <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>

On Wed, 9 Oct 2024 16:03:05 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Oh right, `expandBigIntegerTenPowers()` indeed computes and stores a lot of values.
>> 
>> I'm thinking of opening an issue to rewrite it to just keep the values that are actually computed as intermediate results of a repeated squaring implementation.
>
> @rgiulietti BTW of opening new issues, I've found that there are some optimizations and code simplifications that can be done in `BigInteger`'s bit operations that uses lowest non-zero word search, like `shiftRight()`, `getLowestSetBit()`, `bitLength()` and `bitCount()`.

If you are interested, you can create new PRs without reference to JBS issues, and I'll file them.
As usual, it's easier for review purposes when each PR touches only small groups of strongly related changes rather than big modifications en-bloc.

But you should show JMH benchmark evidence in later comments (not the introductory comment) that there are no performance regressions, in addition to code simplification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793809261

From jrose at openjdk.org  Wed Oct  9 16:26:10 2024
From: jrose at openjdk.org (John R Rose)
Date: Wed, 9 Oct 2024 16:26:10 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v6]
In-Reply-To: <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <6SbHbHK4n6vHaDLeC-X1oFBcoGE1osgeSXV7gq36xP8=.6f7e9fc4-ff7d-412f-9e14-5650dfa6f5d9@github.com>
Message-ID: <5tNL3Oxj8lsWwS08KfTBJMK-6r4CyX9j7m3r4UIOWCA=.abe50fe3-21c4-4624-a7cc-a30d6d16296b@github.com>

On Fri, 6 Sep 2024 16:20:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace Metaspace::is_compressed_klass_ptr with CompressedKlassPointers::is_in_encoding_range.

Sometimes, if you are very clever and determined, you can do the very non-simple thing of putting some items at the least level of indirection, and other items at further levels of indirection.  You'd try to put stuff you need frequently closer to the root address.

Currently everything is equally close to the root address, except that IIRC we try to put a few really performance sensitive things on the earliest cache lines.

Splitting one Klass structure into a near and a far part is doable in principle, but the complexity adds up quickly, and there is also a problem deciding what to put in the near part.

Specifically, you probably want some v-table entries, but not all v-table entries, in the near part.  (Why not all?  Because near space is relatively scarce.  The near part might even be fixed in size, depending on design.)

The bottom line for me:  I like flatter data and shorter indirection chains.  The main exception is that I ALSO like to separate hot from cold data, when the opportunity arises, and cold data is often at the end of an unused indirection.

(I think there is relatively little cold data in metaspace, and it is probably already packed inside a pointer to an Array.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2402774234

From liach at openjdk.org  Wed Oct  9 16:43:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 16:43:07 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
Message-ID: <YEPyHcUY0jHKTwBytKbpKrFnTbfiPbRN5h0HLR8vRog=.6eeaf01d-2d41-4e49-a610-ca384ed4fa70@github.com>

On Wed, 9 Oct 2024 11:49:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - assertThrows instead of expectedExceptions
>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER

I have looked at the CSR and revised the wording for you, mostly conveying information CSR review wants to see.

The original "Problem" section only mentions performance, but I added consistency with specification and problems with third-party/custom implementations, as those are indeed problems that we are fixing with this new API. Also simplified "Solution" section to emphasize on our new API. The inlined links have been standardized to links in the "Issue Links" section.

@mkarg Can you take a look at this revised version of CSR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2402809835

From liach at openjdk.org  Wed Oct  9 17:03:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 17:03:59 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate [v4]
In-Reply-To: <xRdJYn2wpcpaPceGf_PoQzJH7-JQnCrwtdlF9egaoBg=.5f0fa775-c45b-4efa-93e2-baf30f46e8ad@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
 <xRdJYn2wpcpaPceGf_PoQzJH7-JQnCrwtdlF9egaoBg=.5f0fa775-c45b-4efa-93e2-baf30f46e8ad@github.com>
Message-ID: <GjPez-XQ-htF9CmvMoZ62Iw3q2X6TwyIyXLDoppKeGY=.5d1f2f0a-005e-41de-83f8-222c028293cc@github.com>

On Fri, 4 Oct 2024 16:53:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

We can optimize non-ascii reading here and in DataInputStream together later.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20767#pullrequestreview-2357720331

From liach at openjdk.org  Wed Oct  9 17:24:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 17:24:11 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v4]
In-Reply-To: <p7zNX3w-EmhHoA_-y0tkaPUWif1iMB_-bJy_u_g6zbo=.1ccfa774-261b-4bc8-8fe5-19919366015f@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
 <p7zNX3w-EmhHoA_-y0tkaPUWif1iMB_-bJy_u_g6zbo=.1ccfa774-261b-4bc8-8fe5-19919366015f@github.com>
Message-ID: <WvumBU0AvHsQzLEcNKQTmk4TKIEdMhTSmU-Tmd2_AbY=.624173f2-1de6-4c15-b335-534b2065e87e@github.com>

On Sat, 5 Oct 2024 15:42:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Reduce code size by combining calls and defining local variables
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'master' into optim_stack_map_gen_202408
>  - Merge branch 'master' into optim_stack_map_gen_202408
>  - reduce codeSize
>  - reduce codeSize
>  - decStack & stackUnderflow
>  - fix merge error
>  - Merge branch 'master' into optim_stack_map_gen_202408
>  - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>  - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>  - fix merge error
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/1c3e56c3...59102d50

Changes requested by liach (Reviewer).

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 555:

> 553:                  currentFrame.dup2_x1();
> 554:             case DUP2_X2 ->
> 555:                  currentFrame.dup2_x2();

These few lines of code have 5-space indent; use 4 spaces.

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1031:

> 1029:             int stackSize = this.stackSize;
> 1030:             if (stackSize < 4) throw stackUnderflow();
> 1031:             checkStack(stackSize + 4);

Suggestion:

            checkStack(stackSize + 2);

-------------

PR Review: https://git.openjdk.org/jdk/pull/20756#pullrequestreview-2357745336
PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1793886571
PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1793881046

From swen at openjdk.org  Wed Oct  9 17:25:08 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 17:25:08 GMT
Subject: Integrated: 8339320: Optimize ClassFile Utf8EntryImpl#inflate
In-Reply-To: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
Message-ID: <ggJtPa9wQrQUHiSBp4rMDtY8ufkRVZckrncfsyX8qmo=.a659c2f8-52ee-4693-9e1d-87f218088728@github.com>

On Thu, 29 Aug 2024 11:44:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR

This pull request has now been integrated.

Changeset: a24525b6
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a24525b67b97d38a33e42871bd2e8d03cd327568
Stats:     75 lines in 1 file changed: 22 ins; 19 del; 34 mod

8339320: Optimize ClassFile Utf8EntryImpl#inflate

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20767

From aefimov at openjdk.org  Wed Oct  9 17:26:14 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 9 Oct 2024 17:26:14 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v11]
In-Reply-To: <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
Message-ID: <C4xWWsL9aQuDnSXmTzzAKi_UwjIS0pV94jpbNXIxq0I=.f816a7e2-3892-45ce-9761-2b5cc1461f94@github.com>

On Mon, 7 Oct 2024 09:00:28 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov 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 16 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into JDK-8339538_DnsClient_nanoTime_And_InfiniteLoop
>  - improve reporting for unrecoverable exceptions
>  - Add comment suggested by Daniel
>  - Track unfulfilled timeouts during UDP queries.
>    Update exceptions handling.
>    Update TCP client to use nano time source.
>  - set min timeout to 0; set max allowed timeout to 2x expected timeout in tests
>  -  set max allowed value for retries to 30
>  - update tests to calculate allowed timeout range (max is updated to 75%), print it and use it for elapsed time check
>  - remove redundant clamp from timeoutLeft calculation
>  - clamp timeout and retries property values
>  - Measure time the caller spent waiting. Simplify timeoutLeft computation
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/3251a5e8...c58e34cc

The changes in this PR are expected to help with intermittent failures of the `com/sun/jndi/dns/ConfigTests/Timeout.java` test. 
Therefore, I'm marking  [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as solved by this PR too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20892#issuecomment-2402889782

From swen at openjdk.org  Wed Oct  9 17:27:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 17:27:38 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v5]
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <5LJ98Zpiiw3LX_FMFyWXp8TTpkb0XMzldTqnrVJFvgs=.57c0f626-543f-4741-aaf4-86a0cbfe5d50@github.com>

> Reduce code size by combining calls and defining local variables

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20756/files
  - new: https://git.openjdk.org/jdk/pull/20756/files/59102d50..eca48ba0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20756/head:pull/20756

PR: https://git.openjdk.org/jdk/pull/20756

From duke at openjdk.org  Wed Oct  9 17:28:09 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 9 Oct 2024 17:28:09 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
 <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
 <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>
Message-ID: <Ugb5Xc_P_l6LM3T41jyyP2nvSNKgJvtviEGolapXdj0=.79e11c44-072f-4b27-a126-b30b516a0efd@github.com>

On Wed, 9 Oct 2024 16:17:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti BTW of opening new issues, I've found that there are some optimizations and code simplifications that can be done in `BigInteger`'s bit operations that uses lowest non-zero word search, like `shiftRight()`, `getLowestSetBit()`, `bitLength()` and `bitCount()`.
>
> If you are interested, you can create new PRs without reference to JBS issues, and I'll file them.
> As usual, it's easier for review purposes when each PR touches only small groups of strongly related changes rather than big modifications en-bloc.
> 
> But you should show JMH benchmark evidence in later comments (not the introductory comment) that there are no performance regressions, in addition to code simplification.

@rgiulietti I think I just found a problem much more serious than a simple optimization, I'm afraid the semantics of `BigInteger.bitCount()` is ill-defined, although it seems absurd to me that no one has noticed it so far...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1793898050

From jlu at openjdk.org  Wed Oct  9 17:34:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Oct 2024 17:34:18 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
Message-ID: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>

Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.

This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21428/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21428&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341789
  Stats: 34 lines in 10 files changed: 0 ins; 0 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/21428.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21428/head:pull/21428

PR: https://git.openjdk.org/jdk/pull/21428

From jlu at openjdk.org  Wed Oct  9 17:34:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Oct 2024 17:34:26 GMT
Subject: RFR: 8341791: Fix ExceptionOccurred in java.prefs
Message-ID: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>

Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.prefs_.

This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21427/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21427&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341791
  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21427.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21427/head:pull/21427

PR: https://git.openjdk.org/jdk/pull/21427

From swen at openjdk.org  Wed Oct  9 17:37:14 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 17:37:14 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v6]
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <QRXe3aHVBl9NWpsyWw4EqvukjBmmSKcO04cvJHsz0oQ=.716f3d35-8cbd-4634-b540-256210b647cf@github.com>

> Reduce code size by combining calls and defining local variables

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use 4 spaces.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20756/files
  - new: https://git.openjdk.org/jdk/pull/20756/files/eca48ba0..c03758ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=04-05

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20756/head:pull/20756

PR: https://git.openjdk.org/jdk/pull/20756

From swen at openjdk.org  Wed Oct  9 17:40:13 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 17:40:13 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v7]
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <PjWMbMEk79EurV8Vzd93s4-zhttCu-KcGhilsv2zG5k=.c9861291-ed1a-4d9b-96e1-128db346e3e5@github.com>

> Reduce code size by combining calls and defining local variables

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
 - use 4 spaces.
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
   
   Co-authored-by: Chen Liang <liach at openjdk.org>
 - Merge branch 'master' into optim_stack_map_gen_202408
 - Merge branch 'master' into optim_stack_map_gen_202408
 - reduce codeSize
 - reduce codeSize
 - decStack & stackUnderflow
 - fix merge error
 - Merge branch 'master' into optim_stack_map_gen_202408
 - ... and 8 more: https://git.openjdk.org/jdk/compare/3ab519f1...248f7474

-------------

Changes: https://git.openjdk.org/jdk/pull/20756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=06
  Stats: 342 lines in 1 file changed: 217 ins; 33 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/20756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20756/head:pull/20756

PR: https://git.openjdk.org/jdk/pull/20756

From swen at openjdk.org  Wed Oct  9 17:40:24 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 17:40:24 GMT
Subject: RFR: 8341859: Optimize ClassFile Benchmark Write
Message-ID: <oQ_Kzd87EIICz5jKbJ5jrnmecVHzyvJ-SAlBe4cxZYA=.af49d1fb-181a-4c98-9546-9a0382a602e2@github.com>

Cache method names to reduce the overhead of using StringBuilder to construct method names, which will make the performance test results more stable.

-------------

Commit messages:
 - cache methodName

Changes: https://git.openjdk.org/jdk/pull/21425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341859
  Stats: 13 lines in 1 file changed: 9 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21425/head:pull/21425

PR: https://git.openjdk.org/jdk/pull/21425

From liach at openjdk.org  Wed Oct  9 17:40:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 17:40:24 GMT
Subject: RFR: 8341859: Optimize ClassFile Benchmark Write
In-Reply-To: <oQ_Kzd87EIICz5jKbJ5jrnmecVHzyvJ-SAlBe4cxZYA=.af49d1fb-181a-4c98-9546-9a0382a602e2@github.com>
References: <oQ_Kzd87EIICz5jKbJ5jrnmecVHzyvJ-SAlBe4cxZYA=.af49d1fb-181a-4c98-9546-9a0382a602e2@github.com>
Message-ID: <FXD3jIRVQOCR7WA5wGL49qzV-qP7rZPtbm4TjwYvGwE=.1a208e60-5d06-46b8-8358-8fe14a2eb699@github.com>

On Wed, 9 Oct 2024 17:17:36 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Cache method names to reduce the overhead of using StringBuilder to construct method names, which will make the performance test results more stable.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21425#pullrequestreview-2357764968

From naoto at openjdk.org  Wed Oct  9 17:43:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 9 Oct 2024 17:43:07 GMT
Subject: RFR: 8341684: Typo in External Specifications link of
 java.util.Currency [v2]
In-Reply-To: <5AJODTHIiCtv26Vq-gWk8VNLyz4eQ7he0zWGPmMEnhU=.a4efb69b-5399-4524-8433-75c7386b7921@github.com>
References: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
 <5AJODTHIiCtv26Vq-gWk8VNLyz4eQ7he0zWGPmMEnhU=.a4efb69b-5399-4524-8433-75c7386b7921@github.com>
Message-ID: <nGqSvA5GPtWKu0u65-QQ5yoeNIVWJa3dav5nWsrSqQw=.a0c931fd-3b96-463d-a61b-92710c3d2b38@github.com>

On Wed, 9 Oct 2024 00:08:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> A trivial correction to the  _j.util.Currency_ external specification ISO currency codes link. Browsers will auto resolve and correct the link, but it should still be fixed regardless.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct link

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21416#pullrequestreview-2357797943

From srl at openjdk.org  Wed Oct  9 17:48:00 2024
From: srl at openjdk.org (Steven Loomis)
Date: Wed, 9 Oct 2024 17:48:00 GMT
Subject: RFR: 8341684: Typo in External Specifications link of
 java.util.Currency [v2]
In-Reply-To: <5AJODTHIiCtv26Vq-gWk8VNLyz4eQ7he0zWGPmMEnhU=.a4efb69b-5399-4524-8433-75c7386b7921@github.com>
References: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
 <5AJODTHIiCtv26Vq-gWk8VNLyz4eQ7he0zWGPmMEnhU=.a4efb69b-5399-4524-8433-75c7386b7921@github.com>
Message-ID: <mxM7rSzy-3Rxa4bMXxphJTeunA3uuFqWFFI3UFARst0=.ee6aa371-e48b-4487-a4ae-f772d71a9788@github.com>

On Wed, 9 Oct 2024 00:08:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> A trivial correction to the  _j.util.Currency_ external specification ISO currency codes link. Browsers will auto resolve and correct the link, but it should still be fixed regardless.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct link

Marked as reviewed by srl (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21416#pullrequestreview-2357806205

From duke at openjdk.org  Wed Oct  9 18:00:05 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 18:00:05 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
Message-ID: <-qITPXdGaxQGt_W9pyZdTWKYu6hNo2X1mR23dDzUOKg=.9d93a01c-e302-4334-a551-ad9e7d3e5e2c@github.com>

On Wed, 9 Oct 2024 11:49:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - assertThrows instead of expectedExceptions
>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER

> I have looked at the CSR and revised the wording for you, mostly conveying information CSR review wants to see.
> @mkarg Can you take a look at this revised version of CSR?

Thank you, Chen. I have no experience with CSR, so I do trust in yours. Having said that, I now have upgraded the status from "Draft" to "Finalized". Ist that enough to trigger the review process, or do I have to set an assignee / manually trigger somebody?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2402946651

From liach at openjdk.org  Wed Oct  9 18:09:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 18:09:03 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
Message-ID: <ZN3g8VnTD_WeXq1wSXxHg9kLGqOjKJ52tC39jxyoRRM=.12cc20e1-b64c-47b3-9eb3-ccea098b924e@github.com>

On Wed, 9 Oct 2024 11:49:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - assertThrows instead of expectedExceptions
>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER

Wiki pages such as https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request are good starting points for CSRs.

CSR review will look at CSRs listed at https://bugs.openjdk.org/secure/Dashboard.jspa?selectPageId=17313. To finalize a CSR for review, you should set your fix version; I fixed that when I marked myself as a reviewer on the CSR.

Also note that the CSR lead might be unavailable the next few days, so the review will wait for a bit. Meanwhile, it's good for other experienced reviewers like Alan to review the CSR too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2402963472

From prr at openjdk.org  Wed Oct  9 18:27:02 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 9 Oct 2024 18:27:02 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <pOGPEw3oV9Qyt57fCI4B9Fj-3RAtUCKWvgZPf_c3uog=.1bcf7dfc-7792-428c-b2eb-64ff52db2c7f@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

the 2D/AWT test changes are fine. I've not looked at anything else.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2357882378

From rriggs at openjdk.org  Wed Oct  9 18:33:04 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Oct 2024 18:33:04 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v6]
In-Reply-To: <gqpqqpXUmIW1z-fgvRe7yQ8xgDMsBKeyKyhLIwmFF3A=.bdef84c2-3f1b-4af8-8d3d-42ad575e8ced@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <7Di2YTFOv-Q0OzRYMgHEfjP-K0LXYJnvTE7KZ0zFJ-g=.9afcf33b-9e18-4822-ae5e-6c91cb338ce4@github.com>
 <gqpqqpXUmIW1z-fgvRe7yQ8xgDMsBKeyKyhLIwmFF3A=.bdef84c2-3f1b-4af8-8d3d-42ad575e8ced@github.com>
Message-ID: <zfZ5uKbakMMDdq6EdYChgBjHw_7HEnU_o3m6cRaKlQE=.564551af-086c-4948-b7b6-1c9c55db42ad@github.com>

On Wed, 9 Oct 2024 15:47:22 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review feedback
>
> Could anyone provide a second review? I'm hoping to get this finished before rampdown for 24, which is about 8 weeks away now, and there are still a few steps to go yet.
> 
> Thanks!

@dmlloyd Please update the CSR to match the PR and mark it proposed to get the review started.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2403007269

From mchung at openjdk.org  Wed Oct  9 18:36:59 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 9 Oct 2024 18:36:59 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v5]
In-Reply-To: <RVqTDqexv9ICI2fzagkynzzJBJkVpEZ5NlrpUk5070k=.2aebc7a0-e88d-4205-84c9-71ba37c6f913@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <RVqTDqexv9ICI2fzagkynzzJBJkVpEZ5NlrpUk5070k=.2aebc7a0-e88d-4205-84c9-71ba37c6f913@github.com>
Message-ID: <Ro0qYD834bMPGdV3b20XLTQBjXpUSea2V5N9OZUN_OU=.d3290e76-abd0-48e0-bd30-2df766e70620@github.com>

On Wed, 9 Oct 2024 07:00:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mandy's review suggestion for man page

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21380#pullrequestreview-2357899907

From rriggs at openjdk.org  Wed Oct  9 19:18:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Oct 2024 19:18:26 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
Message-ID: <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>

On Wed, 9 Oct 2024 11:49:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - assertThrows instead of expectedExceptions
>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER

Looks pretty good; some suggestions about clarity of the javadoc.
Claims are made about performance but are minimal and unsubstantiated with JMH tests.
Some updates to the CSR will be needed after updating the javadoc.

src/java.base/share/classes/java/io/Reader.java line 145:

> 143:     /**
> 144:      * Returns a {@code Reader} that reads characters from a
> 145:      * {@code CharSequence}, starting at the first character in the sequence.

The first line comment should be brief and avoid unnecessary details. It is used in method summaries and should stand alone.
The phrase ", starting at the first character in the sequence" should be moved to a separate sentence.

src/java.base/share/classes/java/io/Reader.java line 161:

> 159:      * {@code transferTo()} methods all throw {@code IOException}.
> 160:      *
> 161:      * <p> The returned reader supports the {@link #mark mark()} operation.

It may be useful to mention and link to the #reset method as well.

src/java.base/share/classes/java/io/Reader.java line 168:

> 166:      *
> 167:      * @throws NullPointerException if {@code cs} is {@code null}
> 168:      *

Drop the extra empty lines, to be more consistent with Reader code style and make the source more compact.

src/java.base/share/classes/java/io/Reader.java line 202:

> 200:                 if (next >= cs.length())
> 201:                     return -1;
> 202:                 int n = Math.min(cs.length() - next, len);

Is there any sensitivity to cs.length() changing between these calls? (For an arbitrary custom implementation).
The spec for undefined behavior covers that but might be safer to compute a local length.

src/java.base/share/classes/java/io/StringReader.java line 38:

> 36:  * {@code Reader.of(String)} should generally be used in preference to this one,
> 37:  * as it supports all of the same operations but it is faster, as it performs no
> 38:  * synchronization.

Consider how this API note will age gracefully in a few releases.
I'd lead with the link to the new method and mention it is unsynchronized/single-thread safe.
The comments about performance and "better" belong in the release note.
Uncontested locks will be barely noticeable from a performance perspective.

test/jdk/java/io/Reader/Of.java line 40:

> 38:  * @bug 8341566
> 39:  * @summary Check for expected behavior of Reader.of().
> 40:  * @run testng Of

The test name should be more descriptive.  Without the package name it is unknown what this test does or what it tests.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2357911836
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793987936
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1793997115
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794003619
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794026096
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794048328
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794058509

From rriggs at openjdk.org  Wed Oct  9 19:18:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Oct 2024 19:18:26 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
Message-ID: <MYVO_RBjjb-pWQtM8-rSOu6kwSkSc8isaVE5-PSiVis=.a4ea6d1f-4144-497f-8cb0-7a726fb6469e@github.com>

On Wed, 9 Oct 2024 18:37:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - assertThrows instead of expectedExceptions
>>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> src/java.base/share/classes/java/io/Reader.java line 145:
> 
>> 143:     /**
>> 144:      * Returns a {@code Reader} that reads characters from a
>> 145:      * {@code CharSequence}, starting at the first character in the sequence.
> 
> The first line comment should be brief and avoid unnecessary details. It is used in method summaries and should stand alone.
> The phrase ", starting at the first character in the sequence" should be moved to a separate sentence.

I see Alan and I have different views on the inclusion of the details.
With only a single CharSequence argument, I can't see any ambiguity about the starting position.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794090678

From liach at openjdk.org  Wed Oct  9 19:18:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 19:18:27 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
Message-ID: <GnP8HzGl4mrD7ElrsjTssc3ewI-r68aptWm0b8Txi08=.67c9d101-e6c2-4997-a0ac-2fc0d4e8c37f@github.com>

On Wed, 9 Oct 2024 18:56:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - assertThrows instead of expectedExceptions
>>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> src/java.base/share/classes/java/io/StringReader.java line 38:
> 
>> 36:  * {@code Reader.of(String)} should generally be used in preference to this one,
>> 37:  * as it supports all of the same operations but it is faster, as it performs no
>> 38:  * synchronization.
> 
> Consider how this API note will age gracefully in a few releases.
> I'd lead with the link to the new method and mention it is unsynchronized/single-thread safe.
> The comments about performance and "better" belong in the release note.
> Uncontested locks will be barely noticeable from a performance perspective.

Currently uncontested locks have a performance regression after the removal of biased locking: A similar example with `StringBuffer` is available in #19513.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794095812

From liach at openjdk.org  Wed Oct  9 19:21:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 9 Oct 2024 19:21:24 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
Message-ID: <fhV_M9KAldvzROYPMqECi7ACCC2_HTDcBDYP5CySDCY=.a9a79dab-5d4b-4785-b9d8-952727a10d27@github.com>

On Wed, 9 Oct 2024 18:40:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - assertThrows instead of expectedExceptions
>>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> src/java.base/share/classes/java/io/Reader.java line 161:
> 
>> 159:      * {@code transferTo()} methods all throw {@code IOException}.
>> 160:      *
>> 161:      * <p> The returned reader supports the {@link #mark mark()} operation.
> 
> It may be useful to mention and link to the #reset method as well.

I think `mark()`'s specification implies that if mark is supported, then `reset()` can be called. We can make that explicit on `mark()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794110239

From sgehwolf at openjdk.org  Wed Oct  9 19:38:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Oct 2024 19:38:11 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support
In-Reply-To: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
Message-ID: <Q8b9Qi1JYyykIoZS8IhWDyGjQ_K_7LwIQk2b_LWNMuc=.b55d86e6-d9e7-4457-bd5a-9df6eaf554ad@github.com>

On Wed, 9 Oct 2024 14:50:30 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
> 
> Positive Testing:
> tier1,tier2,tier3 - to check stability
> tier5 - to run container tests
> 
> Negative Testing:
> Ran the following groups in hosts where container is not present.
> open/test/hotspot/jtreg/containers/
> open/test/jdk/jdk/internal/platform/docker/
> open/test/jdk/jdk/internal/platform/cgroup/

Seems OK to me. One minor nit.

test/lib/jdk/test/lib/Container.java line 27:

> 25: 
> 26: public class Container {
> 27:     // Use this property to specify container location on your system.

Suggestion:

    // Use this property to specify container runtime location (e.g. docker) on your system.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21423#pullrequestreview-2358152114
PR Review Comment: https://git.openjdk.org/jdk/pull/21423#discussion_r1794127601

From duke at openjdk.org  Wed Oct  9 20:11:18 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 9 Oct 2024 20:11:18 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
Message-ID: <z6PoAKA4l8g8WR2vZNlXWjTPdF8MseCKkVPoiBTkEbw=.82b92f2a-4f81-494f-8a18-49632ab638d5@github.com>

On Wed, 9 Oct 2024 18:59:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - assertThrows instead of expectedExceptions
>>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> test/jdk/java/io/Reader/Of.java line 40:
> 
>> 38:  * @bug 8341566
>> 39:  * @summary Check for expected behavior of Reader.of().
>> 40:  * @run testng Of
> 
> The test name should be more descriptive.  Without the package name it is unknown what this test does or what it tests.

The test name follows the conventions currently applied in this folder. Feel free to propose a better name, I would be happy to change it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794163340

From jlahoda at openjdk.org  Wed Oct  9 20:16:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 9 Oct 2024 20:16:19 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second Preview)
Message-ID: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@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

-------------

Commit messages:
 - Cleanup.
 - Cleanup.
 - Fixing tests
 - Adding a separate scope for module imports.
 - Cleanup.
 - Make very sure java.base is completed.
 - Keep jdk.internal.javac qualified export from java.base.
 - Adding forgotten change.
 - java.se is participating in preview.
 - Adding forgotten change.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/8c8f0d85...18554144

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335989
  Stats: 707 lines in 26 files changed: 550 ins; 44 del; 113 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 rgiulietti at openjdk.org  Wed Oct  9 20:22:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Oct 2024 20:22:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <Ugb5Xc_P_l6LM3T41jyyP2nvSNKgJvtviEGolapXdj0=.79e11c44-072f-4b27-a126-b30b516a0efd@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
 <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
 <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>
 <Ugb5Xc_P_l6LM3T41jyyP2nvSNKgJvtviEGolapXdj0=.79e11c44-072f-4b27-a126-b30b516a0efd@github.com>
Message-ID: <P1nGE3jj5c8JapHF2OxomVAXtUZ5LN8s1nnHznZbDwE=.3a7ca1bb-3649-4c9e-94c2-46b5b13d1d23@github.com>

On Wed, 9 Oct 2024 17:25:12 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> If you are interested, you can create new PRs without reference to JBS issues, and I'll file them.
>> As usual, it's easier for review purposes when each PR touches only small groups of strongly related changes rather than big modifications en-bloc.
>> 
>> But you should show JMH benchmark evidence in later comments (not the introductory comment) that there are no performance regressions, in addition to code simplification.
>
> @rgiulietti I think I just found a problem much more serious than a simple optimization, I'm afraid the semantics of `BigInteger.bitCount()` is ill-defined, although it seems absurd to me that no one has noticed it so far...

What's wrong with the semantics? In my understanding, it should count the ones for non-negative values and the zeros for negative values, where non-negative values have an infinite prefix of zero bits and negative values have an infinite prefix of one bits in two's complement representation.

Note that this is different from `[Long|Integer].bitCount()`, which consider their arguments as finite width unsigned bit strings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1794175124

From rgiulietti at openjdk.org  Wed Oct  9 20:35:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Oct 2024 20:35:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
Message-ID: <xF44UaWwUtS5W1mZXOCLKtTneh_zfybmujgT9UFz658=.af93196f-0832-46ad-b194-d1d09ee2662e@github.com>

On Wed, 9 Oct 2024 15:18:15 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Store log5(2) in BigDecimal

Benchmarks

Current mainline (note that `testXL` takes about 4 minutes for about 1 million trailing zeros)

Benchmark                            Mode  Cnt             Score            Error  Units
BigDecimalStripTrailingZeros.testL   avgt   15     243184468.777 ?    5774928.564  ns/op
BigDecimalStripTrailingZeros.testM   avgt   15        178494.667 ?        745.774  ns/op
BigDecimalStripTrailingZeros.testS   avgt   15           414.158 ?          2.164  ns/op
BigDecimalStripTrailingZeros.testXL  avgt   15  245675728189.000 ? 2061221700.695  ns/op
BigDecimalStripTrailingZeros.testXS  avgt   15            29.788 ?          0.567  ns/op
Finished running test 'micro:java.math.BigDecimalStripTrailingZeros'



Current status of this PR (note that `testXL` takes about 0.5 seconds for about 1 million trailing zeros)

Benchmark                            Mode  Cnt          Score         Error  Units
BigDecimalStripTrailingZeros.testL   avgt   15    2726326.956 ?   18516.336  ns/op
BigDecimalStripTrailingZeros.testM   avgt   15       9336.508 ?      88.096  ns/op
BigDecimalStripTrailingZeros.testS   avgt   15        155.843 ?       1.448  ns/op
BigDecimalStripTrailingZeros.testXL  avgt   15  445180776.778 ? 1891719.217  ns/op
BigDecimalStripTrailingZeros.testXS  avgt   15         21.512 ?       0.387  ns/op
Finished running test 'micro:java.math.BigDecimalStripTrailingZeros'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21323#issuecomment-2403376022

From duke at openjdk.org  Wed Oct  9 20:35:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 9 Oct 2024 20:35:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <P1nGE3jj5c8JapHF2OxomVAXtUZ5LN8s1nnHznZbDwE=.3a7ca1bb-3649-4c9e-94c2-46b5b13d1d23@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
 <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
 <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>
 <Ugb5Xc_P_l6LM3T41jyyP2nvSNKgJvtviEGolapXdj0=.79e11c44-072f-4b27-a126-b30b516a0efd@github.com>
 <P1nGE3jj5c8JapHF2OxomVAXtUZ5LN8s1nnHznZbDwE=.3a7ca1bb-3649-4c9e-94c2-46b5b13d1d23@github.com>
Message-ID: <9D0I7gIQRQl9zdqPVZ4Xx_MGPlIIpYO_8MuAPZbGOiw=.2916668d-a066-4c43-b5b6-34064409ac85@github.com>

On Wed, 9 Oct 2024 20:19:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti I think I just found a problem much more serious than a simple optimization, I'm afraid the semantics of `BigInteger.bitCount()` is ill-defined, although it seems absurd to me that no one has noticed it so far...
>
> What's wrong with the semantics? In my understanding, it should count the ones for non-negative values and the zeros for negative values, where non-negative values have an infinite prefix of zero bits and negative values have an infinite prefix of one bits in two's complement representation.
> 
> Note that this is different from `[Long|Integer].bitCount()`, which consider their arguments as finite width unsigned bit strings.

@rgiulietti But the documentation is not clear about this, it should be specified...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1794189722

From duke at openjdk.org  Wed Oct  9 20:50:19 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 9 Oct 2024 20:50:19 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <P1nGE3jj5c8JapHF2OxomVAXtUZ5LN8s1nnHznZbDwE=.3a7ca1bb-3649-4c9e-94c2-46b5b13d1d23@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
 <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
 <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>
 <Ugb5Xc_P_l6LM3T41jyyP2nvSNKgJvtviEGolapXdj0=.79e11c44-072f-4b27-a126-b30b516a0efd@github.com>
 <P1nGE3jj5c8JapHF2OxomVAXtUZ5LN8s1nnHznZbDwE=.3a7ca1bb-3649-4c9e-94c2-46b5b13d1d23@github.com>
Message-ID: <-fVHOUrkMAFWjRzNP83WEBEZ0gOdnjDgGi02awcd9sc=.cbe63631-2540-4fa5-a924-be0fc76b3f9d@github.com>

On Wed, 9 Oct 2024 20:19:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti I think I just found a problem much more serious than a simple optimization, I'm afraid the semantics of `BigInteger.bitCount()` is ill-defined, although it seems absurd to me that no one has noticed it so far...
>
> What's wrong with the semantics? In my understanding, it should count the ones for non-negative values and the zeros for negative values, where non-negative values have an infinite prefix of zero bits and negative values have an infinite prefix of one bits in two's complement representation.
> 
> Note that this is different from `[Long|Integer].bitCount()`, which consider their arguments as finite width unsigned bit strings.

@rgiulietti At least for me, the expression "the bits that differ from its sign bit" is misleading, it seems to implicitly imply that he is talking about the 1s bits which are not sign bits, while it means the bits whose value differs from the value of the sign bits...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1794205023

From bpb at openjdk.org  Wed Oct  9 20:53:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Oct 2024 20:53:11 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <tqvIAkR2Pnq2kXud51IgHSTrvh1E-SSVvth9irzjQMI=.66c6029b-d254-419c-91bd-366cbae51166@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

I think this is correct. `ExceptionOccurred` returns a local reference to a `Throwable` but it is used only in an implicit `!= NULL` check which is better served by the `jboolean` returned by `ExceptionCheck`.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2358283754

From bpb at openjdk.org  Wed Oct  9 20:54:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 9 Oct 2024 20:54:15 GMT
Subject: RFR: 8341791: Fix ExceptionOccurred in java.prefs
In-Reply-To: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
References: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
Message-ID: <Pv8FrrVdojsFzpgEmDOSum9le7T_J67q6BMe58fHhjY=.2e9eda25-3a28-43f1-b7f2-019ccf71b0dd@github.com>

On Wed, 9 Oct 2024 17:28:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.prefs_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21427#pullrequestreview-2358285049

From rgiulietti at openjdk.org  Wed Oct  9 21:14:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 9 Oct 2024 21:14:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <-fVHOUrkMAFWjRzNP83WEBEZ0gOdnjDgGi02awcd9sc=.cbe63631-2540-4fa5-a924-be0fc76b3f9d@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
 <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
 <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>
 <Ugb5Xc_P_l6LM3T41jyyP2nvSNKgJvtviEGolapXdj0=.79e11c44-072f-4b27-a126-b30b516a0efd@github.com>
 <P1nGE3jj5c8JapHF2OxomVAXtUZ5LN8s1nnHznZbDwE=.3a7ca1bb-3649-4c9e-94c2-46b5b13d1d23@github.com>
 <-fVHOUrkMAFWjRzNP83WEBEZ0gOdnjDgGi02awcd9sc=.cbe63631-2540-4fa5-a924-be0fc76b3f9d@github.com>
Message-ID: <llnanXif4pDPZ1PRiP-rY8MgFWQNeQPnQjWX56RvgZY=.e115e1d8-2fb8-4d19-9167-89ae368d34d8@github.com>

On Wed, 9 Oct 2024 20:47:25 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> What's wrong with the semantics? In my understanding, it should count the ones for non-negative values and the zeros for negative values, where non-negative values have an infinite prefix of zero bits and negative values have an infinite prefix of one bits in two's complement representation.
>> 
>> Note that this is different from `[Long|Integer].bitCount()`, which consider their arguments as finite width unsigned bit strings.
>
> @rgiulietti At least for me, the expression "the bits that differ from its sign bit" is misleading, it seems to implicitly imply that he is talking about the 1s bits which are not sign bits, while it means the bits whose value differs from the value of the sign bits...

The class Javadoc mentions, in at least two places, that the two's complement representation conceptually has an infinite number of leading virtual sign bits.
Once this point is clear, IMO the method's own Javadoc is then clear in turn. Maybe it could be improved as in "the bits that differ _in value_ from its sign bit". (Changing the spec requires another process and another, separate issue, but it can be done if needed.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1794234926

From rriggs at openjdk.org  Wed Oct  9 21:15:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Oct 2024 21:15:16 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <z6PoAKA4l8g8WR2vZNlXWjTPdF8MseCKkVPoiBTkEbw=.82b92f2a-4f81-494f-8a18-49632ab638d5@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
 <z6PoAKA4l8g8WR2vZNlXWjTPdF8MseCKkVPoiBTkEbw=.82b92f2a-4f81-494f-8a18-49632ab638d5@github.com>
Message-ID: <jy_1oSK80nqqZdS4ld8eZ9PME1atXzn-b8ecqsYaua4=.2fb102b7-0764-441b-863b-0777c908709d@github.com>

On Wed, 9 Oct 2024 20:08:25 GMT, Markus KARG <duke at openjdk.org> wrote:

>> test/jdk/java/io/Reader/Of.java line 40:
>> 
>>> 38:  * @bug 8341566
>>> 39:  * @summary Check for expected behavior of Reader.of().
>>> 40:  * @run testng Of
>> 
>> The test name should be more descriptive.  Without the package name it is unknown what this test does or what it tests.
>
> The test name follows the conventions currently applied in this folder. Feel free to propose a better name, I would be happy to change it.

The test name should provide enough context so the *human* reader does not have to hunt around for the context.
Either CharSequenceReader or ReaderOfCharSequence would be easier to understand without having to *know* the conventions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794235847

From jrose at openjdk.org  Wed Oct  9 21:43:19 2024
From: jrose at openjdk.org (John R Rose)
Date: Wed, 9 Oct 2024 21:43:19 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v7]
In-Reply-To: <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>
Message-ID: <QcnXxTG51jIuDuOwBVDFD1E5ddZlGDSz8P8_rU3gDVE=.30a6f2cc-5b14-40f3-88bb-699626f68779@github.com>

On Wed, 2 Oct 2024 01:06:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/c68bb02b...1b067b7b

This is good although hacky, due to incomplete "build out" of Leyden-related functionality.  For a first JEP it is fine.  But it leaves some debt to pay off later.

Later, we need to decide how to more fully embrace SoftReference.  There is nothing inherently wrong with mixing SR's and AOT, even if they interfere somewhat.  I think the right answer might be forcing them to get along better.  We need to get their queueing status into a quiet state order to push them into the AOT cache (and then pull them out as the production run states).  It seems to me we should (first) try pruning away most of the queueing infrastructure during the assembly phase, and patching it up in the production run (at some appropriate `VM::initState` level), so that the SRs "go live" at a controlled point during boot-up.

Or, we could do a Three Table (or Two Table) solution.  This PR is an example of a Two Table solution.  (One could say the handoff from AOT table to runtime table is overly subtle but it works, and maybe that subtlety just comes with the territory.)  The various cache variables (`Transform.cache` and `MTF.LFs/MHs`) right now are polymorphically SRs or hard references.  The variable `MethodHandleStatics.NO_SOFT_CACHE` controls which "table" is active.  (This is a sort of "sharded" table, not a centralized table object.)  Cached values are inserted into the table using soft or hard refs, depending on NO_SOFT_CACHE.  They are extracted in a robust way, using instanceof, which is good.  There is no plan for converting hard to soft refs, which is probably OK; we can fix this later if we need to.

If we have a sudden flash of insight how to support AOT of soft references (SRs), then this PR goes away.  Otherwise, I have one request, related to MethodHandleStatics.  I think we should be moving towards respecting the finals of that class, like any other class, as AOT-able values.  Using just one static as a secret channel for AOT logic is too edgy for my taste.

First, `NO_SOFT_CACHE should probably be a @Stable variable, not a final, so it can be patched.  And it should be inverted:  `@Stable boolean USE_SOFT_CACHES`.  When the VM goes to the right init-phase (but never during assembly phase), that boolean should be set true, and it will act like a constant true boolean forever after.

Also, consider moving it (as a stable non-final) to `MethodHandleNatives`, since its state depends on stuff below the level of Java proper.  I think `MethodHandleStatics` stuff has a different area of responsibility than `USE_SOFT_CACHES`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21049#issuecomment-2403478570

From jlu at openjdk.org  Wed Oct  9 21:48:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Oct 2024 21:48:18 GMT
Subject: Integrated: 8341366: Suspicious check in Locale.getDisplayName(Locale
 inLocale)
In-Reply-To: <mV3B1kRYE7kcvVEsIHe_4DcvT99kxlx0m7ELKGxZAfc=.166246cd-5fc2-4c0a-83e5-9e30a399ec1b@github.com>
References: <mV3B1kRYE7kcvVEsIHe_4DcvT99kxlx0m7ELKGxZAfc=.166246cd-5fc2-4c0a-83e5-9e30a399ec1b@github.com>
Message-ID: <zHC3cQLzLto2QN_dfehOGlviMeGdKt52XObzstn6RJo=.6fad9265-62e3-4ff7-802b-4906652e0c43@github.com>

On Tue, 1 Oct 2024 21:46:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which modifies a suspicious check in the fallback of `Locale.getDisplayName(Locale inLocale)`.
> 
> As a fallback, a hard coded pattern is used. The previous code outputted the qualifiers if the `displayNames` array had length greater than 2. Just a few lines above, the array is initialized with a length of 3 and so the check is pointless.
> 
> It would be better, if replaced with a null check for the last element of the `displayNames` array, as that element may be null if there are no qualifiers. See L2317 ,
> 
> `qualifierNames.length != 0 ? formatList(qualifierNames, listCompositionPattern) : null`
> 
> For example, now a fallback (with no qualifiers) might look like: `German` instead of `German (null)`.
> But will remain the same (with qualifiers): `German (Germany)`.

This pull request has now been integrated.

Changeset: 49c7148d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/49c7148d3770c1ba2cd291f7b55ad471577ee151
Stats:     6 lines in 1 file changed: 0 ins; 1 del; 5 mod

8341366: Suspicious check in Locale.getDisplayName(Locale inLocale)

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21298

From jlu at openjdk.org  Wed Oct  9 21:49:17 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Oct 2024 21:49:17 GMT
Subject: Integrated: 8341684: Typo in External Specifications link of
 java.util.Currency
In-Reply-To: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
References: <sURtpNoqJFOsk572HPulefqDyaWBDS69rxsvw1mHEKs=.25dd179f-0da7-4967-a86b-70a88927680c@github.com>
Message-ID: <Sj7UkMqyBVltMoV6zYcqMSsvCMKgk-zwRFroyF_cOQU=.0ac35247-fd50-448d-a796-ed9189f84a19@github.com>

On Tue, 8 Oct 2024 23:11:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A trivial correction to the  _j.util.Currency_ external specification ISO currency codes link. Browsers will auto resolve and correct the link, but it should still be fixed regardless.

This pull request has now been integrated.

Changeset: e7045e93
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7045e9399c5bca0592afc5769432414ecae7219
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8341684: Typo in External Specifications link of java.util.Currency

Reviewed-by: liach, naoto, srl

-------------

PR: https://git.openjdk.org/jdk/pull/21416

From sspitsyn at openjdk.org  Wed Oct  9 22:47:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 22:47:31 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v2]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <qkkPxqZteiOkzUaZyknfx0hDPbHXLfWZFjTKJHIiTBU=.bea75699-5740-4622-b02a-521be2fbe527@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: 1. Minor tweaks in new test; 2. Refactor skip_hidden_frames in two

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/8615d2b9..8ec7bd3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=00-01

  Stats: 42 lines in 3 files changed: 23 ins; 12 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From sspitsyn at openjdk.org  Wed Oct  9 22:58:33 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 22:58:33 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/8ec7bd3f..3317ea81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=01-02

  Stats: 14 lines in 2 files changed: 8 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From swen at openjdk.org  Wed Oct  9 23:53:20 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 9 Oct 2024 23:53:20 GMT
Subject: Integrated: 8341755: Optimize argNames in InnerClassLambdaMetafactory
In-Reply-To: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
References: <_fldNDGPsCjaeXokYuciGix-ubXN6o02U4o44Y9KY5c=.2339155a-7547-4e22-9680-b1bf0326a097@github.com>
Message-ID: <65jqe_6iKNh049mZ9s-HcHy33KmzfJDfrqEmBVRtfdI=.ded47d1d-9fe3-41e5-8efb-a4f8f917a844@github.com>

On Tue, 8 Oct 2024 00:47:27 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A simple optimization that eliminates the allocation of the MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates the allocation of argNames when parameterCount is equal to 1

This pull request has now been integrated.

Changeset: c850ecb2
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c850ecb20a095cb69da81f6fbe5da9c4bce66e77
Stats:     26 lines in 1 file changed: 10 ins; 8 del; 8 mod

8341755: Optimize argNames in InnerClassLambdaMetafactory

Co-authored-by: Chen Liang <liach at openjdk.org>
Reviewed-by: liach, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/21399

From swen at openjdk.org  Thu Oct 10 00:06:18 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Oct 2024 00:06:18 GMT
Subject: Integrated: 8341859: Optimize ClassFile Benchmark Write
In-Reply-To: <oQ_Kzd87EIICz5jKbJ5jrnmecVHzyvJ-SAlBe4cxZYA=.af49d1fb-181a-4c98-9546-9a0382a602e2@github.com>
References: <oQ_Kzd87EIICz5jKbJ5jrnmecVHzyvJ-SAlBe4cxZYA=.af49d1fb-181a-4c98-9546-9a0382a602e2@github.com>
Message-ID: <RfKmelmVkMJ1mOz5OEBXSv6XvXgZ-ho99dZamDAOlKk=.99761935-8f01-4d04-bbe5-c92faffe46df@github.com>

On Wed, 9 Oct 2024 17:17:36 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Cache method names to reduce the overhead of using StringBuilder to construct method names, which will make the performance test results more stable.

This pull request has now been integrated.

Changeset: 475f8f94
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/475f8f94e038e10c796b5d56f939384d7b84da54
Stats:     13 lines in 1 file changed: 9 ins; 0 del; 4 mod

8341859: Optimize ClassFile Benchmark Write

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21425

From duke at openjdk.org  Thu Oct 10 00:17:32 2024
From: duke at openjdk.org (Luca Kellermann)
Date: Thu, 10 Oct 2024 00:17:32 GMT
Subject: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v35]
In-Reply-To: <q1FPAZv5Ri_LysFtpAM3BlpJVZ3RoUTA_9GkLwc-ppE=.efc42fb9-c5d6-4a15-ad30-3dcbf8449828@github.com>
References: <R74ontYwjYg6HeZY0cWrlo0amjl4E1YsFWeuh4pda14=.08ac62df-b2f8-4b4d-b338-07adb289601b@github.com>
 <q1FPAZv5Ri_LysFtpAM3BlpJVZ3RoUTA_9GkLwc-ppE=.efc42fb9-c5d6-4a15-ad30-3dcbf8449828@github.com>
Message-ID: <0nG6Ma5PqefNeOTJCPO7L-DUAxAkbB_YhPsLDjuqJ4s=.5118ab72-1ed7-4e81-abdd-f06f852cff67@github.com>

On Fri, 31 May 2024 18:33:39 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Classes in the `java.lang.ref` package would benefit from an update to bring the spec in line with how the VM already behaves. The changes would focus on _happens-before_ edges at some key points during reference processing.
>> 
>> A couple key things we want to be able to say are:
>> - `Reference.reachabilityFence(x)` _happens-before_ reference processing occurs for 'x'.
>> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the registered cleaning action.
>> 
>> This will bring Cleaner in line (or close) with the memory visibility guarantees made for finalizers in [JLS 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5):
>> _"There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (?12.6) for that object."_
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another package doc link

src/java.base/share/classes/java/lang/ref/Reference.java line 561:

> 559:      * triggering garbage collection.  This method is applicable only
> 560:      * when reclamation may have visible effects,
> 561:      * such as for objects that use finalizers or {@link Cleaner}, or code that

This `@link` tag [does not produce a link in the Javadoc](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/ref/Reference.html#reachabilityFence(java.lang.Object)) because this file imports `jdk.internal.ref.Cleaner`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1794411907

From swen at openjdk.org  Thu Oct 10 01:13:07 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Oct 2024 01:13:07 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName [v2]
In-Reply-To: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
Message-ID: <qWsxQ0pheLkBfa2W8ikejyuRTaPanvYOQEv0ExcbuK0=.f9476579-f0fa-40f2-9092-9de524c5140a@github.com>

> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

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 four additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - suggestion from @liach
 - stable
 - ReferenceClassDescImpl cache internalName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21373/files
  - new: https://git.openjdk.org/jdk/pull/21373/files/478f97f9..ef54ed21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=00-01

  Stats: 9917 lines in 194 files changed: 8099 ins; 580 del; 1238 mod
  Patch: https://git.openjdk.org/jdk/pull/21373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21373/head:pull/21373

PR: https://git.openjdk.org/jdk/pull/21373

From alanb at openjdk.org  Thu Oct 10 04:39:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 04:39:13 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
Message-ID: <uTLu1pyxwgLnUnL71gMwGk91qVarhKBB9epudUOHe-w=.80cbda31-cd5c-459c-8d20-11430c6c0bd4@github.com>

On Wed, 9 Oct 2024 11:49:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - assertThrows instead of expectedExceptions
>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER

src/java.base/share/classes/java/io/StringReader.java line 38:

> 36:  * {@code Reader.of(String)} should generally be used in preference to this one,
> 37:  * as it supports all of the same operations but it is faster, as it performs no
> 38:  * synchronization.

We shouldn't using "release 24" or "supplemented" here. The API note just needs to `Reader.of(CharSequence)` provides a method to read from any CharSequence that may be more efficient than `StringReader`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794636497

From alanb at openjdk.org  Thu Oct 10 04:56:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 04:56:13 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <MYVO_RBjjb-pWQtM8-rSOu6kwSkSc8isaVE5-PSiVis=.a4ea6d1f-4144-497f-8cb0-7a726fb6469e@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
 <MYVO_RBjjb-pWQtM8-rSOu6kwSkSc8isaVE5-PSiVis=.a4ea6d1f-4144-497f-8cb0-7a726fb6469e@github.com>
Message-ID: <cSuyup1QKnhWCwlGEk6wq6yR2Z10CsO66uLU6LOOJ98=.4d4f2c1f-7674-40fb-8741-3110b0d7e0c4@github.com>

On Wed, 9 Oct 2024 19:12:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I see Alan and I have different views on the inclusion of the details. With only a single CharSequence argument, I can't see any ambiguity about the starting position.

It could be a second sentence, "Reading starts at the first character in the sequence".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794648407

From liach at openjdk.org  Thu Oct 10 04:56:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Oct 2024 04:56:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <uTLu1pyxwgLnUnL71gMwGk91qVarhKBB9epudUOHe-w=.80cbda31-cd5c-459c-8d20-11430c6c0bd4@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <uTLu1pyxwgLnUnL71gMwGk91qVarhKBB9epudUOHe-w=.80cbda31-cd5c-459c-8d20-11430c6c0bd4@github.com>
Message-ID: <-LYYyZN6oZhvXjdStVH3uAPHWC4K4IWn3IwuKtm8oNY=.bd4fbc33-6af3-4fa6-a8ff-bf288903b0f8@github.com>

On Thu, 10 Oct 2024 04:36:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - assertThrows instead of expectedExceptions
>>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> src/java.base/share/classes/java/io/StringReader.java line 38:
> 
>> 36:  * {@code Reader.of(String)} should generally be used in preference to this one,
>> 37:  * as it supports all of the same operations but it is faster, as it performs no
>> 38:  * synchronization.
> 
> We shouldn't using "release 24" or "supplemented" here. The API note just needs to `Reader.of(CharSequence)` provides a method to read from any CharSequence that may be more efficient than `StringReader`.

I think "release 24" is fine for now as similar text exists in `java.util.Vector`. We can normalize such texts when we implement https://bugs.openjdk.org/browse/JDK-8341736.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794650465

From alanb at openjdk.org  Thu Oct 10 04:57:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 04:57:13 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v5]
In-Reply-To: <RVqTDqexv9ICI2fzagkynzzJBJkVpEZ5NlrpUk5070k=.2aebc7a0-e88d-4205-84c9-71ba37c6f913@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <RVqTDqexv9ICI2fzagkynzzJBJkVpEZ5NlrpUk5070k=.2aebc7a0-e88d-4205-84c9-71ba37c6f913@github.com>
Message-ID: <Iu99Qy5641JPXzOQMC665kZHjStTK601Mc7uBscdK9Q=.d48e3719-3872-4284-bf64-b01b74d7bab1@github.com>

On Wed, 9 Oct 2024 07:00:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mandy's review suggestion for man page

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21380#pullrequestreview-2358950420

From alanb at openjdk.org  Thu Oct 10 05:03:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 05:03:12 GMT
Subject: RFR: 8335989: Implement 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: <fLVhcJ4GM-NSzzLdwMyr3BcUU836F8ecoUWIA4_1kZ4=.f5dd6d89-0cb9-4264-bcae-e67afc6e5f03@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

test/jdk/java/lang/module/ModuleDescriptorTest.java line 1574:

> 1572:     }
> 1573: 
> 1574:     private byte[] setClassFileVersion(int major, int minor, byte[] bytecode) {

Would it be possible to add a method description and re-format the overly long lines as it's currently impossible to look at the change side-by-side.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1794655877

From alanb at openjdk.org  Thu Oct 10 05:12:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 05:12:11 GMT
Subject: RFR: 8335989: Implement 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: <cpFwTgAHcCf32egTLY70rLKOi0LPb388Q3EitYMs4Eg=.7518dd7f-f1f0-4cfb-94ef-f29f601bbc2a@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

Can you check if test/jdk/java/lang/module/ClassFileVersionsTest.java should be updated too?

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 193:

> 191:         int minor_version = in.readUnsignedShort();
> 192:         int major_version = in.readUnsignedShort();
> 193:         boolean previewClassfile = minor_version == ClassFile.PREVIEW_MINOR_VERSION;

If you rename this to isPreview then it would make the uses further down easier to read.

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 417:

> 415:                          //java.* modules are deemed participating in preview
> 416:                          //and are allowed to use requires transitive java.base:
> 417:                          !mn.startsWith("java."))

A block comment before the `if` statement would be a lot clearer here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21431#issuecomment-2404032481
PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1794661012
PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1794662049

From duke at openjdk.org  Thu Oct 10 05:46:12 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 05:46:12 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <jy_1oSK80nqqZdS4ld8eZ9PME1atXzn-b8ecqsYaua4=.2fb102b7-0764-441b-863b-0777c908709d@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
 <z6PoAKA4l8g8WR2vZNlXWjTPdF8MseCKkVPoiBTkEbw=.82b92f2a-4f81-494f-8a18-49632ab638d5@github.com>
 <jy_1oSK80nqqZdS4ld8eZ9PME1atXzn-b8ecqsYaua4=.2fb102b7-0764-441b-863b-0777c908709d@github.com>
Message-ID: <XZXaYmNjtftS9z9unvo2h2dqAjklHoDCiOfx1Mea0z0=.59420f38-9a09-4d7c-90fb-00ab12a15f5e@github.com>

On Wed, 9 Oct 2024 21:12:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The test name follows the conventions currently applied in this folder. Feel free to propose a better name, I would be happy to change it.
>
> The test name should provide enough context so the *human* reader does not have to hunt around for the context.
> Either CharSequenceReader or ReaderOfCharSequence would be easier to understand without having to *know* the conventions.

I personally did not have any problem understanding the existing conventions within a second, but OTOH I have no strong feelings here.

@AlanBateman Which of both proposed names shall I use (or shall I keep the current name)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794696841

From duke at openjdk.org  Thu Oct 10 05:50:15 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 05:50:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <GnP8HzGl4mrD7ElrsjTssc3ewI-r68aptWm0b8Txi08=.67c9d101-e6c2-4997-a0ac-2fc0d4e8c37f@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
 <GnP8HzGl4mrD7ElrsjTssc3ewI-r68aptWm0b8Txi08=.67c9d101-e6c2-4997-a0ac-2fc0d4e8c37f@github.com>
Message-ID: <XKRrT3nYYyFP7jTwmhjmtqvTW8WuOjrIv9cBpsP55F0=.2076f5bc-cafd-4073-a9c4-130b8ee337eb@github.com>

On Wed, 9 Oct 2024 19:14:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/StringReader.java line 38:
>> 
>>> 36:  * {@code Reader.of(String)} should generally be used in preference to this one,
>>> 37:  * as it supports all of the same operations but it is faster, as it performs no
>>> 38:  * synchronization.
>> 
>> Consider how this API note will age gracefully in a few releases.
>> I'd lead with the link to the new method and mention it is unsynchronized/single-thread safe.
>> The comments about performance and "better" belong in the release note.
>> Uncontested locks will be barely noticeable from a performance perspective.
>
> Currently uncontested locks have a performance regression after the removal of biased locking: A similar example with `StringBuffer` is available in #19513.

I do not have any personal preferences here. The text was paraphrased from `StringBuilder`, so it seems it was acceptable in the past. If a different text is wanted, I would kindly ask all participants in this discussion to agree upon one common proposal, as I personally am fine with the text as-is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794702589

From rsunderbabu at openjdk.org  Thu Oct 10 06:04:10 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Thu, 10 Oct 2024 06:04:10 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust
In-Reply-To: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
Message-ID: <MFVvS6O-bZZNmnYw-PnftoZef8IvJrQNdhgd-3-JnVc=.1a5babbe-297b-4db4-bd89-ce5fccc5fa8f@github.com>

On Tue, 8 Oct 2024 17:10:43 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
> 
> Testing: The test was run for 100 times with -Xcomp option.

Background of the issue:


        Instant expected = Instant.now(Clock.systemUTC());
        Instant test = Instant.now();
        long diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
        assertTrue(diff < 100);  // less than 0.1 secs


In normal cases, the difference between the test and expected stay within the threshold of 100ms.
Issue happens when the code is run with compilation options such as -Xcomp, -Xbatch etc. The aggressive JIT optimizations and other stop-the-world pauses introduce delay in execution and the difference ends up more than 100ms.
The difference is increased to 10s to account for such delays.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21413#issuecomment-2404108128

From lucy at openjdk.org  Thu Oct 10 06:46:13 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 10 Oct 2024 06:46:13 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
Message-ID: <8FNj6NUjFGDmgaThzmacRV9g584Pm6_5v-wdtjJCao8=.877913eb-0cfd-4b4e-971a-d39525cf77e9@github.com>

On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust gcc warning settings; bring back rslt

LGTM.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21407#pullrequestreview-2359153153

From jpai at openjdk.org  Thu Oct 10 07:06:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Oct 2024 07:06:10 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <nmKLk2D_1pr_O5549B-2Hr9qmQ8gV3xEkaeX0QWkBZY=.bde04ae3-e5dc-4d5c-961e-ec205d1e92f0@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2359224533

From duke at openjdk.org  Thu Oct 10 07:17:15 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 07:17:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <cSuyup1QKnhWCwlGEk6wq6yR2Z10CsO66uLU6LOOJ98=.4d4f2c1f-7674-40fb-8741-3110b0d7e0c4@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
 <MYVO_RBjjb-pWQtM8-rSOu6kwSkSc8isaVE5-PSiVis=.a4ea6d1f-4144-497f-8cb0-7a726fb6469e@github.com>
 <cSuyup1QKnhWCwlGEk6wq6yR2Z10CsO66uLU6LOOJ98=.4d4f2c1f-7674-40fb-8741-3110b0d7e0c4@github.com>
Message-ID: <dAZi-brxG3I-IM9s2HANj5sywVfsI7pHawxFQ68NW3c=.042f1c58-b3d0-4bc3-8c96-ad20e850a5fb@github.com>

On Thu, 10 Oct 2024 04:50:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I see Alan and I have different views on the inclusion of the details.
>> With only a single CharSequence argument, I can't see any ambiguity about the starting position.
>
>> I see Alan and I have different views on the inclusion of the details. With only a single CharSequence argument, I can't see any ambiguity about the starting position.
> 
> It could be a second sentence, "Reading starts at the first character in the sequence".

Done. Adopted Alan's wording.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794822439

From mbaesken at openjdk.org  Thu Oct 10 07:24:15 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Oct 2024 07:24:15 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
Message-ID: <Z3NDDQE7tjdPILWu5DWvD9grFYyzyZwbibRPtDgCEaA=.4098e049-b95a-4b89-a02a-dcec1e7e7b6e@github.com>

On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust gcc warning settings; bring back rslt

Thanks for the reviews and suggestions !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21407#issuecomment-2404260346

From mbaesken at openjdk.org  Thu Oct 10 07:24:16 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Oct 2024 07:24:16 GMT
Subject: Integrated: 8341722: Fix some warnings as errors when building on
 Linux with toolchain clang
In-Reply-To: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
Message-ID: <Z7A56gGI5IwoycWemvUUcTAbiLFB6Tp5C_bfkTHWFgg=.dcce4122-c3cf-44be-9421-8887eaf09aca@github.com>

On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

This pull request has now been integrated.

Changeset: e7c5bf45
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7c5bf45f753ad6459c666a4dd4a31197b69e05e
Stats:     12 lines in 5 files changed: 1 ins; 8 del; 3 mod

8341722: Fix some warnings as errors when building on Linux with toolchain clang

Reviewed-by: cjplummer, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/21407

From duke at openjdk.org  Thu Oct 10 07:32:53 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 07:32:53 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v8]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <rCnMftlndUjue1aR6lqHozSTroP1a6m2IFPIh_Q13Os=.727e6172-27df-4e6a-835c-213b69fabd18@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  improved wording / formatting of JavaDocs; introduced local length

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/c0729baf..b0ff5a78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=06-07

  Stats: 10 lines in 1 file changed: 4 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From duke at openjdk.org  Thu Oct 10 07:32:53 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 07:32:53 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <fhV_M9KAldvzROYPMqECi7ACCC2_HTDcBDYP5CySDCY=.a9a79dab-5d4b-4785-b9d8-952727a10d27@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
 <fhV_M9KAldvzROYPMqECi7ACCC2_HTDcBDYP5CySDCY=.a9a79dab-5d4b-4785-b9d8-952727a10d27@github.com>
Message-ID: <WdVFGCtc9FTWsmLiwUXT1LGDevRD4oDJyzckLB2Bpmc=.c302d632-f1cb-487b-bcbb-4ca57afa2d2e@github.com>

On Wed, 9 Oct 2024 19:19:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 161:
>> 
>>> 159:      * {@code transferTo()} methods all throw {@code IOException}.
>>> 160:      *
>>> 161:      * <p> The returned reader supports the {@link #mark mark()} operation.
>> 
>> It may be useful to mention and link to the #reset method as well.
>
> I think `mark()`'s specification implies that if mark is supported, then `reset()` can be called. We can make that explicit on `mark()`.

I share both visions, so I have adopted #reset now as it does not harm IMHO.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794826763

From duke at openjdk.org  Thu Oct 10 07:32:53 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 07:32:53 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
Message-ID: <jwephqOs9KT1Ccre9Yf6whJbbhmd_nBIFsgVS0TgcOc=.2b27183f-f695-4b08-9c91-646dd94e35cf@github.com>

On Wed, 9 Oct 2024 18:42:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - assertThrows instead of expectedExceptions
>>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> src/java.base/share/classes/java/io/Reader.java line 168:
> 
>> 166:      *
>> 167:      * @throws NullPointerException if {@code cs} is {@code null}
>> 168:      *
> 
> Drop the extra empty lines, to be more consistent with Reader code style and make the source more compact.

done

> src/java.base/share/classes/java/io/Reader.java line 202:
> 
>> 200:                 if (next >= cs.length())
>> 201:                     return -1;
>> 202:                 int n = Math.min(cs.length() - next, len);
> 
> Is there any sensitivity to cs.length() changing between these calls? (For an arbitrary custom implementation).
> The spec for undefined behavior covers that but might be safer to compute a local length.

done; introduced local variable

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794828638
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1794831570

From duke at openjdk.org  Thu Oct 10 07:36:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 10 Oct 2024 07:36:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <llnanXif4pDPZ1PRiP-rY8MgFWQNeQPnQjWX56RvgZY=.e115e1d8-2fb8-4d19-9167-89ae368d34d8@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
 <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
 <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>
 <Ugb5Xc_P_l6LM3T41jyyP2nvSNKgJvtviEGolapXdj0=.79e11c44-072f-4b27-a126-b30b516a0efd@github.com>
 <P1nGE3jj5c8JapHF2OxomVAXtUZ5LN8s1nnHznZbDwE=.3a7ca1bb-3649-4c9e-94c2-46b5b13d1d23@github.com>
 <-fVHOUrkMAFWjRzNP83WEBEZ0gOdnjDgGi02awcd9sc=.cbe63631-2540-4fa5-a924-be0fc76b3f9d@github.com>
 <llnanXif4pDPZ1PRiP-rY8MgFWQNeQPnQjWX56RvgZY=.e115e1d8-2fb8-4d19-9167-89ae368d34d8@github.com>
Message-ID: <KvAPTu7Unz7aKs_-fkq5Fw3UF1Ny6puzXr4W3RS5I1I=.6f1c5100-0871-4c77-b9f9-fd72e8fa8362@github.com>

On Wed, 9 Oct 2024 21:11:16 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti At least for me, the expression "the bits that differ from its sign bit" is misleading, it seems to implicitly imply that he is talking about the 1s bits which are not sign bits, while it means the bits whose value differs from the value of the sign bits...
>
> The class Javadoc mentions, in at least two places, that the two's complement representation conceptually has an infinite number of leading virtual sign bits.
> Once this point is clear, IMO the method's own Javadoc is then clear in turn. Maybe it could be improved as in "the bits that differ _in value_ from its sign bit". (Changing the spec requires another process and another, separate issue, but it can be done if needed.)

@rgiulietti So it must have been my limitation, but I didn't realize it, even though I knew that there are virtually infinite sign bits...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1794847956

From jpai at openjdk.org  Thu Oct 10 07:58:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Oct 2024 07:58:09 GMT
Subject: RFR: 8341791: Fix ExceptionOccurred in java.prefs
In-Reply-To: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
References: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
Message-ID: <xsy-8lkz820UqpNigqhS1DygZvoZC3YFhNV-4qzC1ec=.119b2c1d-ec01-4d91-bad3-541a1740fd56@github.com>

On Wed, 9 Oct 2024 17:28:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.prefs_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21427#pullrequestreview-2359400562

From mbaesken at openjdk.org  Thu Oct 10 08:18:11 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Oct 2024 08:18:11 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]
In-Reply-To: <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
 <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>
Message-ID: <Afhej78kcVss1IDSqHuLmvGMQL64QeyiTLEHFI3RTqk=.c0f5275f-776b-4cd1-bb6e-a40b4b54dce9@github.com>

On Wed, 2 Oct 2024 20:29:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> jni_util.h is used across all modules but it is located in `java.base/share/native/libjava` not `java.base/unix/native/libjava`.
> 
> I think you could probably place ub.h along-side jni_util.h in that directory.


Hi David, are you fine with the latest version ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2404399409

From jwaters at openjdk.org  Thu Oct 10 08:26:12 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Oct 2024 08:26:12 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
Message-ID: <YUSAHbPYNykkj8SJ1-vhsrePOvfJnLYfxkkWg05qYr8=.e4e231b2-c637-4263-98b9-4cbf854e2ee3@github.com>

On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8340801
>  - move ub.h to a better location
>  - remove ubsan changes from jni_md.h
>  - JDK-8340801

I do wonder why the header both here and inside HotSpot is named ub.h instead of ubsan.h. Latter sounds better to me, but it doesn't really matter much

-------------

PR Review: https://git.openjdk.org/jdk/pull/21184#pullrequestreview-2359482852

From swen at openjdk.org  Thu Oct 10 09:04:22 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Oct 2024 09:04:22 GMT
Subject: RFR: 8341900: Optimize DirectCodeBuilder writeBody
Message-ID: <1ll-Cy1m3u-A9GUqixqxkTUpv0qWHkgVLbUsZiiYfQc=.456cfb0c-aa33-40cd-bbcb-961ad69d2f46@github.com>

A simple optimization to reduce duplicate code. Reduce the codeSize of writeBody from 268 to 240

-------------

Commit messages:
 - optimize writeBody

Changes: https://git.openjdk.org/jdk/pull/21440/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21440&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341900
  Stats: 18 lines in 1 file changed: 5 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21440.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21440/head:pull/21440

PR: https://git.openjdk.org/jdk/pull/21440

From liach at openjdk.org  Thu Oct 10 09:04:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Oct 2024 09:04:22 GMT
Subject: RFR: 8341900: Optimize DirectCodeBuilder writeBody
In-Reply-To: <1ll-Cy1m3u-A9GUqixqxkTUpv0qWHkgVLbUsZiiYfQc=.456cfb0c-aa33-40cd-bbcb-961ad69d2f46@github.com>
References: <1ll-Cy1m3u-A9GUqixqxkTUpv0qWHkgVLbUsZiiYfQc=.456cfb0c-aa33-40cd-bbcb-961ad69d2f46@github.com>
Message-ID: <2jwaQ7AhMTxYRJkLQwo0Tm8xmX_VzIQw-mmEHZjywP4=.6c74c857-50d0-4690-8b6f-a97152ce30aa@github.com>

On Thu, 10 Oct 2024 03:55:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A simple optimization to reduce duplicate code. Reduce the codeSize of writeBody from 268 to 240

A simplification indeed.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21440#pullrequestreview-2358964642

From dfuchs at openjdk.org  Thu Oct 10 09:34:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 10 Oct 2024 09:34:12 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <l6fjqVOKleomHN1GWHa9hd9GQdGgnNgqCwveUkwWr-c=.4c0e08a8-cd42-43ee-b0d1-4d05c439f527@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by dfuchs (Reviewer).

>From https://docs.oracle.com/en/java/javase/23/docs/specs/jni/functions.html#exceptioncheck :

> ExceptionCheck
> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object.
> 
> jboolean ExceptionCheck(JNIEnv *env);
> 
> Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.
> 

So this looks good to me too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2359643144
PR Comment: https://git.openjdk.org/jdk/pull/21428#issuecomment-2404578043

From sspitsyn at openjdk.org  Thu Oct 10 10:29:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Oct 2024 10:29:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <tDKSsTCaV04gGLI8ipFTwtIw-YMbbdxsP8llgnioA1k=.b43f02f2-bae9-4000-87d4-d5650fec2e1d@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

I've pushed two updates.
The first one addresses the suggestions from Leonid:
 - minor tweaks in new test
 - moved skipping hidden methods `yield()` and `yield0()` from `check_and_skip_hidden_frames()` to a separate function
 - explained in a comment of `JvmtiHandshake::execute()` why all VTMS transitions are disabled for platform thread
 - added extra safety/stability checks and a couple of asserts around calls to `check_and_skip_hidden_frames()`
 
 Second update fixes one more `NotifyFramePop` issue with the frames at the virtual thread start:
  - `enter()`, `enter0`, `VThreadContinuation$1.run()` and `VirtualThread.run()`
  
 This the bottom of stack trace from debugger:

  0: java/lang/VirtualThread: run(Ljava/lang/Runnable;)V
  1: java/lang/VirtualThread$VThreadContinuation$1: run()V
  2: jdk/internal/vm/Continuation: enter0()V
  3: jdk/internal/vm/Continuation: enter(Ljdk/internal/vm/Continuation;Z)V

The fix includes three parts:
- the `notifyJvmtiStart()`/`notifyJvmtiEnd()` notification calls are moved from `VirtualThread.run()` to the `VThreadContinuation$1.run()`
- the annotation `@JvmtiMountTransition` has been added to the `VThreadContinuation$1.run()`
- the `NotifyFramePop` is changed to return `JVMTI_ERRO_OPAQUE_FRAME` for frames with `enter()` and methods annotated with `@JvmtiMountTransition`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2404706773

From lancea at openjdk.org  Thu Oct 10 11:10:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 10 Oct 2024 11:10:10 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <6Nw5WhhOFHWLbeiAk3uUiuMwz4bRXSMi0qaTnh4GQ34=.5a9d8f6b-405d-4566-87d4-287f9eead997@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Hi Justin,

Overall looks fine.  I
t looks like
open/src/java.base/share/native/libzip/Deflater.c
open/src/java.base/share/native/libzip/Inflater.c

also same for line 670 in open.bk/src/java.base/share/native/libjli/java.c

were left out from the commit for the PR but are listed in the JBS issue so it would be great to include the updates as part of this PR or explain why they were excluded if it was intentional

-------------

Changes requested by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2359952631

From alanb at openjdk.org  Thu Oct 10 11:43:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 11:43:12 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <6Nw5WhhOFHWLbeiAk3uUiuMwz4bRXSMi0qaTnh4GQ34=.5a9d8f6b-405d-4566-87d4-287f9eead997@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
 <6Nw5WhhOFHWLbeiAk3uUiuMwz4bRXSMi0qaTnh4GQ34=.5a9d8f6b-405d-4566-87d4-287f9eead997@github.com>
Message-ID: <9dmqP3SbyAaode7z7nyAfExJkZ0jdeafJkdqvW1nF3k=.99d8e4ce-1632-4d74-b1e2-2c4310b098eb@github.com>

On Thu, 10 Oct 2024 11:07:19 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> were left out from the commit for the PR but are listed in the JBS issue so it would be great to include the updates as part of this PR or explain why they were excluded if it was intentional

The original bug report has several false positives, it flagged cases where ExceptionOccurred == NULL, which aren't issues. Some of these could be changed to ExceptionCheck to avoid create the throwable, that would be more about performance for exception cases so not too interesting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21428#issuecomment-2404860955

From jlahoda at openjdk.org  Thu Oct 10 11:50:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Oct 2024 11:50:00 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v2]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <D8GBIUOfMbHC6-5jyZgnO-tlV1LRfoXRSueLQY-SzCs=.ef354328-b724-4648-a630-bcc8c90da6f1@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 incrementally with one additional commit since the last revision:

  Reflecting review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21431/files
  - new: https://git.openjdk.org/jdk/pull/21431/files/18554144..b7c871da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=00-01

  Stats: 78 lines in 3 files changed: 37 ins; 7 del; 34 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 jlahoda at openjdk.org  Thu Oct 10 11:52:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Oct 2024 11:52:09 GMT
Subject: RFR: 8335989: Implement 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: <Uoc5e3iaQnvSD8Dkycm9UzUKMXxzvdplnSiNL42R07Q=.437b6b3e-647c-484d-bd57-814c5cb45cda@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

Thanks for the comments so far! Here I tried to reflect them:
https://github.com/openjdk/jdk/pull/21431/commits/b7c871dab8357864b532a1f217ed26c3b40d50f4

(For `ClassFileVersionsTest.java`, it seemed unnecessarily complex to position the test cases into specific array positions, so I re-wrote that to use `ArrayList`. My goal was take the focus of the data preparation from how to place the test cases into the correct buckets, and more to the data. I kept pre-sizing of the `ArrayList` to avoid resizing it, although I could see an argument to remove that as well.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21431#issuecomment-2404877409

From lancea at openjdk.org  Thu Oct 10 12:09:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 10 Oct 2024 12:09:10 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <xraZZW8sqoQZ77xsDds5MG0YSFOFhBZsukZW8BNqyDE=.67fb2364-59e7-4981-ab85-0dae74544648@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by lancea (Reviewer).

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2360103431
PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2360105737

From lancea at openjdk.org  Thu Oct 10 12:09:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 10 Oct 2024 12:09:10 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <9dmqP3SbyAaode7z7nyAfExJkZ0jdeafJkdqvW1nF3k=.99d8e4ce-1632-4d74-b1e2-2c4310b098eb@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
 <6Nw5WhhOFHWLbeiAk3uUiuMwz4bRXSMi0qaTnh4GQ34=.5a9d8f6b-405d-4566-87d4-287f9eead997@github.com>
 <9dmqP3SbyAaode7z7nyAfExJkZ0jdeafJkdqvW1nF3k=.99d8e4ce-1632-4d74-b1e2-2c4310b098eb@github.com>
Message-ID: <T6nDjqBNIbDKj4hbhHt9aOABFndPQChTtBfdE38wGKk=.08cf5ab5-a8c3-4c90-8e3a-c80a56227b3b@github.com>

On Thu, 10 Oct 2024 11:40:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > were left out from the commit for the PR but are listed in the JBS issue so it would be great to include the updates as part of this PR or explain why they were excluded if it was intentional
> 
> The original bug report has several false positives, it flagged cases where ExceptionOccurred == NULL, which aren't issues. Some of these could be changed to ExceptionCheck to avoid create the throwable, that would be more about performance for exception cases so not too interesting.

Thanks for the clarification, I missed the comment you added to the bug

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21428#issuecomment-2404909070

From kcr at openjdk.org  Thu Oct 10 12:25:53 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 10 Oct 2024 12:25:53 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal [v3]
In-Reply-To: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
Message-ID: <pyeVVbvjxTMr-WjFeKnjdipXwKyyuJjCx_s_oJ9hdQc=.a1fe3942-3ddd-45f7-9a59-d722c71bf1b5@github.com>

> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
> 
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
> 
> This PR does two things:
> 
> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

Kevin Rushforth 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 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Update javadoc
 - Update copyright years
 - Merge branch 'master' into 8311530-depr-jsobject
 - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test
 - 8311530: Deprecate jdk.jsobject module for removal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20555/files
  - new: https://git.openjdk.org/jdk/pull/20555/files/d2ff851c..7afc50ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=01-02

  Stats: 56203 lines in 908 files changed: 45148 ins; 6116 del; 4939 mod
  Patch: https://git.openjdk.org/jdk/pull/20555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555

PR: https://git.openjdk.org/jdk/pull/20555

From rriggs at openjdk.org  Thu Oct 10 13:52:11 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Oct 2024 13:52:11 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <MrmyaL7Vt13nMPINZRyqq1oVi6y4p1we3TgVNMS4psM=.4fad2ec5-65b2-4be3-af22-1e5d935f9f69@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2360414401

From swen at openjdk.org  Thu Oct 10 13:58:22 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Oct 2024 13:58:22 GMT
Subject: RFR: 8341906: Optimize ClassFile writing BufBuffer
Message-ID: <bqOKlhJoakkfA10HQNiiZFekPZYMTF3eZI6Yt4brp80=.efe1096f-bae4-4941-9532-177f29fef605@github.com>

We made a lot of improvements to merge writes to BufWriter in #21243, and this PR is about doing more of the same.

-------------

Commit messages:
 - merge write

Changes: https://git.openjdk.org/jdk/pull/21437/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341906
  Stats: 154 lines in 13 files changed: 43 ins; 35 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/21437.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21437/head:pull/21437

PR: https://git.openjdk.org/jdk/pull/21437

From liach at openjdk.org  Thu Oct 10 13:58:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Oct 2024 13:58:22 GMT
Subject: RFR: 8341906: Optimize ClassFile writing BufBuffer
In-Reply-To: <bqOKlhJoakkfA10HQNiiZFekPZYMTF3eZI6Yt4brp80=.efe1096f-bae4-4941-9532-177f29fef605@github.com>
References: <bqOKlhJoakkfA10HQNiiZFekPZYMTF3eZI6Yt4brp80=.efe1096f-bae4-4941-9532-177f29fef605@github.com>
Message-ID: <8guDWy1lP5sgyQES1KTAdDpjYtDP1N1H6frQZQQ9gOo=.5c2ac612-c2f4-44f4-b410-f1261537265c@github.com>

On Thu, 10 Oct 2024 01:13:13 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> We made a lot of improvements to merge writes to BufWriter in #21243, and this PR is about doing more of the same.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21437#pullrequestreview-2360291754

From patrick at reini.net  Thu Oct 10 14:13:35 2024
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 10 Oct 2024 16:13:35 +0200
Subject: Potential URLClassLoader bug?
Message-ID: <B722CBFE-BD52-484E-AEC0-FE2EB67E2055@reini.net>

Hi Everybody,

I recently stumbled over a strange behavior within the URLClassLoader under Windows regarding a left open file handle even though everything is handled within try-with-resources blocks.

Here is simple test that passes under Linux & Mac but fails under Windows:


import java.io.*;
import java.net.*;
import java.nio.file.*;
import java.util.jar.*;

public class TestURLClassLoader {

    public static void main(String[] args) throws Exception {
        var testJar = setupJar();
        try (URLClassLoader cl = new URLClassLoader(new URL[] { testJar.toUri().toURL() })) {
            var testResource = cl.getResource("testResource");
            assert testResource != null;
            try (InputStream in = testResource.openStream()) {
                in.transferTo(System.out);
            }
        }
        Files.delete(testJar);
        assert !Files.exists(testJar);
    }

    // setting up a simple .jar file with a single resource as example
    private static Path setupJar() throws IOException {
        var testJar = Paths.get("test.jar");
        try (var out = new FileOutputStream("test.jar");
             var jar = new JarOutputStream(out)) {
            jar.putNextEntry(new JarEntry("testResource"));
            var testData = "some data\n".getBytes();
            jar.write(testData, 0, testData.length);
        }
        assert Files.exists(testJar);
        return testJar;
    }
}

From jai.forums2013 at gmail.com  Thu Oct 10 14:20:40 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 10 Oct 2024 19:50:40 +0530
Subject: Potential URLClassLoader bug?
In-Reply-To: <B722CBFE-BD52-484E-AEC0-FE2EB67E2055@reini.net>
References: <B722CBFE-BD52-484E-AEC0-FE2EB67E2055@reini.net>
Message-ID: <33430757-ef74-4b19-b870-8813ab216be0@gmail.com>

Hello Patrick,

This is a known bug https://bugs.openjdk.org/browse/JDK-8315993 which 
gets triggered when the getResource() gets called on a URL returned 
through the URLClassLoader. We know what's causing this but the fix 
isn't straightforward and is currently under investigation.

-Jaikiran

On 10/10/24 7:43 pm, Patrick Reinhart wrote:
> Hi Everybody,
>
> I recently stumbled over a strange behavior within the URLClassLoader under Windows regarding a left open file handle even though everything is handled within try-with-resources blocks.
>
> Here is simple test that passes under Linux & Mac but fails under Windows:
>
>
> import java.io.*;
> import java.net.*;
> import java.nio.file.*;
> import java.util.jar.*;
>
> public class TestURLClassLoader {
>
>      public static void main(String[] args) throws Exception {
>          var testJar = setupJar();
>          try (URLClassLoader cl = new URLClassLoader(new URL[] { testJar.toUri().toURL() })) {
>              var testResource = cl.getResource("testResource");
>              assert testResource != null;
>              try (InputStream in = testResource.openStream()) {
>                  in.transferTo(System.out);
>              }
>          }
>          Files.delete(testJar);
>          assert !Files.exists(testJar);
>      }
>
>      // setting up a simple .jar file with a single resource as example
>      private static Path setupJar() throws IOException {
>          var testJar = Paths.get("test.jar");
>          try (var out = new FileOutputStream("test.jar");
>               var jar = new JarOutputStream(out)) {
>              jar.putNextEntry(new JarEntry("testResource"));
>              var testData = "some data\n".getBytes();
>              jar.write(testData, 0, testData.length);
>          }
>          assert Files.exists(testJar);
>          return testJar;
>      }
> }

From rsunderbabu at openjdk.org  Thu Oct 10 14:27:08 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Thu, 10 Oct 2024 14:27:08 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support [v2]
In-Reply-To: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
Message-ID: <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>

> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
> 
> Positive Testing:
> tier1,tier2,tier3 - to check stability
> tier5 - to run container tests
> 
> Negative Testing:
> Ran the following groups in hosts where container is not present.
> open/test/hotspot/jtreg/containers/
> open/test/jdk/jdk/internal/platform/docker/
> open/test/jdk/jdk/internal/platform/cgroup/

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21423/files
  - new: https://git.openjdk.org/jdk/pull/21423/files/75001218..3e36b519

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21423&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21423&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21423.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21423/head:pull/21423

PR: https://git.openjdk.org/jdk/pull/21423

From thartmann at openjdk.org  Thu Oct 10 14:28:14 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Oct 2024 14:28:14 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <1hqzRjRFI8wC_c65Nc0rDAni6sxkuSqMdMeGEDZLcXo=.30446bbb-0646-4830-b840-82c0a7d882b6@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
 <HV0EXWSdcCOAoBfxHSoFZMqfBVhMAJj0Fr55gbi8HQo=.914bb5da-62fe-487b-bbcb-a7ece87e1d58@github.com>
 <1hqzRjRFI8wC_c65Nc0rDAni6sxkuSqMdMeGEDZLcXo=.30446bbb-0646-4830-b840-82c0a7d882b6@github.com>
Message-ID: <gxfsCnxgk6WgNY0MsC9n6x81mmgPTTQg2GwKGzAaCvU=.29d9b6f8-91b2-4ceb-a3a7-de34bc52d0c9@github.com>

On Wed, 9 Oct 2024 11:05:15 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> You've probably seen this but the new test is failing IR verification:
>> 
>> 
>> Failed IR Rules (4) of Methods (4)
>> ----------------------------------
>> 1) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMax(double,double)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MaxD.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 2) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMin(double,double)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MinD.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 3) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMax(float,float)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MaxF.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 4) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMin(float,float)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, app...
>
>> You've probably seen this but the new test is failing IR verification:
>> 
>> ```
>> Failed IR Rules (4) of Methods (4)
>> ----------------------------------
>> 1) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMax(double,double)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MaxD.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 2) Method "private static double compiler.intrinsics.math.TestMinMaxInlining.testDoubleMin(double,double)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_D#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MinD.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 3) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMax(float,float)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MAX_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(MaxF.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 = 1 [given]
>>            - No nodes matched!
>> 
>> 4) Method "private static float compiler.intrinsics.math.TestMinMaxInlining.testFloatMin(float,float)" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#MIN_F#_", "1"}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, ...

@galderz The failure happened on x86_64, we (Oracle) don't build/test on 32-bit.

(The 32-bit build is currently broken due to [JDK-8341871](https://bugs.openjdk.org/browse/JDK-8341871))

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2405239334

From thartmann at openjdk.org  Thu Oct 10 14:28:15 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Oct 2024 14:28:15 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v3]
In-Reply-To: <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <i-Tjdy6hmt3rS5YNDiFO2KfdFXVFGvauqyhi16HzN9E=.5b129097-39e2-4ab1-8810-89e11df3a3a2@github.com>
Message-ID: <Ywh4SAGnd9BWFTYu397rWnWiW6T0gKO_rK_m30jgsuM=.712eff81-8c99-4c94-b6e0-bd47fa43d392@github.com>

On Fri, 27 Sep 2024 14:21:57 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 incrementally with three additional commits since the last revision:
> 
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - Revert "Switch movl to movq"
>    
>    This reverts commit a64fcdab7d6c63125c8dfd427ae8a56ff5fa2bb7.
>  - Revert "Fix format of assembly for the movl to movq switch"
>    
>    This reverts commit 13ed87295cff50ff6ef30f909f6dcb35d15af047.

The failure happens with `-XX:UseAVX=0`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2405244635

From liach at openjdk.org  Thu Oct 10 14:32:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Oct 2024 14:32:11 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator [v7]
In-Reply-To: <PjWMbMEk79EurV8Vzd93s4-zhttCu-KcGhilsv2zG5k=.c9861291-ed1a-4d9b-96e1-128db346e3e5@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
 <PjWMbMEk79EurV8Vzd93s4-zhttCu-KcGhilsv2zG5k=.c9861291-ed1a-4d9b-96e1-128db346e3e5@github.com>
Message-ID: <WGWnVLXefYHeqdvodP7PNW4S6Yk-MM9dY8J2H8Ko79o=.9269c4bf-170d-44cd-be5a-1ff72bdb03a1@github.com>

On Wed, 9 Oct 2024 17:40:13 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Reduce code size by combining calls and defining local variables
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_stack_map_gen_202408
>  - use 4 spaces.
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Merge branch 'master' into optim_stack_map_gen_202408
>  - Merge branch 'master' into optim_stack_map_gen_202408
>  - reduce codeSize
>  - reduce codeSize
>  - decStack & stackUnderflow
>  - fix merge error
>  - Merge branch 'master' into optim_stack_map_gen_202408
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/3ab519f1...248f7474

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20756#pullrequestreview-2360568222

From rriggs at openjdk.org  Thu Oct 10 14:35:15 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Oct 2024 14:35:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v8]
In-Reply-To: <rCnMftlndUjue1aR6lqHozSTroP1a6m2IFPIh_Q13Os=.727e6172-27df-4e6a-835c-213b69fabd18@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <rCnMftlndUjue1aR6lqHozSTroP1a6m2IFPIh_Q13Os=.727e6172-27df-4e6a-835c-213b69fabd18@github.com>
Message-ID: <4AEuXCSsbIy3ToONzHppd25IKH79utlYTGdtExAOm9o=.a4559fee-56a5-4eb6-ae5b-a5e93f835159@github.com>

On Thu, 10 Oct 2024 07:32:53 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved wording / formatting of JavaDocs; introduced local length

Changes requested by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2360579082

From swen at openjdk.org  Thu Oct 10 14:35:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Oct 2024 14:35:17 GMT
Subject: Integrated: 8339205: Optimize StackMapGenerator
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <7qkgQ37SKgFkWmjiRxEODgy9dInk0nAodnAc3vklXps=.253c1d7f-7e0d-4c89-8a4a-96962b5c3662@github.com>

On Wed, 28 Aug 2024 22:20:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Reduce code size by combining calls and defining local variables

This pull request has now been integrated.

Changeset: e9327b6e
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9327b6e3c1fcc47ec790fa4e4019f7651a8f912
Stats:     342 lines in 1 file changed: 217 ins; 33 del; 92 mod

8339205: Optimize StackMapGenerator

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20756

From rriggs at openjdk.org  Thu Oct 10 14:35:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Oct 2024 14:35:16 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <-LYYyZN6oZhvXjdStVH3uAPHWC4K4IWn3IwuKtm8oNY=.bd4fbc33-6af3-4fa6-a8ff-bf288903b0f8@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <uTLu1pyxwgLnUnL71gMwGk91qVarhKBB9epudUOHe-w=.80cbda31-cd5c-459c-8d20-11430c6c0bd4@github.com>
 <-LYYyZN6oZhvXjdStVH3uAPHWC4K4IWn3IwuKtm8oNY=.bd4fbc33-6af3-4fa6-a8ff-bf288903b0f8@github.com>
Message-ID: <sJuomRr47A5_nDahM3G82mz5ufJWdvWfn-Ddy6UF0VY=.569dab31-3f79-41f2-a6cc-ef09f8069cfd@github.com>

On Thu, 10 Oct 2024 04:53:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/StringReader.java line 38:
>> 
>>> 36:  * {@code Reader.of(String)} should generally be used in preference to this one,
>>> 37:  * as it supports all of the same operations but it is faster, as it performs no
>>> 38:  * synchronization.
>> 
>> We shouldn't using "release 24" or "supplemented" here. The API note just needs to `Reader.of(CharSequence)` provides a method to read from any CharSequence that may be more efficient than `StringReader`.
>
> I think "release 24" is fine for now as similar text exists in `java.util.Vector`. We can normalize such texts when we implement https://bugs.openjdk.org/browse/JDK-8341736.

Please remove the reference to JDK 24; it will age rapidly and would require extra maintenance later.
The javadoc should focus on the functionality provided.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1795581242

From msheppar at openjdk.org  Thu Oct 10 14:39:16 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 10 Oct 2024 14:39:16 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v11]
In-Reply-To: <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
Message-ID: <Wz28Hat14vBOWupeEtIezTd9ynHlQl_e3obZh9nFgTg=.d3f59db7-05df-46f5-bad0-10b9283b9c42@github.com>

On Mon, 7 Oct 2024 09:00:28 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov 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 16 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into JDK-8339538_DnsClient_nanoTime_And_InfiniteLoop
>  - improve reporting for unrecoverable exceptions
>  - Add comment suggested by Daniel
>  - Track unfulfilled timeouts during UDP queries.
>    Update exceptions handling.
>    Update TCP client to use nano time source.
>  - set min timeout to 0; set max allowed timeout to 2x expected timeout in tests
>  -  set max allowed value for retries to 30
>  - update tests to calculate allowed timeout range (max is updated to 75%), print it and use it for elapsed time check
>  - remove redundant clamp from timeoutLeft calculation
>  - clamp timeout and retries property values
>  - Measure time the caller spent waiting. Simplify timeoutLeft computation
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/270d00f1...c58e34cc

test/jdk/com/sun/jndi/dns/ConfigTests/TimeoutWithEmptyDatagrams.java line 92:

> 90: 
> 91:             // Run a virtual thread that receives client request packets and extracts
> 92:             // sender address from them.

I think the lambda could have been encapsulated in a class abstraction to convey clearly its semantics e.g. DnsRequestSink implementing Runnable and started with Thread.startVirtualThread(new DnsRequestSink(. . .));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1795589879

From msheppar at openjdk.org  Thu Oct 10 14:43:18 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 10 Oct 2024 14:43:18 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v11]
In-Reply-To: <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
Message-ID: <QrOexTbv-9gJEpA_OxY4SKXZ-VWR8VgW4ObBQPaUF9E=.15d248d3-9ae6-48af-8c96-108559df0480@github.com>

On Mon, 7 Oct 2024 09:00:28 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov 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 16 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into JDK-8339538_DnsClient_nanoTime_And_InfiniteLoop
>  - improve reporting for unrecoverable exceptions
>  - Add comment suggested by Daniel
>  - Track unfulfilled timeouts during UDP queries.
>    Update exceptions handling.
>    Update TCP client to use nano time source.
>  - set min timeout to 0; set max allowed timeout to 2x expected timeout in tests
>  -  set max allowed value for retries to 30
>  - update tests to calculate allowed timeout range (max is updated to 75%), print it and use it for elapsed time check
>  - remove redundant clamp from timeoutLeft calculation
>  - clamp timeout and retries property values
>  - Measure time the caller spent waiting. Simplify timeoutLeft computation
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/772b32cc...c58e34cc

test/jdk/com/sun/jndi/dns/ConfigTests/TimeoutWithEmptyDatagrams.java line 114:

> 112:             });
> 113: 
> 114:             // Run a virtual thread that will send an empty packets via server socket

similarly here the lambda functionality encapsulated in a class abstraction EmptyDatagramSender implements Runnable
Thread.startVirtualThread(new EmptyDatagramSender(. . .))

I make this and the above comment as an observation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1795595815

From liach at openjdk.org  Thu Oct 10 14:56:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Oct 2024 14:56:11 GMT
Subject: RFR: 8341136: Optimize StackMapGenerator::trimAndCompress
In-Reply-To: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
References: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
Message-ID: <9gvfE4R3ucaRDyyaGJqe4VddP1c6-zIEzcP8NqIuPPA=.3ddd1e96-6b23-4fc4-9af5-553ed5f5ca39@github.com>

On Fri, 27 Sep 2024 17:05:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce the write operations of trimAndCompress

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21227#pullrequestreview-2360639076

From swen at openjdk.org  Thu Oct 10 14:58:18 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Oct 2024 14:58:18 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName [v3]
In-Reply-To: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
Message-ID: <AMZrjpfoz7Q3avCj_7F78p7Rj-UfxOTpBww9WcEip-o=.4edb2f3d-c7bc-41ae-a9c5-fc5beb07aca3@github.com>

> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

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 five additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - suggestion from @liach
 - stable
 - ReferenceClassDescImpl cache internalName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21373/files
  - new: https://git.openjdk.org/jdk/pull/21373/files/ef54ed21..a83b3d34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=01-02

  Stats: 1697 lines in 37 files changed: 1035 ins; 555 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/21373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21373/head:pull/21373

PR: https://git.openjdk.org/jdk/pull/21373

From rriggs at openjdk.org  Thu Oct 10 15:15:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Oct 2024 15:15:12 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust
In-Reply-To: <O4Qew8_cYY2HnEBpIgAf7jYiYLZI82RTix4H1uDk8YQ=.20f4ae77-7bee-4e2f-be22-33c3b2a93f1a@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <DbUP95GxAnTQ2f-TTF65ooCYlMZsIb8yqTGxkaKsOMc=.7c53fb62-7607-4378-ad5c-f38aa8d1da47@github.com>
 <s-OkA8ZCdhMrg-UuxirJeT8rU7K-av_F5GG0cWu2XmM=.3d0a78e4-b513-4e7c-93cb-726bd3d9dae3@github.com>
 <O4Qew8_cYY2HnEBpIgAf7jYiYLZI82RTix4H1uDk8YQ=.20f4ae77-7bee-4e2f-be22-33c3b2a93f1a@github.com>
Message-ID: <abBnyjgRnZRmGeIbagZ2W7ExT_zuXMwm-53uPcnR9p0=.433a327a-3e1b-4eef-9921-f425dc679e21@github.com>

On Wed, 9 Oct 2024 01:26:53 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Thanks @RogerRiggs for the comments. I increased the diff allowance to absorb any compilation related delays. What would you propose here?
>
> If your objection is primarily on Math.abs, is this ok?
> `
>         long diff = test.toEpochMilli() - expected.toEpochMilli();
>         assertTrue(diff >= 0 && diff < 10_000);  // less than 10 secs
>  `

I don't think there is any way to meaningfully and reliably test the assertion that `Instant.now()` is the using the same clock as `Instant.now(Clock.systemUTC())` given the potential delays in execution of the two statements.
It might be possible to ignore well known delays due to gc or compilation by making sure the code is warmed up by repeating the test until the delta meets the .1 sec limit. If it was really a bug, the test would timeout after a couple of minutes. Putting a while loop around the body of the test would cover that.
I'd leave the code using `abs` alone to avoid exposing some other unanticipated change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1795652647

From swen at openjdk.org  Thu Oct 10 15:16:16 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Oct 2024 15:16:16 GMT
Subject: Integrated: 8341136: Optimize StackMapGenerator::trimAndCompress
In-Reply-To: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
References: <tNBAaxzrp_rk_RyPDpl9FqJZUMMVU64XuhoZtwJHjDc=.12b79d01-6406-44b0-b79f-c449cf811dc7@github.com>
Message-ID: <tLlKTKOCxKdNY9fnpyqFBp6bJoZnrHBTUdepRlc4p2w=.583fcf6d-c85a-423b-8e01-027b746f18a9@github.com>

On Fri, 27 Sep 2024 17:05:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce the write operations of trimAndCompress

This pull request has now been integrated.

Changeset: 6e013845
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e0138450ab4b0af917cbf61701b0d1d17eeaa44
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8341136: Optimize StackMapGenerator::trimAndCompress

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21227

From swen at openjdk.org  Thu Oct 10 15:26:48 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 10 Oct 2024 15:26:48 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName [v4]
In-Reply-To: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
Message-ID: <roubu1gvtuj7m_8rtiHZh1P95lubERiWA_JdnUKVwz8=.a568bd92-5c4f-4e68-b2bc-89747c5a6079@github.com>

> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

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 six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - suggestion from @liach
 - stable
 - ReferenceClassDescImpl cache internalName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21373/files
  - new: https://git.openjdk.org/jdk/pull/21373/files/a83b3d34..8da27b0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=02-03

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21373/head:pull/21373

PR: https://git.openjdk.org/jdk/pull/21373

From sgehwolf at openjdk.org  Thu Oct 10 15:41:14 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Oct 2024 15:41:14 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support [v2]
In-Reply-To: <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
 <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
Message-ID: <cbeqn52d_TPX-3pwqn4WKrQXVXY_jUsvyfqVAEJxkm8=.b32d5a4f-2de5-4a83-a68b-2cd9cb434285@github.com>

On Thu, 10 Oct 2024 14:27:08 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
>> 
>> Positive Testing:
>> tier1,tier2,tier3 - to check stability
>> tier5 - to run container tests
>> 
>> Negative Testing:
>> Ran the following groups in hosts where container is not present.
>> open/test/hotspot/jtreg/containers/
>> open/test/jdk/jdk/internal/platform/docker/
>> open/test/jdk/jdk/internal/platform/cgroup/
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comment

Marked as reviewed by sgehwolf (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21423#pullrequestreview-2360759661

From msheppar at openjdk.org  Thu Oct 10 15:41:18 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 10 Oct 2024 15:41:18 GMT
Subject: RFR: 8339538: Wrong timeout computations in DnsClient [v11]
In-Reply-To: <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
 <Ejq1_06iuvm-V6sSfjWuDcwqXDtQLhod7fE1rTSnfb4=.8fa6c775-fdcc-4748-a068-a31a5cc52e0f@github.com>
Message-ID: <KAubTFJc2OCXwGM30eRXLiBqyTEOwuM0KrVhRcbbk4w=.ba8e6fa8-d799-4eba-8860-20583efd6c23@github.com>

On Mon, 7 Oct 2024 09:00:28 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
>> 
>> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
>> 
>> - The `DnsClient.blockingReceive` has been updated:
>>     - to detect if any data is received
>>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
>> 
>> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
>> 
>> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).
>
> Aleksei Efimov 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 16 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin' into JDK-8339538_DnsClient_nanoTime_And_InfiniteLoop
>  - improve reporting for unrecoverable exceptions
>  - Add comment suggested by Daniel
>  - Track unfulfilled timeouts during UDP queries.
>    Update exceptions handling.
>    Update TCP client to use nano time source.
>  - set min timeout to 0; set max allowed timeout to 2x expected timeout in tests
>  -  set max allowed value for retries to 30
>  - update tests to calculate allowed timeout range (max is updated to 75%), print it and use it for elapsed time check
>  - remove redundant clamp from timeoutLeft calculation
>  - clamp timeout and retries property values
>  - Measure time the caller spent waiting. Simplify timeoutLeft computation
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/860af487...c58e34cc

good job ... thanks for considering my feedback

-------------

Marked as reviewed by msheppar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20892#pullrequestreview-2360760459

From aefimov at openjdk.org  Thu Oct 10 15:59:19 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 10 Oct 2024 15:59:19 GMT
Subject: Integrated: 8339538: Wrong timeout computations in DnsClient
In-Reply-To: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
References: <fTdrI1qEVKOJktPEnuEOlTP-heFgQx-Hn-udnfiIzeo=.8c4bf0c4-027e-4f5a-a394-0270d51adbcc@github.com>
Message-ID: <3ccYAv2T43qSQkVgo-WKGTp0hsOIEe_ZRFD4sMLN0pY=.24dc6737-3412-4bce-a209-9185572c44f7@github.com>

On Fri, 6 Sep 2024 16:28:36 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> This PR proposes the following changes to address wrong timeout computations in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano) clock. The existing `Timeout` test has also been updated to use the nano clock to measure observed timeout value.
> 
> - The left timeout computation has been fixed to decrease the timeout value during each retry attempt. A new test, `TimeoutWithEmptyDatagrams`, has been added to test it.
> 
> - The `DnsClient.blockingReceive` has been updated:
>     - to detect if any data is received
>     - to avoid contention with `Selector.close()` that could be called by a cleaner thread
> 
> - The expected timeout calculation in the `Timeout` test has been updated to take into account the minimum retry timeout (50ms). Additionally, the max allowed difference between the observed timeout and the expected one has been increased from 50% to 67%. Taking into account 50 ms retry timeout decrease the maximum allowed difference is effectively set to 61%. This change is expected to improve the stability of the `Timeout` test which has been seen to fail [intermittentlly](https://bugs.openjdk.org/browse/JDK-8220213). If no objections, I'm planning to close [JDK-8220213](https://bugs.openjdk.org/browse/JDK-8220213) as duplicate of this one.
> 
> JNDI/DNS jtreg tests has been executed multiple times (500+) to check if the new and the modified tests are stable. No failures been observed (so far?).

This pull request has now been integrated.

Changeset: 4beb7719
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4beb77192f54f27183285400d7cae7528df64e43
Stats:     332 lines in 4 files changed: 280 ins; 8 del; 44 mod

8339538: Wrong timeout computations in DnsClient
8220213: com/sun/jndi/dns/ConfigTests/Timeout.java failed intermittent

Reviewed-by: dfuchs, msheppar, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/20892

From rgiulietti at openjdk.org  Thu Oct 10 16:10:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Oct 2024 16:10:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]
In-Reply-To: <KvAPTu7Unz7aKs_-fkq5Fw3UF1Ny6puzXr4W3RS5I1I=.6f1c5100-0871-4c77-b9f9-fd72e8fa8362@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <KEtzPHSUSVK69AMAXnN1QnAJCMCFdwZZYs_Y9I3nIlE=.dcd296f2-5e7c-4c6d-aa46-84061344ad90@github.com>
 <_d8rGaRUDWNiHwTXLrtVaeQC6Hd1uxGgytyIoBPXvvI=.5e58be70-1256-4abe-bdb3-b22b47537d7e@github.com>
 <oM859X2ihTfZbmAZHGAG_EGkQzzI7tdNqpbWaMZNFiE=.7925727a-5fa7-4365-a71f-6a8b9c3f30bf@github.com>
 <gY0zQS3FveVl__RRGLKjii0rxQRhfZ-_uT3f-BFgd5Y=.80520445-c6a3-4b17-8c9a-a07801c64ce8@github.com>
 <5BgR8_BEcqXsRoga-v2fHJyD2Q4Ychr0G59laPpyy54=.d72daff5-c9e9-4e3d-8360-99fe7b5a9104@github.com>
 <MEjhDsybJTxg8MVvlGAupJwG-fiyIpChN8cycUUnWa4=.971012a3-81ea-41c4-8846-9165efa4f533@github.com>
 <AzN40Wt7oA73yUd5ERHEOZRUnjl_k8qZURFBAR8ySNo=.540d8d16-7981-4e75-ae41-c72314d15372@github.com>
 <-7kP37mWz37S1freWfc6O_8qUzsN_ZR4DSCPGEF-aec=.94d03d62-2195-46c9-a195-21dec2947042@github.com>
 <OkSV9SwcnsjnRq2AQNeJu8QDE5AJ-ob-O3caQMm_ssI=.fca5e2b5-a881-4f5c-884b-f9e8db757518@github.com>
 <4DreQKpVzuR-JmKhu0KihHd14E0hEPVGYnr
 wS32Be_w=.a2d67a84-b229-4e36-addb-be7a6200260e@github.com>
 <Npfgjp25YB-r7_6bbvS6-g7t90W-mmgnB7XHuiVMHpo=.517b022a-889c-4934-8ef1-169f3bb34ead@github.com>
 <ChtAT1jMr22DeSL12eydRAEOxPKModbLNypygtrQqXk=.188b0bb8-0a0f-4769-ae7d-8a83f225ece6@github.com>
 <sXsw9vj2xMjwLEKhXqC-GfghsPMzl-29wZ1vcKcS3LM=.abb3a026-c3e1-404f-ae07-bbd0a90268dd@github.com>
 <yGMZiQ0haVFDN9jk8C4STSiuta8XUjneQPNMxjEzjI8=.33653d75-bfa9-40bd-8969-044cb77ed045@github.com>
 <_dWj2Xjhie38tbKTRAkwR4tr0OzvVCkexvE1QKVHDdA=.843346e1-b3a1-46b2-809c-c445d96bb98b@github.com>
 <Ugb5Xc_P_l6LM3T41jyyP2nvSNKgJvtviEGolapXdj0=.79e11c44-072f-4b27-a126-b30b516a0efd@github.com>
 <P1nGE3jj5c8JapHF2OxomVAXtUZ5LN8s1nnHznZbDwE=.3a7ca1bb-3649-4c9e-94c2-46b5b13d1d23@github.com>
 <-fVHOUrkMAFWjRzNP83WEBEZ0gOdnjDgGi02awcd9sc=.cbe63631-2540-4fa5-a924-be0fc76b3f9d@github.com>
 <llnanXif4pDPZ1PRiP-rY8MgFWQNeQPnQjWX56RvgZY=.e115e1d8-2fb8-4d19-9167-89ae368d34d8@github.com>
 <KvAPTu7Unz7aKs_-fkq5Fw3UF1Ny6puzXr4W3RS5I1I=.6f1c5100-0871-4c77-b9f9-fd72e8fa8362@
 github.com>
Message-ID: <VcHAmY_rfiBDs-QQVU9rXrMGT9g4_5c364y9ix7G1RI=.2f1f5821-60f6-4561-a123-0e6d7c47994e@github.com>

On Thu, 10 Oct 2024 07:32:15 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The class Javadoc mentions, in at least two places, that the two's complement representation conceptually has an infinite number of leading virtual sign bits.
>> Once this point is clear, IMO the method's own Javadoc is then clear in turn. Maybe it could be improved as in "the bits that differ _in value_ from its sign bit". (Changing the spec requires another process and another, separate issue, but it can be done if needed.)
>
> @rgiulietti So it must have been my limitation, but I didn't realize it, even though I knew that there are virtually infinite sign bits...

Turns out that the table maintained by `expandBigIntegerTenPowers()` never stores more than 19 * 16 = 304 entries, totaling some 20 kB of resident storage in the worst case. Nor is the iterative multiplication by 10 a problem for such a small cache.

I tried to reduce the size of the `FIVE_TO_2_TO` array to a length of 16 + 1 instead of 20. The size is then around 80 kB, about the same order of magnitude as for the cache above.
The impact on performance is barely noticeable on large number of trailing zeros, with a slowdown of about 5%.


Benchmark                            Mode  Cnt          Score         Error  Units
BigDecimalStripTrailingZeros.testL   avgt   15    2733190.412 ?   51858.195  ns/op
BigDecimalStripTrailingZeros.testM   avgt   15       9262.737 ?      18.105  ns/op
BigDecimalStripTrailingZeros.testS   avgt   15        153.792 ?       1.234  ns/op
BigDecimalStripTrailingZeros.testXL  avgt   15  466326466.667 ? 6076783.818  ns/op
BigDecimalStripTrailingZeros.testXS  avgt   15         21.336 ?       0.058  ns/op
Finished running test 'micro:java.math.BigDecimalStripTrailingZeros'

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1795735351

From naoto at openjdk.org  Thu Oct 10 16:14:19 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Oct 2024 16:14:19 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <Oyzx743ZfHVD8v5ljUfSaMZDPbXtABeKWwTR1bNUKzg=.f91fe553-0810-4855-97f3-dd4f13beeb6a@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21428#pullrequestreview-2360837181

From naoto at openjdk.org  Thu Oct 10 16:16:15 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Oct 2024 16:16:15 GMT
Subject: RFR: 8341791: Fix ExceptionOccurred in java.prefs
In-Reply-To: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
References: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
Message-ID: <eYcH1rQJT45ZVRw3njxJ8MIpgO5BKehDGTyMiS5ogS4=.95d2769c-fcf1-48cd-bc58-4d69ea670084@github.com>

On Wed, 9 Oct 2024 17:28:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.prefs_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21427#pullrequestreview-2360842161

From rgiulietti at openjdk.org  Thu Oct 10 16:16:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Oct 2024 16:16:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
Message-ID: <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>

On Wed, 9 Oct 2024 15:18:15 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Store log5(2) in BigDecimal

src/java.base/share/classes/java/math/BigDecimal.java line 5260:

> 5258:         // a multiple of 10^n must be a multiple of 2^n
> 5259:         int powsOf2 = intVal.getLowestSetBit();
> 5260:         long remainingZeros = Math.min(scale - preferredScale, powsOf2);

Please document the semantics of this variable, preferably in maths, like inequalities, etc.

src/java.base/share/classes/java/math/BigDecimal.java line 5270:

> 5268:         intVal = intVal.shiftRight(powsOf2); // remove powers of 2
> 5269:         // maxPowsOf5 == ceil(log5(intVal)) roughly
> 5270:         long maxPowsOf5 = (long) Math.ceil(intVal.bitLength() * LOG_5_OF_2);

Please document the meaning of this variable in form of inequalities w.r.t. `intVal`.
Also, shouldn't it be named `maxExpOf5` or similar? It's an exponent, after all.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1795743150
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1795743514

From aph at openjdk.org  Thu Oct 10 16:21:20 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 16:21:20 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
Message-ID: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>

The fourth preview of scoped values.

-------------

Commit messages:
 - Scoped Values API changes
 - Scoped Values API changes
 - Scoped Values API changes

Changes: https://git.openjdk.org/jdk/pull/21456/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341903
  Stats: 159 lines in 5 files changed: 5 ins; 73 del; 81 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 jbhateja at openjdk.org  Thu Oct 10 16:27:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 10 Oct 2024 16:27:25 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v23]
In-Reply-To: <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>
Message-ID: <cnD4QSr1n6ntVhACh9F9j3OF7_VB8wi7EFD-ZrSwYjE=.fc684c7f-b72c-4738-a5a8-7dda07910f57@github.com>

On Tue, 8 Oct 2024 19:25:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge branch 'JDK-8338201' of http://github.com/jatin-bhateja/jdk into JDK-8338201
>  - Update VectorMath.java
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Typographical error fixups
>  - Doc fixups
>  - Typographic error
>  - Merge stashing and re-commit
>  - Tuning extra spaces.
>  - Tests for newly added VectorMath.* operations
>  - Test cleanups.
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/7312eea3...ce76c3e5

Hi @vnkozlov , Can you kindly run this through your test infrastructure. We have two review approvals for Java and x86 backend code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2405554905

From duke at openjdk.org  Thu Oct 10 16:31:50 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 16:31:50 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v9]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <NQHqqmOfhEdPDhiciy5vbm-PtwML48A0D9BC9_VOB2g=.1ae331fa-885d-4199-9c5c-a61fe3f6e045@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Improved wording: 'Reader.of(CharSequence) provides a method to read from any CharSequence that may be more efficient than StringReader'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/b0ff5a78..f7ab51f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=07-08

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From duke at openjdk.org  Thu Oct 10 16:31:50 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 16:31:50 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <XKRrT3nYYyFP7jTwmhjmtqvTW8WuOjrIv9cBpsP55F0=.2076f5bc-cafd-4073-a9c4-130b8ee337eb@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <gAD9PeIH72LeZMvv1_PCMzr4g53-f-eNM2fbM-gMoVE=.9d2ee544-6b12-4ac6-83c6-02aa78fb81df@github.com>
 <GnP8HzGl4mrD7ElrsjTssc3ewI-r68aptWm0b8Txi08=.67c9d101-e6c2-4997-a0ac-2fc0d4e8c37f@github.com>
 <XKRrT3nYYyFP7jTwmhjmtqvTW8WuOjrIv9cBpsP55F0=.2076f5bc-cafd-4073-a9c4-130b8ee337eb@github.com>
Message-ID: <sGSaIoQBX-Fmej-Pz4Wk_ngfILxvA2T2w3cG3uvcRhc=.f64c06ef-0afd-4cdb-8bd0-320f921f535e@github.com>

On Thu, 10 Oct 2024 05:47:26 GMT, Markus KARG <duke at openjdk.org> wrote:

>> Currently uncontested locks have a performance regression after the removal of biased locking: A similar example with `StringBuffer` is available in #19513.
>
> I do not have any personal preferences here. The text was paraphrased from `StringBuilder`, so it seems it was acceptable in the past. If a different text is wanted, I would kindly ask all participants in this discussion to agree upon one common proposal, as I personally am fine with the text as-is.

Done; replaced by Alan's proposal: "Reader.of(CharSequence) provides a method to read from any CharSequence that may be more efficient than StringReader"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1795762880

From duke at openjdk.org  Thu Oct 10 16:31:50 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 16:31:50 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <sJuomRr47A5_nDahM3G82mz5ufJWdvWfn-Ddy6UF0VY=.569dab31-3f79-41f2-a6cc-ef09f8069cfd@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <uTLu1pyxwgLnUnL71gMwGk91qVarhKBB9epudUOHe-w=.80cbda31-cd5c-459c-8d20-11430c6c0bd4@github.com>
 <-LYYyZN6oZhvXjdStVH3uAPHWC4K4IWn3IwuKtm8oNY=.bd4fbc33-6af3-4fa6-a8ff-bf288903b0f8@github.com>
 <sJuomRr47A5_nDahM3G82mz5ufJWdvWfn-Ddy6UF0VY=.569dab31-3f79-41f2-a6cc-ef09f8069cfd@github.com>
Message-ID: <2t1ppUUSnzGkxuQ8V1upMrDeIiOc6HHaqkPEM-5OXhs=.f1e632f4-57df-4288-b68e-d383bf9fcda1@github.com>

On Thu, 10 Oct 2024 14:32:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I think "release 24" is fine for now as similar text exists in `java.util.Vector`. We can normalize such texts when we implement https://bugs.openjdk.org/browse/JDK-8341736.
>
> Please remove the reference to JDK 24; it will age rapidly and would require extra maintenance later.
> The javadoc should focus on the functionality provided.

Done; replaced by Alan's proposal: "Reader.of(CharSequence) provides a method to read from any CharSequence that may be more efficient than StringReader"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1795763919

From aph at openjdk.org  Thu Oct 10 16:37:24 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 10 Oct 2024 16:37:24 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v2]
In-Reply-To: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
Message-ID: <LwMAE0nlGW79Os0pqGCDMBsukXRsHje7gBNE7A7kh8g=.52bf0745-2a10-4fa2-b431-2f6977ae6649@github.com>

> The fourth preview of scoped values.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Fix javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21456/files
  - new: https://git.openjdk.org/jdk/pull/21456/files/77e055b6..0d178006

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 jrose at openjdk.org  Thu Oct 10 16:52:15 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 10 Oct 2024 16:52:15 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v7]
In-Reply-To: <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>
Message-ID: <R_CQkdM_q-fZH0KPcgxMpijaI8Dt_6-3hwcV95ubbY0=.82abc052-b494-4b8d-9ca7-e461c6e3d964@github.com>

On Wed, 2 Oct 2024 01:06:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/2cf0ce42...1b067b7b

Here is a more extensive example of using stable variables to split a single class initializer into multiple phases:

https://cr.openjdk.org/~jrose/leyden/SplitInitsWithStableFields.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21049#issuecomment-2405604237

From alanb at openjdk.org  Thu Oct 10 17:04:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 17:04:15 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v2]
In-Reply-To: <LwMAE0nlGW79Os0pqGCDMBsukXRsHje7gBNE7A7kh8g=.52bf0745-2a10-4fa2-b431-2f6977ae6649@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
 <LwMAE0nlGW79Os0pqGCDMBsukXRsHje7gBNE7A7kh8g=.52bf0745-2a10-4fa2-b431-2f6977ae6649@github.com>
Message-ID: <CY34YcAPSwgzXjpMtjlGOLsT1Pmw0XoJlUiXwZpBc0A=.0c896047-9e70-4b61-a72a-dbff2fa3de74@github.com>

On Thu, 10 Oct 2024 16:37:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The fourth preview of scoped values.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix javadoc

@theRealAph The update to src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java needs to be included too. Also test/jdk/jdk/internal/misc/ThreadFlock/WithScopedValue.java is updated in the loom repo, need to include that change too.

src/java.base/share/classes/java/lang/ScopedValue.java line 163:

> 161:  *         // @link substring="open" target="StructuredTaskScope#open()" :
> 162:  *         try (var scope = StructuredTaskScope.open()) {
> 163:  *

You'll need to revert this line as that is the updated STS API so will be update with its next JEP.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21456#issuecomment-2405621865
PR Review Comment: https://git.openjdk.org/jdk/pull/21456#discussion_r1795812628

From alanb at openjdk.org  Thu Oct 10 17:14:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Oct 2024 17:14:11 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v2]
In-Reply-To: <CY34YcAPSwgzXjpMtjlGOLsT1Pmw0XoJlUiXwZpBc0A=.0c896047-9e70-4b61-a72a-dbff2fa3de74@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
 <LwMAE0nlGW79Os0pqGCDMBsukXRsHje7gBNE7A7kh8g=.52bf0745-2a10-4fa2-b431-2f6977ae6649@github.com>
 <CY34YcAPSwgzXjpMtjlGOLsT1Pmw0XoJlUiXwZpBc0A=.0c896047-9e70-4b61-a72a-dbff2fa3de74@github.com>
Message-ID: <NDcSkqx97gHyoniX_8cJ2o5LMq8f-c7B2XUx866_bMQ=.64f1da56-a310-4393-961d-f40c7da0c38a@github.com>

On Thu, 10 Oct 2024 17:02:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix javadoc
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 163:
> 
>> 161:  *         // @link substring="open" target="StructuredTaskScope#open()" :
>> 162:  *         try (var scope = StructuredTaskScope.open()) {
>> 163:  *
> 
> You'll need to revert this line as that is the updated STS API so will be update with its next JEP.

Make sure to run jdk:tier1 and jdk:tier2 as that will run the tests that use this API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21456#discussion_r1795823325

From jlu at openjdk.org  Thu Oct 10 17:36:17 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 17:36:17 GMT
Subject: RFR: 8341791: Fix ExceptionOccurred in java.prefs
In-Reply-To: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
References: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
Message-ID: <6IEa1JGo3PWKKQ_aTmla4B19snCtEgqH25WVEoo5Cxk=.bc6bba2c-0c9e-460e-bf95-83f67f90535c@github.com>

On Wed, 9 Oct 2024 17:28:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.prefs_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21427#issuecomment-2405681582

From jlu at openjdk.org  Thu Oct 10 17:36:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 17:36:18 GMT
Subject: RFR: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <y5ySdUaHq077MHmFPHWwYzgwKgIA1Ajs90h2TpYOMps=.cb3c434c-f069-4c8b-84d4-b862ede962af@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21428#issuecomment-2405681457

From jlu at openjdk.org  Thu Oct 10 17:36:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 17:36:18 GMT
Subject: Integrated: 8341791: Fix ExceptionOccurred in java.prefs
In-Reply-To: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
References: <ljNfUeFGmlq3b9x-VC2N7SLXNVodWQyIwxVt4oZjsOk=.33fd3dd8-e905-4d39-99e4-5dac0b7cf4ab@github.com>
Message-ID: <-UaeMH2Hrejb_zymB0O6P4Nk1Yn9ChcWTY8K2bdQ6e0=.11f03367-401a-4c96-9899-a5a045356e30@github.com>

On Wed, 9 Oct 2024 17:28:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.prefs_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

This pull request has now been integrated.

Changeset: a5cad0ee
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5cad0ee1e86285b7d2561dfce37f2b22067c9e6
Stats:     9 lines in 1 file changed: 0 ins; 0 del; 9 mod

8341791: Fix ExceptionOccurred in java.prefs

Reviewed-by: bpb, jpai, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21427

From jlu at openjdk.org  Thu Oct 10 17:36:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 17:36:19 GMT
Subject: Integrated: 8341789: Fix ExceptionOccurred in java.base
In-Reply-To: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
References: <4TdMxCEKdWHr9pblEUTraos7bSgC-vhuZ6bZMLVdLzE=.2286bbf6-b23d-4f5b-a4d2-ddf53a8b809f@github.com>
Message-ID: <1JyoGUOO4Ps9U46odRSiK9XlfgLMs7hpaNyXQY90W44=.c59cf882-36d8-4663-b728-6b6327a7ef86@github.com>

On Wed, 9 Oct 2024 17:28:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _java.base_.
> 
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

This pull request has now been integrated.

Changeset: 7eb55357
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7eb55357ab169c21dd5d0ed1738155e794e5faaf
Stats:     34 lines in 10 files changed: 0 ins; 0 del; 34 mod

8341789: Fix ExceptionOccurred in java.base

Reviewed-by: bpb, jpai, dfuchs, lancea, rriggs, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21428

From weijun at openjdk.org  Thu Oct 10 17:40:18 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 10 Oct 2024 17:40:18 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v2]
In-Reply-To: <LwMAE0nlGW79Os0pqGCDMBsukXRsHje7gBNE7A7kh8g=.52bf0745-2a10-4fa2-b431-2f6977ae6649@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
 <LwMAE0nlGW79Os0pqGCDMBsukXRsHje7gBNE7A7kh8g=.52bf0745-2a10-4fa2-b431-2f6977ae6649@github.com>
Message-ID: <emcfdiELle3saJWMmlebHuJqZeW-SHdBFghwFLhgnjc=.c474a86f-719d-45dd-a284-22e2d16dc6ce@github.com>

On Thu, 10 Oct 2024 16:37:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The fourth preview of scoped values.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix javadoc

The one line change in `Subject.java` is fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21456#issuecomment-2405691411

From jlahoda at openjdk.org  Thu Oct 10 17:54:51 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Oct 2024 17:54:51 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
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: <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@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` launcher, 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 launcher 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:
> 
> $ java
> openjdk 24-internal 2025-03-18
> 
> Usage: java [options...] <what to execute> [arguments to main method...]
> 
> Where <what to execute> is one of:
>   <MainClass>                to execute the main method of a compiled class
>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>   -m <module>[/<MainClass>]  to execute the main class of a module
>   <SourceFile.java>          to compile and execute a single-file program
> 
> Where key options include:
>   --class-path <class path>
>       a : separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a : separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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:

  Adjusting the concise help based on review suggestions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21411/files
  - new: https://git.openjdk.org/jdk/pull/21411/files/72939030..0a6c17f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=00-01

  Stats: 8 lines in 1 file 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  Thu Oct 10 17:59:12 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Oct 2024 17:59:12 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
Message-ID: <73ADa-rbdWp23yI2WMB2ERGYaSo6s_0MfAFA3HZ-UE0=.a2c0abd6-19a4-42a7-9f05-646f18a93101@github.com>

On Thu, 10 Oct 2024 17:54:51 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` launcher, 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 launcher 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:
>> 
>> $ java
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [options...] <what to execute> [arguments to main method...]
>> 
>> Where <what to execute> is one of:
>>   <MainClass>                to execute the main method of a compiled class
>>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>>   -m <module>[/<MainClass>]  to execute the main class of a module
>>   <SourceFile.java>          to compile and execute a single-file program
>> 
>> Where key options include:
>>   --class-path <class path>
>>       a : separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a : separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help based on review suggestions.

I've adjusted the concise help to:

$ java
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 <jar-file.jar>        to execute the main class in a JAR archive
  -m <module>[/<MainClass>]  to execute the main class of a module
  <SourceFile.java>          to compile and execute a single-file program

Where key java options include:
  --class-path <class path>
      a ":"-separated list of directories and JAR archives to search for class files
  --module-path <module path>
      a ":"-separated list of directories and JAR archives to search for modules

For more details about this launcher:   java --help
For an interactive Java environment:    jshell


@magicus' suggestion with `<application>` seemed good, so I used that. Regarding the `: separated list` problem, chose `":"-separated list`, as that is still reasonably easy to do.

Regarding "launcher" - sorry, but I don't think this is meant to refer to launcher architecture or to multiple launchers. `java` is a launcher for Java programs, and (to me, at least) "For more details about this launcher:   java --help" does not seem to require any very special knowledge - it is simply about listing the options for this specific launcher.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2405723643

From duke at openjdk.org  Thu Oct 10 18:09:12 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Thu, 10 Oct 2024 18:09:12 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
Message-ID: <PPPSegDOvh9niNnGdwMZlPlZbgOKPgQCCZ8kgPCkO34=.91296cad-efe3-46c6-8059-941fca37558a@github.com>

On Thu, 10 Oct 2024 17:54:51 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` launcher, 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 launcher 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:
>> 
>> $ java
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [options...] <what to execute> [arguments to main method...]
>> 
>> Where <what to execute> is one of:
>>   <MainClass>                to execute the main method of a compiled class
>>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>>   -m <module>[/<MainClass>]  to execute the main class of a module
>>   <SourceFile.java>          to compile and execute a single-file program
>> 
>> Where key options include:
>>   --class-path <class path>
>>       a : separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a : separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help based on review suggestions.

I still love this :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2405742233

From eirbjo at openjdk.org  Thu Oct 10 18:38:11 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Oct 2024 18:38:11 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <73ADa-rbdWp23yI2WMB2ERGYaSo6s_0MfAFA3HZ-UE0=.a2c0abd6-19a4-42a7-9f05-646f18a93101@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
 <73ADa-rbdWp23yI2WMB2ERGYaSo6s_0MfAFA3HZ-UE0=.a2c0abd6-19a4-42a7-9f05-646f18a93101@github.com>
Message-ID: <Qt6tToQNc-IBDFT3o4KNyoaXKOLpnwHCudSxZI1WQI0=.18bfb4af-632c-4ab8-a190-62b0f021f51c@github.com>

On Thu, 10 Oct 2024 17:56:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I've adjusted the concise help to:
> 
> ```
> $ java
> openjdk 24-internal 2025-03-18
> 
> Usage: java [java options...] <application> [application arguments...]
> ```

How about just `[arguments...]` instead of `[application arguments...]`?

It's shorter, in this context it is pretty clear that it is arguments to the application and it removes any confusion between `<application>`  and `application`.  (If you need to explain it you could add a "And [arguments..] is a list of inputs strings to the application" or something along those lines)

> ```
> Where <application> is one of:
>   <MainClass>                to execute the main method of a compiled class
>   -jar <jar-file.jar>        to execute the main class in a JAR archive
> ```

Nit: I would consider using "main class _of_ a JAR archive" here for consistency. Yes, the main class is a binary file stored as an entry _in_ a JAR archive. But so is the main class _of_ a module. The key thing here is that the Main-Class attribute designates it as the "main class" of the JAR archive. (But then I'm not a native English speaker..:)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2405790480

From liach at openjdk.org  Thu Oct 10 19:17:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Oct 2024 19:17:24 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
Message-ID: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>

Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.

Notes:
1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.

-------------

Commit messages:
 - 8317356: Test ClassFile API if it deals with nulls correctly across the whole API

Changes: https://git.openjdk.org/jdk/pull/21458/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21458&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317356
  Stats: 1202 lines in 38 files changed: 1085 ins; 14 del; 103 mod
  Patch: https://git.openjdk.org/jdk/pull/21458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21458/head:pull/21458

PR: https://git.openjdk.org/jdk/pull/21458

From rsunderbabu at openjdk.org  Thu Oct 10 19:27:12 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Thu, 10 Oct 2024 19:27:12 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust
In-Reply-To: <abBnyjgRnZRmGeIbagZ2W7ExT_zuXMwm-53uPcnR9p0=.433a327a-3e1b-4eef-9921-f425dc679e21@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <DbUP95GxAnTQ2f-TTF65ooCYlMZsIb8yqTGxkaKsOMc=.7c53fb62-7607-4378-ad5c-f38aa8d1da47@github.com>
 <s-OkA8ZCdhMrg-UuxirJeT8rU7K-av_F5GG0cWu2XmM=.3d0a78e4-b513-4e7c-93cb-726bd3d9dae3@github.com>
 <O4Qew8_cYY2HnEBpIgAf7jYiYLZI82RTix4H1uDk8YQ=.20f4ae77-7bee-4e2f-be22-33c3b2a93f1a@github.com>
 <abBnyjgRnZRmGeIbagZ2W7ExT_zuXMwm-53uPcnR9p0=.433a327a-3e1b-4eef-9921-f425dc679e21@github.com>
Message-ID: <I0Bs58nqtAUq4DXlpdohkQJiY5XNoYgxLWuWjn72sC4=.46606e37-54a1-4c07-a8af-6a46a825c209@github.com>

On Thu, 10 Oct 2024 15:12:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> If your objection is primarily on Math.abs, is this ok?
>> `
>>         long diff = test.toEpochMilli() - expected.toEpochMilli();
>>         assertTrue(diff >= 0 && diff < 10_000);  // less than 10 secs
>>  `
>
> I don't think there is any way to meaningfully and reliably test the assertion that `Instant.now()` is the using the same clock as `Instant.now(Clock.systemUTC())` given the potential delays in execution of the two statements.
> It might be possible to ignore well known delays due to gc or compilation by making sure the code is warmed up by repeating the test until the delta meets the .1 sec limit. If it was really a bug, the test would timeout after a couple of minutes. Putting a while loop around the body of the test would cover that.
> I'd leave the code using `abs` alone to avoid exposing some other unanticipated change.

I am keeping the timeout as 60 seconds. is this ok?

    @Test(timeOut=60000)
    public void now() {
        Instant expected, test;
        long diff;
        do {
            expected = Instant.now(Clock.systemUTC());
            test = Instant.now();
            diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
        } while( diff > 100 ); // retry if more than 0.1 sec
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1795975497

From rriggs at openjdk.org  Thu Oct 10 19:46:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 10 Oct 2024 19:46:12 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust
In-Reply-To: <I0Bs58nqtAUq4DXlpdohkQJiY5XNoYgxLWuWjn72sC4=.46606e37-54a1-4c07-a8af-6a46a825c209@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <DbUP95GxAnTQ2f-TTF65ooCYlMZsIb8yqTGxkaKsOMc=.7c53fb62-7607-4378-ad5c-f38aa8d1da47@github.com>
 <s-OkA8ZCdhMrg-UuxirJeT8rU7K-av_F5GG0cWu2XmM=.3d0a78e4-b513-4e7c-93cb-726bd3d9dae3@github.com>
 <O4Qew8_cYY2HnEBpIgAf7jYiYLZI82RTix4H1uDk8YQ=.20f4ae77-7bee-4e2f-be22-33c3b2a93f1a@github.com>
 <abBnyjgRnZRmGeIbagZ2W7ExT_zuXMwm-53uPcnR9p0=.433a327a-3e1b-4eef-9921-f425dc679e21@github.com>
 <I0Bs58nqtAUq4DXlpdohkQJiY5XNoYgxLWuWjn72sC4=.46606e37-54a1-4c07-a8af-6a46a825c209@github.com>
Message-ID: <F-DVZ4RGb3T5wnpp6fFyhE33nNySOb3c9VB9LbOi_mA=.7e7f3ddd-4e5b-4cb0-88f0-cfad4c3ec23e@github.com>

On Thu, 10 Oct 2024 19:25:01 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> I don't think there is any way to meaningfully and reliably test the assertion that `Instant.now()` is the using the same clock as `Instant.now(Clock.systemUTC())` given the potential delays in execution of the two statements.
>> It might be possible to ignore well known delays due to gc or compilation by making sure the code is warmed up by repeating the test until the delta meets the .1 sec limit. If it was really a bug, the test would timeout after a couple of minutes. Putting a while loop around the body of the test would cover that.
>> I'd leave the code using `abs` alone to avoid exposing some other unanticipated change.
>
> I am keeping the timeout as 60 seconds. is this ok?
> 
>     @Test(timeOut=60000)
>     public void now() {
>         Instant expected, test;
>         long diff;
>         do {
>             expected = Instant.now(Clock.systemUTC());
>             test = Instant.now();
>             diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
>         } while( diff > 100 ); // retry if more than 0.1 sec
>     }

Yes, looks fine;  The normal JTREG timeout is 2 minutes. 60 seconds is fine for the testng timeout.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1795993908

From duke at openjdk.org  Thu Oct 10 19:47:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 10 Oct 2024 19:47:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
Message-ID: <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>

On Thu, 10 Oct 2024 16:12:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Store log5(2) in BigDecimal
>
> src/java.base/share/classes/java/math/BigDecimal.java line 5270:
> 
>> 5268:         intVal = intVal.shiftRight(powsOf2); // remove powers of 2
>> 5269:         // maxPowsOf5 == ceil(log5(intVal)) roughly
>> 5270:         long maxPowsOf5 = (long) Math.ceil(intVal.bitLength() * LOG_5_OF_2);
> 
> Please document the meaning of this variable in form of inequalities w.r.t. `intVal`.
> Also, shouldn't it be named `maxExpOf5` or similar? It's an exponent, after all.

The name `maxPowsOf5` has been chosen for consistence with `powsOf2`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1795995929

From rsunderbabu at openjdk.org  Thu Oct 10 19:56:24 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Thu, 10 Oct 2024 19:56:24 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v2]
In-Reply-To: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
Message-ID: <XWL5bol2O-zJ8x-zc_vOLea-zNJoOtsZ1WDW2uRGdSk=.819904ac-f258-485d-904c-03d35a30004e@github.com>

> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
> 
> Testing: The test was run for 100 times with -Xcomp option.

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  retry till timeout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21413/files
  - new: https://git.openjdk.org/jdk/pull/21413/files/a84e4fc7..c0998456

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21413&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21413&range=00-01

  Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21413/head:pull/21413

PR: https://git.openjdk.org/jdk/pull/21413

From duke at openjdk.org  Thu Oct 10 20:07:47 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 10 Oct 2024 20:07:47 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v34]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <DZlxKQK8Hh55r7fZh2nHi7RyxKjBEh1FogEoaSezKjU=.fd10e547-50b3-4e39-b140-07e8fd8f5c08@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added comments on mathematical semantic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/5caa5651..76d8e2af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=32-33

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Thu Oct 10 20:28:13 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 10 Oct 2024 20:28:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
Message-ID: <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>

On Thu, 10 Oct 2024 19:44:21 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 5270:
>> 
>>> 5268:         intVal = intVal.shiftRight(powsOf2); // remove powers of 2
>>> 5269:         // maxPowsOf5 == ceil(log5(intVal)) roughly
>>> 5270:         long maxPowsOf5 = (long) Math.ceil(intVal.bitLength() * LOG_5_OF_2);
>> 
>> Please document the meaning of this variable in form of inequalities w.r.t. `intVal`.
>> Also, shouldn't it be named `maxExpOf5` or similar? It's an exponent, after all.
>
> The name `maxPowsOf5` has been chosen for consistence with `powsOf2`.

Could make sense using Math.round() instead of Math.ceil() to get better upper bound?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1796053786

From duke at openjdk.org  Thu Oct 10 20:36:26 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 10 Oct 2024 20:36:26 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v35]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <oQ2jxvi26vsJij2LCuQu0iyT3rlPyq1dlbQAW-zNcTM=.68c8d289-c1c2-45e9-b8d5-66e19e2f6b96@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refining mathematical definition of remainingZeros

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/76d8e2af..2e2c042e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=33-34

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Thu Oct 10 21:10:30 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 21:10:30 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  inc should be faster than add on most CPUs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/f7ab51f7..07215bbc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From duke at openjdk.org  Thu Oct 10 21:15:16 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 10 Oct 2024 21:15:16 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
Message-ID: <8zB-zdwFTQyf2gHWYK5q8nKLV5lOhYueOrk_lpPYH6Y=.4e9889ab-6b4b-4c6a-b243-a80d1c094602@github.com>

On Thu, 10 Oct 2024 21:10:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   inc should be faster than add on most CPUs

I have slightly adapted the copy loop to allow CPUs to use solely single-operand INC within the loop instead of dual-operand ADD.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2406046622

From rgiulietti at openjdk.org  Thu Oct 10 21:57:16 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Oct 2024 21:57:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
Message-ID: <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>

On Thu, 10 Oct 2024 20:25:09 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The name `maxPowsOf5` has been chosen for consistence with `powsOf2`.
>
> Could make sense using Math.round() instead of Math.ceil() to get better upper bound?

I'll have to check...
... tomorrow ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1796140763

From duke at openjdk.org  Thu Oct 10 22:45:13 2024
From: duke at openjdk.org (Bernd)
Date: Thu, 10 Oct 2024 22:45:13 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <8zB-zdwFTQyf2gHWYK5q8nKLV5lOhYueOrk_lpPYH6Y=.4e9889ab-6b4b-4c6a-b243-a80d1c094602@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <8zB-zdwFTQyf2gHWYK5q8nKLV5lOhYueOrk_lpPYH6Y=.4e9889ab-6b4b-4c6a-b243-a80d1c094602@github.com>
Message-ID: <ypaNksQS3D5SXEzbEoZNvPhJsr0WoGmRiW2F07ijQTc=.f3f00676-f17f-4cf9-9a93-326295e36e34@github.com>

On Thu, 10 Oct 2024 21:12:50 GMT, Markus KARG <duke at openjdk.org> wrote:

> I have slightly adapted the copy loop to allow CPUs to use solely single-operand INC within the loop instead of dual-operand ADD.

If that makes a difference we might need to consider fixing the Compiler :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2406164161

From mseledtsov at openjdk.org  Thu Oct 10 22:49:10 2024
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 10 Oct 2024 22:49:10 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support [v2]
In-Reply-To: <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
 <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
Message-ID: <7qtN24O68lFXKIhmUZD4iCEn_NE9OcEPdL2Cn7iWITE=.3378efdd-d54c-4df5-b9e3-5114c9495930@github.com>

On Thu, 10 Oct 2024 14:27:08 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
>> 
>> Positive Testing:
>> tier1,tier2,tier3 - to check stability
>> tier5 - to run container tests
>> 
>> Negative Testing:
>> Ran the following groups in hosts where container is not present.
>> open/test/hotspot/jtreg/containers/
>> open/test/jdk/jdk/internal/platform/docker/
>> open/test/jdk/jdk/internal/platform/cgroup/
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comment

Marked as reviewed by mseledtsov (Committer).

Changes look good to me. Thank you for making these changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21423#pullrequestreview-2361544516
PR Comment: https://git.openjdk.org/jdk/pull/21423#issuecomment-2406168566

From swen at openjdk.org  Fri Oct 11 00:32:14 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 11 Oct 2024 00:32:14 GMT
Subject: Integrated: 8341906: Optimize ClassFile writing BufBuffer
In-Reply-To: <bqOKlhJoakkfA10HQNiiZFekPZYMTF3eZI6Yt4brp80=.efe1096f-bae4-4941-9532-177f29fef605@github.com>
References: <bqOKlhJoakkfA10HQNiiZFekPZYMTF3eZI6Yt4brp80=.efe1096f-bae4-4941-9532-177f29fef605@github.com>
Message-ID: <PucYDzcAh-0vFho2SwMwLikI61iotf59btJmHbkCBZg=.806fd08d-d798-49b8-b29b-e8c140ef9bcd@github.com>

On Thu, 10 Oct 2024 01:13:13 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> We made a lot of improvements to merge writes to BufWriter in #21243, and this PR is about doing more of the same.

This pull request has now been integrated.

Changeset: 24eb3601
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/24eb360147a5ca548abc89eb6480f46b89e11d19
Stats:     154 lines in 13 files changed: 43 ins; 35 del; 76 mod

8341906: Optimize ClassFile writing BufBuffer

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21437

From duke at openjdk.org  Fri Oct 11 00:50:09 2024
From: duke at openjdk.org (duke)
Date: Fri, 11 Oct 2024 00:50:09 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support [v2]
In-Reply-To: <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
 <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
Message-ID: <eQ78vvDQeRdPWhkcQOE3irfp57ONh9Hb3pTV6g0XwDU=.ce77cdc4-6d65-4c73-9f7e-91932c03f7b5@github.com>

On Thu, 10 Oct 2024 14:27:08 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
>> 
>> Positive Testing:
>> tier1,tier2,tier3 - to check stability
>> tier5 - to run container tests
>> 
>> Negative Testing:
>> Ran the following groups in hosts where container is not present.
>> open/test/hotspot/jtreg/containers/
>> open/test/jdk/jdk/internal/platform/docker/
>> open/test/jdk/jdk/internal/platform/cgroup/
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comment

@rsunderbabu 
Your change (at version 3e36b519be6dfed513fbe867e3ec0f03e061eaa1) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21423#issuecomment-2406315737

From swen at openjdk.org  Fri Oct 11 02:20:18 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 11 Oct 2024 02:20:18 GMT
Subject: Integrated: 8341900: Optimize DirectCodeBuilder writeBody
In-Reply-To: <1ll-Cy1m3u-A9GUqixqxkTUpv0qWHkgVLbUsZiiYfQc=.456cfb0c-aa33-40cd-bbcb-961ad69d2f46@github.com>
References: <1ll-Cy1m3u-A9GUqixqxkTUpv0qWHkgVLbUsZiiYfQc=.456cfb0c-aa33-40cd-bbcb-961ad69d2f46@github.com>
Message-ID: <dWE31hgBIAzqGDY5a5m69LVEx3L_QLp_PRbXuT8yAEo=.339f6057-3ae0-4844-a94b-3cc0bea93f03@github.com>

On Thu, 10 Oct 2024 03:55:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A simple optimization to reduce duplicate code. Reduce the codeSize of writeBody from 268 to 240

This pull request has now been integrated.

Changeset: 472db922
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/472db922fabfb8942f15d39ebd58125189bc8600
Stats:     18 lines in 1 file changed: 5 ins; 10 del; 3 mod

8341900: Optimize DirectCodeBuilder writeBody

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21440

From duke at openjdk.org  Fri Oct 11 02:47:14 2024
From: duke at openjdk.org (duke)
Date: Fri, 11 Oct 2024 02:47:14 GMT
Subject: Withdrawn: 8338242: RoundingMode.HALF_UP gives different results with
 NumberFormat
In-Reply-To: <Kjxluy_pwph_tlhSr0fy8Hq2B29GlK55BWO4nvcxw6w=.c385d8ac-09ed-4409-835d-80fb7934c299@github.com>
References: <Kjxluy_pwph_tlhSr0fy8Hq2B29GlK55BWO4nvcxw6w=.c385d8ac-09ed-4409-835d-80fb7934c299@github.com>
Message-ID: <n_UJwEc8INLC-6P_JR0vGc8eun3gRAvnkd4cSy19XU0=.4c5ad406-87f3-4513-8d3f-9b684dacce65@github.com>

On Wed, 14 Aug 2024 11:46:31 GMT, Myp <duke at openjdk.org> wrote:

> Fix of problem RoundingMode.HALF_UP gives different results with NumberFormat

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20580

From kbarrett at openjdk.org  Fri Oct 11 03:59:13 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Oct 2024 03:59:13 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
Message-ID: <WROL2RXymrN5wBbnQDZ3YfOFDLnSVvZZYV9kNziHUMY=.22a8cd29-f34d-4882-9bf4-27ac8e125988@github.com>

On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust gcc warning settings; bring back rslt

test/hotspot/gtest/runtime/test_os_linux.cpp line 366:

> 364:       os::pretouch_memory(heap, heap + size, os::vm_page_size());
> 365:     };
> 366:     auto useMemory = [heap](Thread*, int) {

Coming to this late, after the change has been integrated.

These lambdas should have been changed to use implicit reference capture
(`[&]`), per the style guide.

The change to the pretouch lambda actually makes things more difficult to
understand, since the outer `size` variable *is* referenced within the lambda
body.  This works because `size` is an integral constant initialized from a
constant expression, so does not need to be captured for the reference to
work. I'm guessing the clang warning had something to do with that, but it's
not mentioned in the JBS issue.  If implicit reference capture were used, the
referential transparency that comes with it would mean readers wouldn't need
to even know about that distinction.

I'll file an issue to change the capture lists.  I didn't find any other
explicit capture lists in HotSpot code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1796392834

From swen at openjdk.org  Fri Oct 11 05:17:49 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 11 Oct 2024 05:17:49 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName [v5]
In-Reply-To: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
Message-ID: <7PGw6b5uXf_6-kaXs74YojO_Nyusketosn5UUH26cL8=.6bfe19cf-8262-4e1d-9887-56f45dea2fa0@github.com>

> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

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 seven additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - suggestion from @liach
 - stable
 - ReferenceClassDescImpl cache internalName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21373/files
  - new: https://git.openjdk.org/jdk/pull/21373/files/8da27b0f..a18164f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=03-04

  Stats: 4986 lines in 67 files changed: 4754 ins; 57 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/21373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21373/head:pull/21373

PR: https://git.openjdk.org/jdk/pull/21373

From patrick at reini.net  Fri Oct 11 05:39:08 2024
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 11 Oct 2024 07:39:08 +0200
Subject: Potential URLClassLoader bug?
In-Reply-To: <33430757-ef74-4b19-b870-8813ab216be0@gmail.com>
References: <33430757-ef74-4b19-b870-8813ab216be0@gmail.com>
Message-ID: <B69A4057-15BE-48E5-A30C-248F6E55D4FC@reini.net>

Hi Jaikiran,

Thanks for the info. I will consult the bug for more details then.

Patrick 

> Am 10.10.2024 um 16:21 schrieb Jaikiran Pai <jai.forums2013 at gmail.com>:
> 
> ?Hello Patrick,
> 
> This is a known bug https://bugs.openjdk.org/browse/JDK-8315993 which gets triggered when the getResource() gets called on a URL returned through the URLClassLoader. We know what's causing this but the fix isn't straightforward and is currently under investigation.
> 
> -Jaikiran


From liach at openjdk.org  Fri Oct 11 05:44:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 05:44:19 GMT
Subject: RFR: 8341924: Improve error message with structurally malformed Code
 array
Message-ID: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>

Patch a tableswitch instruction's low value to be greater than a high value, previously, javap will not print any previous instruction and report problematic address/bci to be 0. This is because the iteration of bound models require first collecting all data into a buffer list. We call the eager `forEach` instead to avoid this problem.

Before:

$ javap -c BadSwitch.class
Compiled from "BadSwitch.java"
final class BadSwitch {
  static void work(int);
    Code:
Error: error at or after byte 0
}


Now:

$ $localjdk2/bin/javap -c BadSwitch.class
Compiled from "BadSwitch.java"
final class BadSwitch {
  static void work(int);
    Code:
       0: iload_0
Error: error at or after address 1: Invalid tableswitch values low: 9 high: 5
}

-------------

Commit messages:
 - 8341924: Improve error message with structurally malformed Code array

Changes: https://git.openjdk.org/jdk/pull/21463/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21463&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341924
  Stats: 9 lines in 1 file changed: 2 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21463.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21463/head:pull/21463

PR: https://git.openjdk.org/jdk/pull/21463

From duke at openjdk.org  Fri Oct 11 06:18:15 2024
From: duke at openjdk.org (Markus KARG)
Date: Fri, 11 Oct 2024 06:18:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <ypaNksQS3D5SXEzbEoZNvPhJsr0WoGmRiW2F07ijQTc=.f3f00676-f17f-4cf9-9a93-326295e36e34@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <8zB-zdwFTQyf2gHWYK5q8nKLV5lOhYueOrk_lpPYH6Y=.4e9889ab-6b4b-4c6a-b243-a80d1c094602@github.com>
 <ypaNksQS3D5SXEzbEoZNvPhJsr0WoGmRiW2F07ijQTc=.f3f00676-f17f-4cf9-9a93-326295e36e34@github.com>
Message-ID: <ncBcFsD7FZ9sCkiqawLmwwr0ZID1f1T44-hvzncNOoY=.fe3a8523-fb9e-4d3b-9f1a-6862435b6d36@github.com>

On Thu, 10 Oct 2024 22:42:19 GMT, Bernd <duke at openjdk.org> wrote:

> > I have slightly adapted the copy loop to allow CPUs to use solely single-operand INC within the loop instead of dual-operand ADD.
> 
> If that makes a difference we might need to consider fixing the Compiler :)

Hm... really? In fact I am not sure if the compiler is actually able to optimize replacement from ADD to INC *in this particular* scenario: The operand of the ADD is *neither* a constant and in particular *not* `1`, the upper limit of the loop is *not* a constant, and is typically far beyond any reasonable unrolling limit (readers rather often are asked for multiple KB here to optimize I/O transmissions). This is not just `for (int i = 0; i < 5; i++;)` (always same limit, reasonably low limit, using INC only).

Anyways, if you can proof me wrong I am willing to learn (and to undo this commit)! :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2406625958

From aboldtch at openjdk.org  Fri Oct 11 06:43:33 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 11 Oct 2024 06:43:33 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v3]
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

Axel Boldt-Christmas 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 tag 'jdk-24+19' into JDK-8341692
   
   Added tag jdk-24+19 for changeset e7c5bf45
 - LargeWindowPaintTest.java fix id typo
 - Fix problem-listed @requires typo
 - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
 - Reorder z_globals options: product > diagnostic product > develop
 - Consistent albite special code style
 - Consistent order between ZArguments and GCArguments
 - Remove XCollectedHeap from HSDB
 - Fix typo in TestZUncommitEvent.java
 - Add missing problem-listing
 - ... and 2 more: https://git.openjdk.org/jdk/compare/63794f5e...e58b4c5a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21401/files
  - new: https://git.openjdk.org/jdk/pull/21401/files/22c243a6..e58b4c5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=01-02

  Stats: 6773 lines in 133 files changed: 5327 ins; 455 del; 991 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

PR: https://git.openjdk.org/jdk/pull/21401

From iklam at openjdk.org  Fri Oct 11 06:48:32 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 11 Oct 2024 06:48:32 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v3]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <D09TNJDwgd8OVBTt_488SYoevx1arDB0mewIGcd7HNE=.bf5135ba-56d1-4e44-b7f8-48379caba007@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  8341600: [premain] Automatic aot-init of classes used by java.lang.invoke

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/ebfbb238..e9995ea7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=01-02

  Stats: 477 lines in 14 files changed: 344 ins; 63 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From asotona at openjdk.org  Fri Oct 11 07:58:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Oct 2024 07:58:13 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
Message-ID: <qQikHiXEAsOIvFXlvHjnU5DAb6vlahajMol9UQDRdi8=.dd7b5474-fe60-4802-be32-335880bb22a8@github.com>

On Thu, 10 Oct 2024 19:13:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
> 
> Notes:
> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.

test/jdk/jdk/classfile/NullHostileTest.java line 1:

> 1: /*

I'm a bit worried about maintainability of such complex parametrized test with hard-listed method signatures in a text form. I would recommend to find better location/category and tier for the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21458#discussion_r1796573314

From asotona at openjdk.org  Fri Oct 11 08:01:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Oct 2024 08:01:11 GMT
Subject: RFR: 8341924: Improve error message with structurally malformed
 Code array
In-Reply-To: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
References: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
Message-ID: <r7LuAv5VfvyxcXRESMeNV4Yqb95K3w4Lgoe0M3dX7vs=.95461bfe-d84e-4f4e-8147-c1e0ed0332ba@github.com>

On Fri, 11 Oct 2024 05:39:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Patch a tableswitch instruction's low value to be greater than a high value, previously, javap will not print any previous instruction and report problematic address/bci to be 0. This is because the iteration of bound models require first collecting all data into a buffer list. We call the eager `forEach` instead to avoid this problem.
> 
> Before:
> 
> $ javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
> Error: error at or after byte 0
> }
> 
> 
> Now:
> 
> $ $localjdk2/bin/javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
>        0: iload_0
> Error: error at or after address 1: Invalid tableswitch values low: 9 high: 5
> }

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21463#pullrequestreview-2362194526

From eirbjo at openjdk.org  Fri Oct 11 08:25:43 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 08:25:43 GMT
Subject: RFR: 8341944: zlib no longer requires dummy byte for raw inflate
Message-ID: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>

Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.

These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):


// Override fill() method to provide an extra "dummy" byte
// at the end of the input stream. This is required when
// using the "nowrap" Inflater option.
protected void fill() throws IOException {

However, zlib has not required such an extra dummy byte since 2003. 


Changes in 1.2.0 (9 March 2003)
- New and improved inflate code
    - Raw inflate no longer needs an extra dummy byte at end
``` 

The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.

Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.

Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR.

-------------

Commit messages:
 - Remove overrides of InflaterInputStream.fill which provide an extra dummy byte at the end of raw compressed streams

Changes: https://git.openjdk.org/jdk/pull/21467/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21467&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341944
  Stats: 35 lines in 2 files changed: 0 ins; 35 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21467/head:pull/21467

PR: https://git.openjdk.org/jdk/pull/21467

From eirbjo at openjdk.org  Fri Oct 11 08:25:43 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 08:25:43 GMT
Subject: RFR: 8341944: zlib no longer requires dummy byte for raw inflate
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <F_QzSn_a3Cn4uso-ERJKsp-aqq_SXueUTbEy1q87AAI=.eb52e277-c118-486c-abb2-9e36ec71723d@github.com>

On Fri, 11 Oct 2024 08:11:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR.

Channeling @simonis for his experience with third-party zlib implementations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2406875243

From duke at openjdk.org  Fri Oct 11 09:38:11 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 11 Oct 2024 09:38:11 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <qQikHiXEAsOIvFXlvHjnU5DAb6vlahajMol9UQDRdi8=.dd7b5474-fe60-4802-be32-335880bb22a8@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
 <qQikHiXEAsOIvFXlvHjnU5DAb6vlahajMol9UQDRdi8=.dd7b5474-fe60-4802-be32-335880bb22a8@github.com>
Message-ID: <CGY27o2ClZvLMT3oydn4zcXR-0qn3ZFTdYGe7QjOve0=.722b0357-a74d-4a21-bbec-383d4d35a3bc@github.com>

On Fri, 11 Oct 2024 07:55:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
>> 
>> Notes:
>> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
>> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
>> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.
>
> test/jdk/jdk/classfile/NullHostileTest.java line 1:
> 
>> 1: /*
> 
> I'm a bit worried about maintainability of such complex parametrized test with hard-listed method signatures in a text form. I would recommend to find better location/category and tier for the test.

Perhaps the parameters could be annotated with?a?**JDK**?internal `@Nullable`?annotation, which?would then?be?used by?the?test to?determine whether?the?parameter is?supposed to?allow?`null`s.

--------------------------------------------------------------------------------

This?would also?ease future?migration to?[Null?Restricted and?Nullable?Types].

[Null?Restricted and?Nullable?Types]: https://openjdk.org/jeps/8303099

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21458#discussion_r1796699729

From coffeys at openjdk.org  Fri Oct 11 10:13:11 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 11 Oct 2024 10:13:11 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v4]
In-Reply-To: <Tb-8iAEg9YHtjK6lRiLcVbKy9vkgEVwmzZu2g9-v5NQ=.c12dd52f-507b-46ed-9cb4-95bba858c32d@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <Tb-8iAEg9YHtjK6lRiLcVbKy9vkgEVwmzZu2g9-v5NQ=.c12dd52f-507b-46ed-9cb4-95bba858c32d@github.com>
Message-ID: <n3UuChOOGE3tRZ_mh86UL07LDVdgPGaQKRQjbz6A36U=.57ff9ec9-4590-4a65-8eb5-8ffbcdf96608@github.com>

On Mon, 7 Oct 2024 12:42:00 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:
> 
>   JDK-8329251

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1972:

> 1970:                                 .getPath((FileInputStream) stream);
> 1971:                 if (keystorePath != null) {
> 1972:                     debug.println("PKCS12KeyStore: Loading \"" + keystorePath.substring(

I ran a straightforward test to connect to a TLS website and expected to see the cacerts file details being printed. 

`BufferedInputStream` is used for `InputStream` instance

sun.security.util.KeyStoreDelegator#engineLoad


            InputStream bufferedStream = new BufferedInputStream(stream);
            bufferedStream.mark(Integer.MAX_VALUE);

            try {
                @SuppressWarnings("deprecation")
                KeyStoreSpi tmp = primaryKeyStore.newInstance();
                tmp.engineLoad(bufferedStream, password);


You'll need to get a handle to the BufferedInputStream -> FilterInputStream -> `in` stream and check if it's an instance of a `FileInputStream`. You can then query and print the path value if present.

On a side note, I was surprised to see no debug output (of interest) initially when I was using the `-Djava.security.debug=keystore` value. Turns out I have to use the `pkcs12` value for debug option. Given that PKCS12KeyStore.java is the only file to use this debug value and that pkcs12 is now the default keystore type, there might be merit in folding this value into the more common `keystore` option

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1796741288

From erikj at openjdk.org  Fri Oct 11 12:45:19 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 11 Oct 2024 12:45:19 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal [v3]
In-Reply-To: <pyeVVbvjxTMr-WjFeKnjdipXwKyyuJjCx_s_oJ9hdQc=.a1fe3942-3ddd-45f7-9a59-d722c71bf1b5@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
 <pyeVVbvjxTMr-WjFeKnjdipXwKyyuJjCx_s_oJ9hdQc=.a1fe3942-3ddd-45f7-9a59-d722c71bf1b5@github.com>
Message-ID: <B5gxeodH3r9r68Qn_ISfOGoPnBwTPnG1JA2UFCG6Ce8=.a8d9b25e-63b2-436f-b284-eeb214eeb6e8@github.com>

On Thu, 10 Oct 2024 12:25:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
>> 
>> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
>> 
>> This PR does two things:
>> 
>> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
>> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.
>
> Kevin Rushforth 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 'master' into 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Update javadoc
>  - Update copyright years
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test
>  - 8311530: Deprecate jdk.jsobject module for removal

Build change looks good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20555#pullrequestreview-2362720934

From liach at openjdk.org  Fri Oct 11 13:00:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 13:00:12 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <CGY27o2ClZvLMT3oydn4zcXR-0qn3ZFTdYGe7QjOve0=.722b0357-a74d-4a21-bbec-383d4d35a3bc@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
 <qQikHiXEAsOIvFXlvHjnU5DAb6vlahajMol9UQDRdi8=.dd7b5474-fe60-4802-be32-335880bb22a8@github.com>
 <CGY27o2ClZvLMT3oydn4zcXR-0qn3ZFTdYGe7QjOve0=.722b0357-a74d-4a21-bbec-383d4d35a3bc@github.com>
Message-ID: <ZA_XJq4dtg_7eOXMllSkEXAbWoMMQS55sw6Qnq0XPBs=.ba0c9451-40b3-4cab-a026-35bcb5f6b742@github.com>

On Fri, 11 Oct 2024 09:35:35 GMT, ExE Boss <duke at openjdk.org> wrote:

>> test/jdk/jdk/classfile/NullHostileTest.java line 1:
>> 
>>> 1: /*
>> 
>> I'm a bit worried about maintainability of such complex parametrized test with hard-listed method signatures in a text form. I would recommend to find better location/category and tier for the test.
>
> Perhaps the parameters could be annotated with?a?**JDK**?internal `@Nullable`?annotation, which?would then?be?used by?the?test to?determine whether?the?parameter is?supposed to?allow?`null`s.
> 
> --------------------------------------------------------------------------------
> 
> This?would also?ease future?migration to?[Null?Restricted and?Nullable?Types].
> 
> [Null?Restricted and?Nullable?Types]: https://openjdk.org/jeps/8303099

Should I remove this test and only include the null checks in the pr?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21458#discussion_r1796920856

From lancea at openjdk.org  Fri Oct 11 14:08:09 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 11 Oct 2024 14:08:09 GMT
Subject: RFR: 8341944: zlib no longer requires dummy byte for raw inflate
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <A9t0d4_xETdU7XdH5jOyD8I6ZUq0Shr4rbflX0iekH0=.93d779aa-28b3-452f-8ae6-886ecc2fe2b1@github.com>

On Fri, 11 Oct 2024 08:11:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.

I think we need to be a bit cautious with the proposed change while I understand the desire to remove potentially unneeded code. 

 I have not yet found a specific issue for the for the original need for the overload of fill, but have not looked to hard either, and the constructor in Inflater.java also makes reference to gzip for which we do not have as much test coverage as we do for Zip.

So we might want to hold off on this PR for JDK 24 while we try to do some more archaeological digging.

As far as which zlib with the openJDK,  currently the openjdk project bundles zlib with the windows builds and relies on the zlib bundled with the various OS's 

I would be surprised to find any vendor using a zlib below zlib 1.2.13 or 1.3.1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2407490236

From ihse at openjdk.org  Fri Oct 11 14:13:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Oct 2024 14:13:10 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
Message-ID: <KEc3pecAXzAp2aUxW7uRiCkqCGB4RtDQqX59WAIB1wI=.6f536ad0-2dec-40e2-a75a-2dd52ff12a02@github.com>

On Thu, 10 Oct 2024 17:54:51 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` launcher, 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 launcher 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:
>> 
>> $ java
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [options...] <what to execute> [arguments to main method...]
>> 
>> Where <what to execute> is one of:
>>   <MainClass>                to execute the main method of a compiled class
>>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>>   -m <module>[/<MainClass>]  to execute the main class of a module
>>   <SourceFile.java>          to compile and execute a single-file program
>> 
>> Where key options include:
>>   --class-path <class path>
>>       a : separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a : separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help based on review suggestions.

I think this looks great now. Thanks for doing this!

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21411#pullrequestreview-2362910134

From ihse at openjdk.org  Fri Oct 11 14:17:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 11 Oct 2024 14:17:14 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <YUSAHbPYNykkj8SJ1-vhsrePOvfJnLYfxkkWg05qYr8=.e4e231b2-c637-4263-98b9-4cbf854e2ee3@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
 <YUSAHbPYNykkj8SJ1-vhsrePOvfJnLYfxkkWg05qYr8=.e4e231b2-c637-4263-98b9-4cbf854e2ee3@github.com>
Message-ID: <U51BBrN81OoqMuVmB5o88pqIBeTQzJUpIge_xW206j0=.4ba772bf-9d9c-48d9-94f6-2168038bf18c@github.com>

On Thu, 10 Oct 2024 08:23:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I do wonder why the header both here and inside HotSpot is named ub.h instead of ubsan.h. Latter sounds better to me, but it doesn't really matter much

I agree it would have probably been better from the start, but at this point consistency with hotspot is more important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2407508806

From eirbjo at openjdk.org  Fri Oct 11 14:39:10 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 14:39:10 GMT
Subject: RFR: 8341944: The zlib library no longer requires dummy byte for
 raw inflate
In-Reply-To: <A9t0d4_xETdU7XdH5jOyD8I6ZUq0Shr4rbflX0iekH0=.93d779aa-28b3-452f-8ae6-886ecc2fe2b1@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
 <A9t0d4_xETdU7XdH5jOyD8I6ZUq0Shr4rbflX0iekH0=.93d779aa-28b3-452f-8ae6-886ecc2fe2b1@github.com>
Message-ID: <XTzzNDqSwpJdeDbK_Bz3C3AgTTMwYqIjxf1RHLCsFJw=.02a19a97-a4f3-479a-a056-c64736638d6a@github.com>

On Fri, 11 Oct 2024 14:05:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think we need to be a bit cautious with the proposed change while I understand the desire to remove potentially unneeded code.

I understand the need to be cautious in this area. But I would also like to avoid cargo-culting this for another 21 years :-)  

> I have not yet found a specific issue for the for the original need for the overload of fill, but have not looked to hard either

If we trust the zlib change log, the original need retired with 1.2.0. Any of the performance-motivated forks like chromium-zlib or cloudflare-zlib should have been forked long after this. Perhaps @simonis can confirm. 

>, and the constructor in Inflater.java also makes reference to gzip for which we do not have as much test coverage as we do for Zip.

It's interesting that `GZIPInputStream` does _not_ override `InflaterInputStream.fill`, but _does_ use `nowrap`.

The extra dummy byte note in the Inflater constructor is now misleading and should probably go too. Would require a CSR. 

The `@param nowrap` note is perhaps also misleading in that it is not actually specific to GZIP. It just tells zlib to expect raw deflated data, without any wrapping, GZIP or zlib. I guess since the only wrapping supported by the JDK is GZIP, the note is maybe okay. But if we do a CSR, I think we should relax this note to not reference GZIP.  

> So we might want to hold off on this PR for JDK 24 while we try to do some more archaeological digging.

That is fair.

> As far as which zlib with the openJDK, currently the openjdk project bundles zlib with the windows builds and relies on the zlib bundled with the various OS's
> 
> I would be surprised to find any vendor using a zlib below zlib 1.2.13 or 1.3.1

Yes, that would indeed be awkward.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2407549193

From liach at openjdk.org  Fri Oct 11 14:48:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 14:48:46 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v4]
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <9BdcLKLhIrZlXGxDokzKK1ro6IojgkHVMDavndMN_G8=.f7f7d7e7-2cbf-45a8-995d-c13b504c9c11@github.com>

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Mandy reviews
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - mlchung suggestions: elementType, improve utility methods
 - class or interface descriptor renamed for clarity
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Cleanup after merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Compile error
 - Redundant import
 - ... and 2 more: https://git.openjdk.org/jdk/compare/61338661...e65fa6aa

-------------

Changes: https://git.openjdk.org/jdk/pull/20665/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=03
  Stats: 790 lines in 17 files changed: 425 ins; 236 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/20665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20665/head:pull/20665

PR: https://git.openjdk.org/jdk/pull/20665

From liach at openjdk.org  Fri Oct 11 14:48:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 14:48:47 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v3]
In-Reply-To: <E08k_oGBlIEXC0c3Hpn06sJdDHeSnXTzejFCxS_2epQ=.b3fc2d7c-9ce2-41fb-a5ce-fd306156fcd6@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <-n7Fsw654cCQ6wSb_WI8T3pBe_PCXPhCstQP9HZ02-4=.61d5164d-6aca-4943-bbb6-226050831c13@github.com>
 <5MJzVXplOUb-odJPDlLzwvrsnn4T4r2QjA69bbcP60E=.26701d57-80b1-4dc6-8713-8623ddf480d0@github.com>
 <bj7FLJ29QdKbGbK1SEHpc11NQGMXcH7xLW15p1gKqn4=.18feb48a-b77e-46b4-b464-481ebe14d636@github.com>
 <E08k_oGBlIEXC0c3Hpn06sJdDHeSnXTzejFCxS_2epQ=.b3fc2d7c-9ce2-41fb-a5ce-fd306156fcd6@github.com>
Message-ID: <2aQUXRewnvJ_PaOJ_U69p-CjbUB8kbbbrgmH3mzTViQ=.d56ca949-7e97-4c74-a07b-541fecd53fb7@github.com>

On Tue, 8 Oct 2024 21:13:47 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> So like `if (rank <= 0) throw ConstantUtils.rankNotPositive(rank);` at individual use sites?
>
> I meant no need to have a utility method.   Just do this:
> 
> Suggestion:
> 
>     public static void validateArrayDepth(int rank) {
>         if (rank <= 0) {
>             throw new IllegalArgumentException("rank " + rank + " is not a positive value");
>         }
>         validateMaxArrayDepth(rank, true);
>     }
> 
> 
> Same change in `ArrayClassDescImpl::arrayType(int)`

Done. The negative rank check is pulled out separately in `ArrayClassDescImpl::arrayType(int)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1797064156

From mbaesken at openjdk.org  Fri Oct 11 14:52:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Oct 2024 14:52:13 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
Message-ID: <fcM0UHFRCPu_Ar0_n0B4MzHee7JPG__Iw4-537-26iA=.bf5184f5-1b74-4a27-8b4c-2ce0b793168b@github.com>

On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8340801
>  - move ub.h to a better location
>  - remove ubsan changes from jni_md.h
>  - JDK-8340801

In the review of the HS PR ubsan.hpp was discussed
https://github.com/openjdk/jdk/pull/19722
but then it was changed to ub.hpp .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2407576740

From eirbjo at openjdk.org  Fri Oct 11 15:16:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 15:16:50 GMT
Subject: RFR: 8341944: The zlib library no longer requires dummy byte for
 raw inflate [v2]
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <QoTT4a34dBIlopSlvARhtQPscwqM9Jp1TJO2X13Ri0Q=.d0fcdf31-852c-4c62-ba75-7ea4bf6b1a77@github.com>

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Update Inflater and Deflater constructors taking 'nowrap' options to explain more clearly what this option does

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21467/files
  - new: https://git.openjdk.org/jdk/pull/21467/files/661032c8..66abb0dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21467&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21467&range=00-01

  Stats: 14 lines in 2 files changed: 2 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21467/head:pull/21467

PR: https://git.openjdk.org/jdk/pull/21467

From eirbjo at openjdk.org  Fri Oct 11 15:16:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 15:16:50 GMT
Subject: RFR: 8341944: The zlib library no longer requires dummy byte for
 raw inflate
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <FfoWevKDqCL7NwhkZylNzwOSbPcRPf0_btWstfgUGBw=.dcf6aedb-a6b2-47d9-8dee-2ab50b0012e3@github.com>

On Fri, 11 Oct 2024 08:11:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA results pending. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.

I have updated the `nowrap` constructor of `java.util.zip.Inflater` to remove the note about the extra 'dummy' input byte. I also tightened up the constructor to more clearly explain what the `nowrap` parameter does. The current "will not use" feels a bit loose. The `nowrap` parameter description is updated to not mention GZIP and instead just say "expect compressed input without ZLIB headers".

The matching constructor in `java.util.zip.Deflater` is updated to be consistent with the changes in `Inflater`. These should be easy to read side-by-side.

These API changes requires a CSR, which I plan to create once "more archaeological digging" deems this PR can continue safely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2407618033

From rriggs at openjdk.org  Fri Oct 11 15:24:18 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 11 Oct 2024 15:24:18 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <ncBcFsD7FZ9sCkiqawLmwwr0ZID1f1T44-hvzncNOoY=.fe3a8523-fb9e-4d3b-9f1a-6862435b6d36@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <8zB-zdwFTQyf2gHWYK5q8nKLV5lOhYueOrk_lpPYH6Y=.4e9889ab-6b4b-4c6a-b243-a80d1c094602@github.com>
 <ypaNksQS3D5SXEzbEoZNvPhJsr0WoGmRiW2F07ijQTc=.f3f00676-f17f-4cf9-9a93-326295e36e34@github.com>
 <ncBcFsD7FZ9sCkiqawLmwwr0ZID1f1T44-hvzncNOoY=.fe3a8523-fb9e-4d3b-9f1a-6862435b6d36@github.com>
Message-ID: <l5C3bic8S9xA_bFq42MmDq4DosACBLLmBGmtnZ-zd3A=.2dbbc9b5-af13-4599-9841-5d2a53f414b9@github.com>

On Fri, 11 Oct 2024 06:16:02 GMT, Markus KARG <duke at openjdk.org> wrote:

> I have slightly adapted the copy loop to allow CPUs to use solely single-operand INC within the loop instead of dual-operand ADD.

Did you measure a performance improvement? Compiler optimizations are more productive than spot source changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2407640364

From jkarthikeyan at openjdk.org  Fri Oct 11 15:34:15 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Fri, 11 Oct 2024 15:34:15 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
Message-ID: <yxkBii8OvaDXyEgT5VWG1a2YISdWCKaRCQIsq_-6c54=.3ef53153-6922-4e60-9cbf-1aba0508cadc@github.com>

On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2407658405

From eirbjo at openjdk.org  Fri Oct 11 15:35:29 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 11 Oct 2024 15:35:29 GMT
Subject: RFR: 8341957: Add test for URLClassLoader loading invalid class with
 mismatching CRC32
Message-ID: <q6Qz4Lg2ckHcy7_T5ZKWldYeo02iUwjfZ6D-cxa6E6U=.00d97bc2-4e51-4a04-9f8f-6192f47cb508@github.com>

Please review this PR which adds test coverage for the case where `URLClassLoader.defineClass` fails with a `ClassFormatError` _and_ the CRC32 checksum of the class file byte array did not match the CRC32 value stated in the JAR file's CEN header.

In such cases, an `IOException` with the message _"CRC error while extracting entry from JAR file"_ is added as a suppressed exception to the `ClassFormatError`.

Adding a test documents this unspecified, but long-standing behavior.

For good measure, the test also covers the existing behavior of the module system class loader. Since the module system does not add similar suppressed exception on a CRC32 mismatch, this test mostly serves the purpose of documentation. 

The test is parameterized, as such it covers all eight combinations of {URLClassLoader/module class loader, valid/invalid class data, valid/invalid CRC checksum}.

Should any of the class loaders change behavior in the future (with or without intent), this test will notice and may need to be updated to document the new behavior. Otherwise, it will catch unintended regressions.

Testing: This is a test-only enhancement PR, no existing tests are updated.

-------------

Commit messages:
 - Rename "ClassLoadingContext" -> "ClassLoaderContext"
 - Make the test parameterized allows testing all eight combinations of class loader, valid class data, valid CRC in a single test
 - Add tests for the cases where there is a CRC mismatch, but the class file data is valid
 - Spell fix
 - Rename "zipFile" to "jarFile"
 - Add javadoc documentation to tests
 - Add test to verify that URLClassLoader checks CRC32 of class file data when defineClass fails with ClassFormatError

Changes: https://git.openjdk.org/jdk/pull/21469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341957
  Stats: 280 lines in 1 file changed: 280 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21469/head:pull/21469

PR: https://git.openjdk.org/jdk/pull/21469

From liach at openjdk.org  Fri Oct 11 15:49:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 15:49:33 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v4]
In-Reply-To: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
Message-ID: <wQ_yMnYZfpwLoEcOie-sTlUjn8cMeB76s_p3-PTv6Wc=.e1efc8ed-da0f-4a39-a238-1a4a1e419db3@github.com>

> 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

-------------

Changes: https://git.openjdk.org/jdk/pull/15834/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15834&range=03
  Stats: 128 lines in 3 files changed: 124 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15834.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15834/head:pull/15834

PR: https://git.openjdk.org/jdk/pull/15834

From liach at openjdk.org  Fri Oct 11 15:49:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 15:49:35 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v3]
In-Reply-To: <dKtiS_OzJBR_h2Dc964t46RuEQVq7y3ewmwBSoozXNY=.5e652e75-e142-4ffc-a1ba-bf6d0713092f@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
 <dKtiS_OzJBR_h2Dc964t46RuEQVq7y3ewmwBSoozXNY=.5e652e75-e142-4ffc-a1ba-bf6d0713092f@github.com>
Message-ID: <1hduZ0X2t1SHnf_G0IIyfWbFfdSASMPV4xq6-kdQnl0=.42ac5678-86c2-455b-9888-a88fa6ff7914@github.com>

On Wed, 25 Sep 2024 20:46:27 GMT, Stuart Marks <smarks 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 16 commits:
>> 
>>  - 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
>>  - Copyright year, revert changes for non-few element collections
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/a920af23...70583024
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 676:
> 
>> 674:                 return Collections.singletonSpliterator(e0);
>> 675:             }
>> 676:             return super.spliterator();
> 
> Not a big deal, but I prefer using if/else for situations like this where the then-part and else-part are equal in size and are conceptually at the same level. (As opposed to a check for a quick special case, where an early return is sensible, followed by the main logic at the method's top level.) Code in the rest of the file is similar, I think.
> 
> (yes, I'm aware that this takes an extra line)

Done. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15834#discussion_r1797139814

From asotona at openjdk.org  Fri Oct 11 15:56:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Oct 2024 15:56:18 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
Message-ID: <pEmF8E8tuIYWETu00K5UoDWml92yb4kj5VO7x4jB-ho=.ddd64a35-c899-43f8-9ee5-e95c683cde35@github.com>

On Thu, 10 Oct 2024 19:13:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
> 
> Notes:
> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.

src/java.base/share/classes/java/lang/classfile/instruction/DiscontinuedInstruction.java line 37:

> 35: import jdk.internal.javac.PreviewFeature;
> 36: 
> 37: import static java.util.Objects.requireNonNull;

Isn't it unused?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21458#discussion_r1797148194

From asotona at openjdk.org  Fri Oct 11 16:00:18 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Oct 2024 16:00:18 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
Message-ID: <tjPGWHuzmvj_rxfeUan2yHs3ike5EJBrbWtd4N_0IhM=.97754137-deea-4b7d-8a29-6982ec323a45@github.com>

On Thu, 10 Oct 2024 19:13:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
> 
> Notes:
> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.

src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java line 276:

> 274:     @Override
> 275:     public ClassDesc map(ClassDesc desc) {
> 276:         if (desc == null) return null;

I'm not sure this won't break some use case.
Here I would say null -> null mapping might be OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21458#discussion_r1797153280

From asotona at openjdk.org  Fri Oct 11 16:07:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Oct 2024 16:07:13 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <idRheykYi0899FvsW9LTTDCXZQNvCWTdEVREqAln9jY=.4311779d-092d-4ae6-b168-baa6fac7d4d9@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
 <tjPGWHuzmvj_rxfeUan2yHs3ike5EJBrbWtd4N_0IhM=.97754137-deea-4b7d-8a29-6982ec323a45@github.com>
 <idRheykYi0899FvsW9LTTDCXZQNvCWTdEVREqAln9jY=.4311779d-092d-4ae6-b168-baa6fac7d4d9@github.com>
Message-ID: <EfLAl6U6LarwUfWt_g_4vTjNHIHR4SzW8d5bNydYHD0=.f2e64d16-3e33-4039-b4ae-9b226a8ec15d@github.com>

On Fri, 11 Oct 2024 16:02:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java line 276:
>> 
>>> 274:     @Override
>>> 275:     public ClassDesc map(ClassDesc desc) {
>>> 276:         if (desc == null) return null;
>> 
>> I'm not sure this won't break some use case.
>> Here I would say null -> null mapping might be OK.
>
> Makes sense. I will push the changes when you finish the review.

It is all I have.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21458#discussion_r1797160380

From liach at openjdk.org  Fri Oct 11 16:07:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 16:07:12 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <tjPGWHuzmvj_rxfeUan2yHs3ike5EJBrbWtd4N_0IhM=.97754137-deea-4b7d-8a29-6982ec323a45@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
 <tjPGWHuzmvj_rxfeUan2yHs3ike5EJBrbWtd4N_0IhM=.97754137-deea-4b7d-8a29-6982ec323a45@github.com>
Message-ID: <idRheykYi0899FvsW9LTTDCXZQNvCWTdEVREqAln9jY=.4311779d-092d-4ae6-b168-baa6fac7d4d9@github.com>

On Fri, 11 Oct 2024 15:57:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
>> 
>> Notes:
>> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
>> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
>> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java line 276:
> 
>> 274:     @Override
>> 275:     public ClassDesc map(ClassDesc desc) {
>> 276:         if (desc == null) return null;
> 
> I'm not sure this won't break some use case.
> Here I would say null -> null mapping might be OK.

Makes sense. I will push the changes when you finish the review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21458#discussion_r1797158151

From liach at openjdk.org  Fri Oct 11 16:21:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 16:21:30 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v2]
In-Reply-To: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
Message-ID: <4N8U8IZlBtCnhyvamwRyjGP-PtLeEJJ1ZWFFNAGjp0E=.03112658-2220-4cf2-a144-f78c3a478720@github.com>

> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
> 
> Notes:
> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  asotona review remarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21458/files
  - new: https://git.openjdk.org/jdk/pull/21458/files/79443792..b4f0ebcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21458&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21458&range=00-01

  Stats: 940 lines in 3 files changed: 1 ins; 939 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21458/head:pull/21458

PR: https://git.openjdk.org/jdk/pull/21458

From liach at openjdk.org  Fri Oct 11 16:21:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 16:21:30 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API
In-Reply-To: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
Message-ID: <out9-vfj7XUkf51ErIUyngu5y9YvFT6FGsxoXPP2hH4=.f4c3e2c4-f5a6-40e4-884f-cf2c4edf915c@github.com>

On Thu, 10 Oct 2024 19:13:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
> 
> Notes:
> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.

Thanks adam for the review. I have removed the test for now. We can come back later and find a more comprehensive way to test builders accessible only in transforms, etc. and the null check test might actually be incorporated with a general contract check test that checks for IAE too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21458#issuecomment-2407736668

From asotona at openjdk.org  Fri Oct 11 16:28:12 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 11 Oct 2024 16:28:12 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v2]
In-Reply-To: <4N8U8IZlBtCnhyvamwRyjGP-PtLeEJJ1ZWFFNAGjp0E=.03112658-2220-4cf2-a144-f78c3a478720@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
 <4N8U8IZlBtCnhyvamwRyjGP-PtLeEJJ1ZWFFNAGjp0E=.03112658-2220-4cf2-a144-f78c3a478720@github.com>
Message-ID: <Vx3qireYT3NSY7odHcuZ7qyDv-k1PXh6Z1DbR0cBPXk=.7c38f15b-3e9a-4ec1-bce5-b7b29f142886@github.com>

On Fri, 11 Oct 2024 16:21:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
>> 
>> Notes:
>> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
>> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
>> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asotona review remarks

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21458#pullrequestreview-2363181465

From dfuchs at openjdk.org  Fri Oct 11 16:55:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 11 Oct 2024 16:55:12 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v2]
In-Reply-To: <F-DVZ4RGb3T5wnpp6fFyhE33nNySOb3c9VB9LbOi_mA=.7e7f3ddd-4e5b-4cb0-88f0-cfad4c3ec23e@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <DbUP95GxAnTQ2f-TTF65ooCYlMZsIb8yqTGxkaKsOMc=.7c53fb62-7607-4378-ad5c-f38aa8d1da47@github.com>
 <s-OkA8ZCdhMrg-UuxirJeT8rU7K-av_F5GG0cWu2XmM=.3d0a78e4-b513-4e7c-93cb-726bd3d9dae3@github.com>
 <O4Qew8_cYY2HnEBpIgAf7jYiYLZI82RTix4H1uDk8YQ=.20f4ae77-7bee-4e2f-be22-33c3b2a93f1a@github.com>
 <abBnyjgRnZRmGeIbagZ2W7ExT_zuXMwm-53uPcnR9p0=.433a327a-3e1b-4eef-9921-f425dc679e21@github.com>
 <I0Bs58nqtAUq4DXlpdohkQJiY5XNoYgxLWuWjn72sC4=.46606e37-54a1-4c07-a8af-6a46a825c209@github.com>
 <F-DVZ4RGb3T5wnpp6fFyhE33nNySOb3c9VB9LbOi_mA=.7e7f3ddd-4e5b-4cb0-88f0-cfad4c3ec23e@github.com>
Message-ID: <SUMfw7T4Whg8kbrse4wIa1MbyCn6RLT2ltNKqxOxNck=.86cb18d2-c1e2-4d2b-bfb0-db28cf755b38@github.com>

On Thu, 10 Oct 2024 19:42:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I am keeping the timeout as 60 seconds. is this ok?
>> 
>>     @Test(timeOut=60000)
>>     public void now() {
>>         Instant expected, test;
>>         long diff;
>>         do {
>>             expected = Instant.now(Clock.systemUTC());
>>             test = Instant.now();
>>             diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
>>         } while( diff > 100 ); // retry if more than 0.1 sec
>>     }
>
> Yes, looks fine;  The normal JTREG timeout is 2 minutes. 60 seconds is fine for the testng timeout.

FWIW - when I updated the System UTC clock to get sub-milliseconds resolution from the OS I added this test:
https://github.com/openjdk/jdk/blob/master/test/jdk/java/time/test/java/time/TestClock_System.java

Maybe some similar technique could be used here. That is - take System.currentTimeMillis(), Take Instant.now(), take System.currentTimeMillis() again, and then verify that the instant lies between the two snapshots: greater or equal to the first, less or equal to the second. That should always be true (unless the UTC clock is adjusted by NTP). But you could hopefully detect that and retry if you observe that the second call to System.currentTimeMillis() has returned a value which is before the first call. 

If the difference between the two System::curentTimeMillis calls is too big, then if you wish you might want to try again too.

I believe this would provide a more robust test strategy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1797211143

From qamai at openjdk.org  Fri Oct 11 16:57:13 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 11 Oct 2024 16:57:13 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
Message-ID: <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.4e3d7ba2-872f-4407-8bb0-1b9388614660@github.com>

On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2407793168

From jkarthikeyan at openjdk.org  Fri Oct 11 17:15:08 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Fri, 11 Oct 2024 17:15:08 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.4e3d7ba2-872f-4407-8bb0-1b9388614660@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.4e3d7ba2-872f-4407-8bb0-1b9388614660@github.com>
Message-ID: <dFk8CH3PN2SgyZ_VAef0uhWsdqj8D73_c1RTBsYUBrw=.164ea5ab-990d-4300-a77b-d8013089452a@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 rgiulietti at openjdk.org  Fri Oct 11 17:32:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Oct 2024 17:32:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
Message-ID: <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>

On Thu, 10 Oct 2024 21:54:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Could make sense using Math.round() instead of Math.ceil() to get better upper bound?
>
> I'll have to check...
> ... tomorrow ;-)

IIUC, the code assumes that the floating-point computation `Math.ceil(intVal.bitLength() * LOG_5_OF_2)` has the same value as the mathematical &lceil; `intVal.bitLength()` &times; log5(2) &rceil;.
I don't think this is safe, as it might happen that the computed and mathematical values are off by &plusmn;1.
To ensure 5^`maxPowsOf5` >= `intVal` (that is, maxPowsOf5 >= log5(intVal)) it would be more prudent to have

long maxPowsOf5 = (long) Math.ceil(intVal.bitLength() * LOG_5_OF_2) + 1;


But I think what you really want is maybe to meet 5^`maxPowsOf5` <= `intVal` < 5^(`maxPowsOf5` + 1) instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797246974

From rgiulietti at openjdk.org  Fri Oct 11 17:43:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Oct 2024 17:43:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v35]
In-Reply-To: <oQ2jxvi26vsJij2LCuQu0iyT3rlPyq1dlbQAW-zNcTM=.68c8d289-c1c2-45e9-b8d5-66e19e2f6b96@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <oQ2jxvi26vsJij2LCuQu0iyT3rlPyq1dlbQAW-zNcTM=.68c8d289-c1c2-45e9-b8d5-66e19e2f6b96@github.com>
Message-ID: <oSZSKhsyMbgScMdrl2onFHBvDKiMOQamfxbulN5M8Ps=.37894d09-5f63-423a-bf0c-bc1d5594d799@github.com>

On Thu, 10 Oct 2024 20:36:26 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refining mathematical definition of remainingZeros

src/java.base/share/classes/java/math/BigDecimal.java line 5221:

> 5219:      * {@code FIVE_TO_2_TO[n] == 5^(2^n)}
> 5220:      */
> 5221:     private static final BigInteger[] FIVE_TO_2_TO = new BigInteger[20];

As discussed before, the benchmarks show no significant performance regressions even for a million of trailing zeros if this cache is reduced to save resident memory footprint.
Suggestion:

    private static final BigInteger[] FIVE_TO_2_TO = new BigInteger[16 + 1];

src/java.base/share/classes/java/math/BigDecimal.java line 5259:

> 5257:         preferredScale = Math.clamp(preferredScale, Integer.MIN_VALUE - 1L, Integer.MAX_VALUE);
> 5258:         int powsOf2 = intVal.getLowestSetBit();
> 5259:         // scale - preferredScale >= remainingZeros >= max{n : (intVal % 10^n) == 0 && scale - n >= preferredScale}

Suggestion:

        // scale - preferredScale >= remainingZeros >= max{n : (intVal % 10^n) == 0 && n <= scale - preferredScale}

is clearer IMO.

src/java.base/share/classes/java/math/BigDecimal.java line 5274:

> 5272:         remainingZeros = Math.min(remainingZeros, maxPowsOf5);
> 5273: 
> 5274:         BigInteger[] qr; // quotient-remainder pair

The algorithm is clever, but it took me some time to "reverse-engineer" to understand how it works.

If this is described somewhere in the literature, please add a reference.
Otherwise, it needs an explanation in form of comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797255797
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797255851
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797256459

From aturbanov at openjdk.org  Fri Oct 11 17:48:15 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 11 Oct 2024 17:48:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v35]
In-Reply-To: <oQ2jxvi26vsJij2LCuQu0iyT3rlPyq1dlbQAW-zNcTM=.68c8d289-c1c2-45e9-b8d5-66e19e2f6b96@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <oQ2jxvi26vsJij2LCuQu0iyT3rlPyq1dlbQAW-zNcTM=.68c8d289-c1c2-45e9-b8d5-66e19e2f6b96@github.com>
Message-ID: <_YW4ErX8vcKHJ_jZGKQB07w2qSBBCUBnS7Rt0I0ckQI=.a07b39ff-abd1-4cf5-901e-f3dde91c6642@github.com>

On Thu, 10 Oct 2024 20:36:26 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refining mathematical definition of remainingZeros

src/java.base/share/classes/java/math/BigDecimal.java line 5331:

> 5329:      */
> 5330:     private static BigDecimal stripZerosToMatchScale(BigInteger intVal, long intCompact, int scale, long preferredScale) {
> 5331:         if(intCompact!=INFLATED) {

Suggestion:

        if (intCompact != INFLATED) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797261119

From liach at openjdk.org  Fri Oct 11 18:02:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 18:02:40 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes [v3]
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <zGJMKOsVbOGhJN4EHEjFKEZ_dkfJdnW86TeuPK9qWlI=.2c0b6aa0-6b88-45f6-9139-92c35ac6bb3a@github.com>

> Please review this change that adds a new dynamic proxies implementation as hidden classes.
> 
> Summary:
> 1. Adds new implementation which can be `-Djdk.reflect.useHiddenProxy=true` for early adoption.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Flip flags, hidden is enabled only by choice
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - Missing changes to commit
 - Condense legacy and modern impl
 - Clean up
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - Cleanup...
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
 - ... and 3 more: https://git.openjdk.org/jdk/compare/7276a1be...2cc88f2b

-------------

Changes: https://git.openjdk.org/jdk/pull/19356/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19356&range=02
  Stats: 81 lines in 6 files changed: 53 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/19356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19356/head:pull/19356

PR: https://git.openjdk.org/jdk/pull/19356

From kbarrett at openjdk.org  Fri Oct 11 18:08:15 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Oct 2024 18:08:15 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
Message-ID: <yH_gGFizqXCy6EZ5cXYr99x0nGu99-tsGlct6b8NVr8=.cb7f5798-1959-43a6-8869-a40b24d634dd@github.com>

On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8340801
>  - move ub.h to a better location
>  - remove ubsan changes from jni_md.h
>  - JDK-8340801

Not a review, just commenting.

I very much support the work @MBaesken has done with ubsan in HotSpot.
There's a bit of a chicken or egg problem with this kind of thing.  ubsan
isn't really usable and in any way supported or supportable until the code has
been made pretty much ubsan-clean.  Matthias has made substantial progress
toward that for HotSpot, and I thank him for this effort.

There are currently four uses of the disabling attribute in HotSpot.  Two are
for intentional things (writing to address zero intentionally, for testing
signal handling and the like).  One is for a known issue that is being worked
on, with an associated JBS issue; the attribute is being used to reduce
testing noise in the meantime.  The fourth is related to some of my recent
work (adjacent to, not caused by), and something that I think ought to be
fixed.  I'll be filing a JBS issue.  Along the way there have been a
substantial number of real bugs uncovered and addressed.

My only complaint has been a tendency to be a bit too quick to reach for the
disabling attribute, without sufficient analysis and attempt to resolve in a
way that corrects the problem.  Of the issues I've observed, the result of a
real fix nearly always ben a straight-up improvement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2407899603

From liach at openjdk.org  Fri Oct 11 18:10:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 18:10:14 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes [v3]
In-Reply-To: <zGJMKOsVbOGhJN4EHEjFKEZ_dkfJdnW86TeuPK9qWlI=.2c0b6aa0-6b88-45f6-9139-92c35ac6bb3a@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <zGJMKOsVbOGhJN4EHEjFKEZ_dkfJdnW86TeuPK9qWlI=.2c0b6aa0-6b88-45f6-9139-92c35ac6bb3a@github.com>
Message-ID: <BZrY0l2Zu8u7uGs2PXmPQeqaOTh5o4UrxixJqPqd-_w=.a2a15ae3-ee30-4f14-9eff-a61449d98be3@github.com>

On Fri, 11 Oct 2024 18:02:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this change that adds a new dynamic proxies implementation as hidden classes.
>> 
>> Summary:
>> 1. Adds new implementation which can be `-Djdk.reflect.useHiddenProxy=true` for early adoption.
>> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
>> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
>> 
>> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>  - Flip flags, hidden is enabled only by choice
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>  - Missing changes to commit
>  - Condense legacy and modern impl
>  - Clean up
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>  - Cleanup...
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/7276a1be...2cc88f2b

Updated to merge latest master. It seems the hidden class implementation passes existing serialization tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2407902076

From duke at openjdk.org  Fri Oct 11 18:11:17 2024
From: duke at openjdk.org (Markus KARG)
Date: Fri, 11 Oct 2024 18:11:17 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <l5C3bic8S9xA_bFq42MmDq4DosACBLLmBGmtnZ-zd3A=.2dbbc9b5-af13-4599-9841-5d2a53f414b9@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <8zB-zdwFTQyf2gHWYK5q8nKLV5lOhYueOrk_lpPYH6Y=.4e9889ab-6b4b-4c6a-b243-a80d1c094602@github.com>
 <ypaNksQS3D5SXEzbEoZNvPhJsr0WoGmRiW2F07ijQTc=.f3f00676-f17f-4cf9-9a93-326295e36e34@github.com>
 <ncBcFsD7FZ9sCkiqawLmwwr0ZID1f1T44-hvzncNOoY=.fe3a8523-fb9e-4d3b-9f1a-6862435b6d36@github.com>
 <l5C3bic8S9xA_bFq42MmDq4DosACBLLmBGmtnZ-zd3A=.2dbbc9b5-af13-4599-9841-5d2a53f414b9@github.com>
Message-ID: <CPzzriUvkFAMdDau-J9rt0ODQdnVdfs_s2KAV4JBb7E=.a721a336-0043-4dfe-ae52-0cb465ca58c9@github.com>

On Fri, 11 Oct 2024 15:21:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > I have slightly adapted the copy loop to allow CPUs to use solely single-operand INC within the loop instead of dual-operand ADD.
> 
> Did you measure a performance improvement? Compiler optimizations are more productive than spot source changes.

No and I do not intent to do, as it was ja a code simplification I have seen, not an engineering target actively developed to reach max performance. Did you measure a performance drawback of the latest code? Maybe Compiler optimization is less productive in that particular case, due to the constraints mentioned?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2407903343

From duke at openjdk.org  Fri Oct 11 18:25:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 18:25:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
Message-ID: <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>

On Fri, 11 Oct 2024 17:29:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> I'll have to check...
>> ... tomorrow ;-)
>
> IIUC, the code assumes that the floating-point computation `Math.ceil(intVal.bitLength() * LOG_5_OF_2)` has the same value as the mathematical &lceil; `intVal.bitLength()` &times; log5(2) &rceil;.
> I don't think this is safe, as it might happen that the computed and mathematical values are off by &plusmn;1.
> To ensure 5^`maxPowsOf5` >= `intVal` (that is, maxPowsOf5 >= log5(intVal)) it would be more prudent to have
> 
> long maxPowsOf5 = (long) Math.ceil(intVal.bitLength() * LOG_5_OF_2) + 1;
> 
> 
> But I think what you really want is maybe to meet 5^`maxPowsOf5` <= `intVal` < 5^(`maxPowsOf5` + 1) instead?

Actually, if we reason in terms of "ulp vs precision", the computation should be safe: `Math.log()`'s results are within 1 ulp of the exact result, and the floating point operations are a multiplication and a division. The division to compute `LOG_5_OF_2` costs 1/2 ulp plus the errors of the operands, so 2.5 ulps. Same for multiplication, but `intVal.bitLength()` has an exact `double` value, so the total roundoff error of `intVal.bitLength() * LOG_5_OF_2` is 3 ulps. Since the integer part of `intVal.bitLength() * LOG_5_OF_2` is representable with 31 bits, and double has 53 bits of precision, we can reasonably say that `Math.ceil()` can always guarantee `maxPowsOf5 >= log5(intVal)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797292843

From duke at openjdk.org  Fri Oct 11 18:29:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 18:29:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v35]
In-Reply-To: <oSZSKhsyMbgScMdrl2onFHBvDKiMOQamfxbulN5M8Ps=.37894d09-5f63-423a-bf0c-bc1d5594d799@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <oQ2jxvi26vsJij2LCuQu0iyT3rlPyq1dlbQAW-zNcTM=.68c8d289-c1c2-45e9-b8d5-66e19e2f6b96@github.com>
 <oSZSKhsyMbgScMdrl2onFHBvDKiMOQamfxbulN5M8Ps=.37894d09-5f63-423a-bf0c-bc1d5594d799@github.com>
Message-ID: <SFfdggKQejb0TobuMD5V2vbkT6_Bw8veG6HggHBiEXs=.8db6f278-7c67-4354-8ae7-5a65c1e4470c@github.com>

On Fri, 11 Oct 2024 17:40:21 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refining mathematical definition of remainingZeros
>
> src/java.base/share/classes/java/math/BigDecimal.java line 5274:
> 
>> 5272:         remainingZeros = Math.min(remainingZeros, maxPowsOf5);
>> 5273: 
>> 5274:         BigInteger[] qr; // quotient-remainder pair
> 
> The algorithm is clever, but it took me some time to "reverse-engineer" to understand how it works.
> 
> If this is described somewhere in the literature, please add a reference.
> Otherwise, it needs an explanation in form of comments.

I don't know any description of the repeated squares technique applied for stripping zeros in the literature...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797298269

From rgiulietti at openjdk.org  Fri Oct 11 18:34:18 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Oct 2024 18:34:18 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
Message-ID: <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>

On Fri, 11 Oct 2024 18:20:50 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> IIUC, the code assumes that the floating-point computation `Math.ceil(intVal.bitLength() * LOG_5_OF_2)` has the same value as the mathematical &lceil; `intVal.bitLength()` &times; log5(2) &rceil;.
>> I don't think this is safe, as it might happen that the computed and mathematical values are off by &plusmn;1.
>> To ensure 5^`maxPowsOf5` >= `intVal` (that is, maxPowsOf5 >= log5(intVal)) it would be more prudent to have
>> 
>> long maxPowsOf5 = (long) Math.ceil(intVal.bitLength() * LOG_5_OF_2) + 1;
>> 
>> 
>> But I think what you really want is maybe to meet 5^`maxPowsOf5` <= `intVal` < 5^(`maxPowsOf5` + 1) instead?
>
> Actually, if we reason in terms of "ulp vs precision", the computation should be safe: `Math.log()`'s results are within 1 ulp of the exact result, and the floating point operations are a multiplication and a division. The division to compute `LOG_5_OF_2` costs 1/2 ulp plus the errors of the operands, so 2.5 ulps. Same for multiplication, but `intVal.bitLength()` has an exact `double` value, so the total roundoff error of `intVal.bitLength() * LOG_5_OF_2` is 3 ulps. Since the integer part of `intVal.bitLength() * LOG_5_OF_2` is representable with 31 bits, and double has 53 bits of precision, we can reasonably say that `Math.ceil()` can always guarantee `maxPowsOf5 >= log5(intVal)`.

If the mathematical value v of the product and its floating-point value fp are separated by an integer i in such a way that fp < i < v, we are in trouble: the ceilings will be different, even if the values are very close to each other.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797302468

From rgiulietti at openjdk.org  Fri Oct 11 18:44:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Oct 2024 18:44:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
Message-ID: <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>

On Fri, 11 Oct 2024 18:32:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Actually, if we reason in terms of "ulp vs precision", the computation should be safe: `Math.log()`'s results are within 1 ulp of the exact result, and the floating point operations are a multiplication and a division. The division to compute `LOG_5_OF_2` costs 1/2 ulp plus the errors of the operands, so 2.5 ulps. Same for multiplication, but `intVal.bitLength()` has an exact `double` value, so the total roundoff error of `intVal.bitLength() * LOG_5_OF_2` is 3 ulps. Since the integer part of `intVal.bitLength() * LOG_5_OF_2` is representable with 31 bits, and double has 53 bits of precision, we can reasonably say that `Math.ceil()` can always guarantee `maxPowsOf5 >= log5(intVal)`.
>
> If the mathematical value v of the product and its floating-point value fp are separated by an integer i in such a way that fp < i < v, we are in trouble: the ceilings will be different, even if the values are very close to each other.

One might prove that this cannot happen for a specific approximation of log5(2), like `LOG_5_OF_2` and for all bit length, but I don't think it is worthwhile to put too much effort on this, given the performance figures.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797310959

From duke at openjdk.org  Fri Oct 11 18:54:16 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 18:54:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
 <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
Message-ID: <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8VaWpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>

On Fri, 11 Oct 2024 18:41:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> If the mathematical value v of the product and its floating-point value fp are separated by an integer i in such a way that fp < i < v, we are in trouble: the ceilings will be different, even if the values are very close to each other.
>
> One might prove that this cannot happen for a specific approximation of log5(2), like `LOG_5_OF_2` and for all bit length, but I don't think it is worthwhile to put too much effort on this, given the performance figures.

> If the mathematical value v of the product and its floating-point value fp are separated by an integer i in such a way that fp < i < v, we are in trouble: the ceilings will be different, even if the values are very close to each other.

In that unlikely case, we would have `maxPowsOf5 >= floor(log5(intVal))`, which is still acceptable as an upper bound.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797319077

From duke at openjdk.org  Fri Oct 11 18:58:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 18:58:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8VaWpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
 <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
 <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8Va
 Wpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>
Message-ID: <7uxM6qDzFNgXhPEu4JKOyxYmo33G37cXeVPNzr80v8s=.a33f0bf8-a42a-4590-b00c-380ffce95ffd@github.com>

On Fri, 11 Oct 2024 18:51:21 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> One might prove that this cannot happen for a specific approximation of log5(2), like `LOG_5_OF_2` and for all bit length, but I don't think it is worthwhile to put too much effort on this, given the performance figures.
>
>> If the mathematical value v of the product and its floating-point value fp are separated by an integer i in such a way that fp < i < v, we are in trouble: the ceilings will be different, even if the values are very close to each other.
> 
> In that unlikely case, we would have `maxPowsOf5 >= floor(log5(intVal))`, which is still acceptable as an upper bound.

And considering that `Math.round()` rounds to the closest integer, it also should assure `maxPowsOf5 >= floor(log5(intVal))`, giving a better upper bound.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797322641

From rgiulietti at openjdk.org  Fri Oct 11 19:04:17 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Oct 2024 19:04:17 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <7uxM6qDzFNgXhPEu4JKOyxYmo33G37cXeVPNzr80v8s=.a33f0bf8-a42a-4590-b00c-380ffce95ffd@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
 <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
 <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8Va
 Wpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>
 <7uxM6qDzFNgXhPEu4JKOyxYmo33G37cXeVPNzr80v8s=.a33f0bf8-a42a-4590-b00c-380ffce95ffd@github.com>
Message-ID: <rxumshZ2nBnn7FIPsrixtBgbw2qJ_m8DN2JXURamN5E=.071cbc01-67cb-47b9-88ad-d73265381bd0@github.com>

On Fri, 11 Oct 2024 18:55:28 GMT, fabioromano1 <duke at openjdk.org> wrote:

>>> If the mathematical value v of the product and its floating-point value fp are separated by an integer i in such a way that fp < i < v, we are in trouble: the ceilings will be different, even if the values are very close to each other.
>> 
>> In that unlikely case, we would have `maxPowsOf5 >= floor(log5(intVal))`, which is still acceptable as an upper bound.
>
> And considering that `Math.round()` rounds to the closest integer, it also should assure `maxPowsOf5 >= floor(log5(intVal))`, giving a better upper bound.

As I asked above, what's the property that should hold?
5^`maxPowsOf5` <= `intVal` < 5^(`maxPowsOf5` + 1)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797327607

From rgiulietti at openjdk.org  Fri Oct 11 19:12:18 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Oct 2024 19:12:18 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <rxumshZ2nBnn7FIPsrixtBgbw2qJ_m8DN2JXURamN5E=.071cbc01-67cb-47b9-88ad-d73265381bd0@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
 <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
 <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8Va
 Wpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>
 <7uxM6qDzFNgXhPEu4JKOyxYmo33G37cXeVPNzr80v8s=.a33f0bf8-a42a-4590-b00c-380ffce95ffd@github.com>
 <rxumshZ2nBnn7FIPsrixtBgbw2qJ_m8DN2JXURamN5E=.071cbc01-67cb-47b9-88ad-d73265381bd0@github.com>
Message-ID: <UctmqrOcu4fNsCJBHHwvGLrPDJNfaV86yu7gyiqmoVM=.c7bc5d04-cce2-4efc-a683-4c84a4c24849@github.com>

On Fri, 11 Oct 2024 19:01:19 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> And considering that `Math.round()` rounds to the closest integer, it also should assure `maxPowsOf5 >= floor(log5(intVal))`, giving a better upper bound.
>
> As I asked above, what's the property that should hold?
> 5^`maxPowsOf5` <= `intVal` < 5^(`maxPowsOf5` + 1)?

Sorry, this is not a good question, disregard.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797334513

From duke at openjdk.org  Fri Oct 11 19:29:21 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 19:29:21 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <UctmqrOcu4fNsCJBHHwvGLrPDJNfaV86yu7gyiqmoVM=.c7bc5d04-cce2-4efc-a683-4c84a4c24849@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
 <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
 <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8Va
 Wpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>
 <7uxM6qDzFNgXhPEu4JKOyxYmo33G37cXeVPNzr80v8s=.a33f0bf8-a42a-4590-b00c-380ffce95ffd@github.com>
 <rxumshZ2nBnn7FIPsrixtBgbw2qJ_m8DN2JXURamN5E=.071cbc01-67cb-47b9-88ad-d73265381bd0@github.com>
 <UctmqrOcu4fNsCJBHHwvGLrPDJNfaV86yu7gyiqmoVM=.c7bc5d04-cce2-4efc-a683-4c84a4c24849@github.com>
Message-ID: <YMWxtGgnkRvH9fkZeoiEQ4wfJhR-gwGn83Mo24DbHnA=.6bce9fd2-394b-4bb7-896e-31714e363ccf@github.com>

On Fri, 11 Oct 2024 19:09:50 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> As I asked above, what's the property that should hold?
>> 5^`maxPowsOf5` <= `intVal` < 5^(`maxPowsOf5` + 1)?
>
> Sorry, this is not a good question, disregard.

> As I asked above, what's the property that should hold? 5^`maxPowsOf5` <= `intVal` < 5^(`maxPowsOf5` + 1)?

Yes, as `floor(log5(intVal)) == max{integer n : 5^n <= intVal}`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797347733

From rgiulietti at openjdk.org  Fri Oct 11 19:41:16 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 11 Oct 2024 19:41:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <YMWxtGgnkRvH9fkZeoiEQ4wfJhR-gwGn83Mo24DbHnA=.6bce9fd2-394b-4bb7-896e-31714e363ccf@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
 <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
 <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8Va
 Wpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>
 <7uxM6qDzFNgXhPEu4JKOyxYmo33G37cXeVPNzr80v8s=.a33f0bf8-a42a-4590-b00c-380ffce95ffd@github.com>
 <rxumshZ2nBnn7FIPsrixtBgbw2qJ_m8DN2JXURamN5E=.071cbc01-67cb-47b9-88ad-d73265381bd0@github.com>
 <UctmqrOcu4fNsCJBHHwvGLrPDJNfaV86yu7gyiqmoVM=.c7bc5d04-cce2-4efc-a683-4c84a4c24849@github.com>
 <YMWxtGgnkRvH9fkZeoiEQ4wfJhR-gwGn83Mo24DbHnA=.6bce9fd2-394b-4bb7-896e-31714e363ccf@github.com>
Message-ID: <81Q7fz7D00F7lvclJ6GtlJZQqhSmBbJY54_4K6C8tqA=.adb0525d-ce29-40ae-a978-2c521a1749c1@github.com>

On Fri, 11 Oct 2024 19:25:51 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Sorry, this is not a good question, disregard.
>
>> As I asked above, what's the property that should hold? 5^`maxPowsOf5` <= `intVal` < 5^(`maxPowsOf5` + 1)?
> 
> Yes, as `floor(log5(intVal)) == max{integer n : 5^n <= intVal}`.

This doesn't say much about `maxPowsOf5`, though. You are not using `intVal` but 2^`bitLength` > `intVal` in the computation of `maxPowsOf5`.
So maybe the property you are looking for is
`maxPowsOf5` - 1 <= log5(intVal) < `maxPowsOf5` || `maxPowsOf5` <= log5(intVal) < `maxPowsOf5` + 1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797357351

From duke at openjdk.org  Fri Oct 11 19:48:19 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 19:48:19 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <81Q7fz7D00F7lvclJ6GtlJZQqhSmBbJY54_4K6C8tqA=.adb0525d-ce29-40ae-a978-2c521a1749c1@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
 <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
 <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8Va
 Wpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>
 <7uxM6qDzFNgXhPEu4JKOyxYmo33G37cXeVPNzr80v8s=.a33f0bf8-a42a-4590-b00c-380ffce95ffd@github.com>
 <rxumshZ2nBnn7FIPsrixtBgbw2qJ_m8DN2JXURamN5E=.071cbc01-67cb-47b9-88ad-d73265381bd0@github.com>
 <UctmqrOcu4fNsCJBHHwvGLrPDJNfaV86yu7gyiqmoVM=.c7bc5d04-cce2-4efc-a683-4c84a4c24849@github.com>
 <YMWxtGgnkRvH9fkZeoiEQ4wfJhR-gwGn83Mo24DbHnA=.6bce9fd2-394b-4bb7-896e-31714e363ccf@github.com>
 <81Q7fz7D00F7lvclJ6GtlJZQqhSmBbJY54_4K6C8tqA=.adb0525d-ce29-40ae-a978-2c521a1749c1@github.com>
Message-ID: <J6PbJaXia4zORkzm2RrAcZGLXd876aHqIkbBti94szU=.c078eb96-84e7-47df-8ed6-1f0e8cda0601@github.com>

On Fri, 11 Oct 2024 19:38:03 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This doesn't say much about `maxPowsOf5`, though. You are not using `intVal` but 2^`bitLength` > `intVal` in the computation of `maxPowsOf5`. So maybe the property you are looking for is `maxPowsOf5` - 1 <= log5(intVal) < `maxPowsOf5` || `maxPowsOf5` <= log5(intVal) < `maxPowsOf5` + 1

Actually, it is sufficient that `maxPowsOf5 >= max{integer n : 5^n <= intVal}` to get a correct upper bound, not that are equal. But the closer they are, the better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797363059

From duke at openjdk.org  Fri Oct 11 20:12:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 20:12:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v33]
In-Reply-To: <J6PbJaXia4zORkzm2RrAcZGLXd876aHqIkbBti94szU=.c078eb96-84e7-47df-8ed6-1f0e8cda0601@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <N20VYg4hZ_tQPCwPezfBVkHFa77ft7nGtIOkj3um3oE=.d3b8876d-0888-428e-a8fd-0e199b6932e6@github.com>
 <TW8LUn0OfQWWkX2WPH1-Ut94UQVwUW2F4sTIrm4deXc=.77197e2a-ccf3-483b-bfda-e823153a3367@github.com>
 <VaL4hZ3fVpKRXGMxjKSwcpFmAX_cPykDcoZ5JAJEoOM=.f7f2abfa-f9e0-4fcc-b593-ec172087c773@github.com>
 <ddS6ygxpHPKQV6Ng8ov0gLvnxXpFQwKCGlJWZ0BuQLQ=.121062ff-6001-4d31-b910-80a65ee6ede6@github.com>
 <FYirJRJl1O4ZZg3H3pcUNvaEhrEwrfwJVXLgOUpVd4c=.cf59ca52-278c-45dd-9054-f8d1788816d3@github.com>
 <3ekCC8TRMvC44FA9kQGWI9UVZiw3rD0fHtFTjU4Oh9Q=.56ca73fd-4865-4e7b-9024-c09817d4dbb2@github.com>
 <edcYXldc48cgY3vdh6-nts9LfO_oYNWthgVdxhj8h5U=.e7d65265-96e5-44b9-8f01-15b718c07fae@github.com>
 <4hDzKfKkT_oNosQvnMK4SfwvH4IqXfnS9Eso53eAnuw=.86febc19-0141-4b2a-956f-89fe9b7889f1@github.com>
 <DJKX9EQiWKbLB9-tgR2fWQ0zn6-rzj7-_5rlULZfIyY=.708904b4-6586-428a-a843-6ff3eb8a1338@github.com>
 <DJQquEQNqDQYMqbstSiPfEkqY2zagtUu8Va
 Wpm9fstc=.811b16a7-f4ba-4155-a062-167913c035ea@github.com>
 <7uxM6qDzFNgXhPEu4JKOyxYmo33G37cXeVPNzr80v8s=.a33f0bf8-a42a-4590-b00c-380ffce95ffd@github.com>
 <rxumshZ2nBnn7FIPsrixtBgbw2qJ_m8DN2JXURamN5E=.071cbc01-67cb-47b9-88ad-d73265381bd0@github.com>
 <UctmqrOcu4fNsCJBHHwvGLrPDJNfaV86yu7gyiqmoVM=.c7bc5d04-cce2-4efc-a683-4c84a4c24849@github.com>
 <YMWxtGgnkRvH9fkZeoiEQ4wfJhR-gwGn83Mo24DbHnA=.6bce9fd2-394b-4bb7-896e-31714e363ccf@github.com>
 <81Q7fz7D00F7lvclJ6GtlJZQqhSmBbJY54_4K6C8tqA=.adb0525d-ce29-40ae-a978-2c521a1749c1@github.com>
 <J6PbJaXia4zORkzm2RrAcZGLXd876aHqIkbBti94szU=.c078eb96-84e7-47df-8ed6-1f0e8cda0601@github.com>
Message-ID: <gkeMw9OCgiYH87vX2YO7hXznonagvqQh0pXxTh9d9UA=.28697cbc-93a8-4274-a741-3e15dff4b530@github.com>

On Fri, 11 Oct 2024 19:45:23 GMT, fabioromano1 <duke at openjdk.org> wrote:

> This doesn't say much about `maxPowsOf5`, though. You are not using `intVal` but 2^`bitLength` > `intVal` in the computation of `maxPowsOf5`. So maybe the property you are looking for is `maxPowsOf5` - 1 <= log5(intVal) < `maxPowsOf5` || `maxPowsOf5` <= log5(intVal) < `maxPowsOf5` + 1

To clarify as much as possible, the weakest property that `maxPowsOf5` must satisfy is:
`maxPowsOf5 >= max{integer n : intVal % 5^n == 0}`.
Clearly, it is true that `max{integer n : 5^n <= intVal} >= max{integer n : intVal % 5^n == 0}`;
and since `floor(log5(intVal)) == max{integer n : 5^n <= intVal}`,
it follows that `maxPowsOf5 >= floor(log5(intVal)) ==> maxPowsOf5 >= max{integer n : intVal % 5^n == 0}.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1797381043

From rriggs at openjdk.org  Fri Oct 11 20:13:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 11 Oct 2024 20:13:16 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
Message-ID: <B9UQwLBw_A2f7JCNzPUEIqjCWuvEGS-iYgLrfTED_Tk=.6a5f2188-8ae4-4a72-9802-14c4210caa6b@github.com>

On Thu, 10 Oct 2024 21:10:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   inc should be faster than add on most CPUs

That's fine, but talking about performance improvements because of what you think the compiler will do isn't productive.
Make the source clear and maintainable and low maintenance.  tnx

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2408060897

From duke at openjdk.org  Fri Oct 11 20:29:18 2024
From: duke at openjdk.org (Markus KARG)
Date: Fri, 11 Oct 2024 20:29:18 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <B9UQwLBw_A2f7JCNzPUEIqjCWuvEGS-iYgLrfTED_Tk=.6a5f2188-8ae4-4a72-9802-14c4210caa6b@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <B9UQwLBw_A2f7JCNzPUEIqjCWuvEGS-iYgLrfTED_Tk=.6a5f2188-8ae4-4a72-9802-14c4210caa6b@github.com>
Message-ID: <dXRO-rg104qsEyaihEzwZ9qxKo2Gy7lHzBUE6z-A6aY=.1c52c2b6-bb99-49b1-b26d-df255c56403d@github.com>

On Fri, 11 Oct 2024 20:10:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> That's fine, but talking about performance improvements because of what you think the compiler will do isn't productive. Make the source clear and maintainable and low maintenance. tnx

Uhm... actually I thought my change *made* it clear and maintainable, as now the loop runs from start to end instead from zero to count ?. Anyways, I have no strong feelings here. If you like it more to iterate from zero to count then I simply can undo the commit (even if I personally think that is *less* understandable).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2408078782

From duke at openjdk.org  Fri Oct 11 20:46:15 2024
From: duke at openjdk.org (Markus KARG)
Date: Fri, 11 Oct 2024 20:46:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <ZN3g8VnTD_WeXq1wSXxHg9kLGqOjKJ52tC39jxyoRRM=.12cc20e1-b64c-47b3-9eb3-ccea098b924e@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <ZN3g8VnTD_WeXq1wSXxHg9kLGqOjKJ52tC39jxyoRRM=.12cc20e1-b64c-47b3-9eb3-ccea098b924e@github.com>
Message-ID: <0Rk-MiIl8MPyV6Ji1WZDznw_ykBe-GsEPhEcumZhIvo=.df0a2082-995c-4707-8b78-b827a330e954@github.com>

On Wed, 9 Oct 2024 18:05:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - assertThrows instead of expectedExceptions
>>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> Wiki pages such as https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request are good starting points for CSRs.
> 
> CSR review will look at CSRs listed at https://bugs.openjdk.org/secure/Dashboard.jspa?selectPageId=17313. To finalize a CSR for review, you should set your fix version; I fixed that when I marked myself as a reviewer on the CSR.
> 
> Also note that the CSR lead might be unavailable the next few days, so the review will wait for a bit. Meanwhile, it's good for other experienced reviewers like Alan to review the CSR too.

@liach Just to make it clear: Thumbs up for "current code *is* more understandible" or thumbs up for "undo last commit"? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2408097139

From duke at openjdk.org  Fri Oct 11 21:46:26 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 11 Oct 2024 21:46:26 GMT
Subject: RFR: 8317356: Test ClassFile API if it deals with nulls correctly
 across the whole API [v2]
In-Reply-To: <4N8U8IZlBtCnhyvamwRyjGP-PtLeEJJ1ZWFFNAGjp0E=.03112658-2220-4cf2-a144-f78c3a478720@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
 <4N8U8IZlBtCnhyvamwRyjGP-PtLeEJJ1ZWFFNAGjp0E=.03112658-2220-4cf2-a144-f78c3a478720@github.com>
Message-ID: <Mj2p9E-c7VFZcwDGcNzZ9aaYWX_IRYh0q3J1-EqomEI=.42afaaf4-4041-4bf8-9314-089cda3a6b80@github.com>

On Fri, 11 Oct 2024 16:21:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
>> 
>> Notes:
>> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
>> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
>> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asotona review remarks

Since this?PR no?longer adds?a?test, the?issue should?probably be?renamed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21458#issuecomment-2408158068

From jlu at openjdk.org  Fri Oct 11 22:23:42 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 11 Oct 2024 22:23:42 GMT
Subject: RFR: 8341445: DecimalFormatSymbols setters should throw NPE [v4]
In-Reply-To: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
Message-ID: <lOTeegOFQ1CPt8HyJT0bvT8kUBiWTVFauivzqMRgMcU=.209911ea-67de-4e82-aa78-961b42b92ce1@github.com>

> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols. As certain setters did not throw NPE, this allowed for NPE in the equality method. This PR now updates the setters to throw NPE.
> 
> In addition to the NPEs, there is also a behavioral change that `setInternationalCurrencySymbol` no longer sets currency to null if the `currencyCode` is invalid. Instead, it simply does not update `currency`. This must be done, because we do not want to allow nullable instance variables post `initalizeCurrency`.

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/21315/files
  - new: https://git.openjdk.org/jdk/pull/21315/files/91b1c78f..d0686b35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21315&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21315&range=02-03

  Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21315/head:pull/21315

PR: https://git.openjdk.org/jdk/pull/21315

From duke at openjdk.org  Fri Oct 11 22:32:43 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 22:32:43 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v36]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <ay68GbOzsk04keVOHXRg2xNJyks4QVTOTJIpa-xoS1g=.aacd9fdd-a7c6-472b-82e9-2b885fe79b7c@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/2e2c042e..b30f5a35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=34-35

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From liach at openjdk.org  Fri Oct 11 22:49:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 22:49:13 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v7]
In-Reply-To: <ZN3g8VnTD_WeXq1wSXxHg9kLGqOjKJ52tC39jxyoRRM=.12cc20e1-b64c-47b3-9eb3-ccea098b924e@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <JaPfFThHEVxGMfCovd277SB5vsH_qyaRIzhWll_6uLA=.13cceb31-f16a-4992-b687-e8de8f1c0319@github.com>
 <ZN3g8VnTD_WeXq1wSXxHg9kLGqOjKJ52tC39jxyoRRM=.12cc20e1-b64c-47b3-9eb3-ccea098b924e@github.com>
Message-ID: <xMIZ9aOaTjpyeiqutE3jUnPyOJYQ8I2PFvKa1VHZLKM=.1b5bf4be-f061-401f-a1df-61430b11b254@github.com>

On Wed, 9 Oct 2024 18:05:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - assertThrows instead of expectedExceptions
>>  - ordered jtreg tags according recommendation in https://openjdk.org/jtreg/tag-spec.html#ORDER
>
> Wiki pages such as https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request are good starting points for CSRs.
> 
> CSR review will look at CSRs listed at https://bugs.openjdk.org/secure/Dashboard.jspa?selectPageId=17313. To finalize a CSR for review, you should set your fix version; I fixed that when I marked myself as a reviewer on the CSR.
> 
> Also note that the CSR lead might be unavailable the next few days, so the review will wait for a bit. Meanwhile, it's good for other experienced reviewers like Alan to review the CSR too.

> @liach Just to make it clear: Thumbs up for "current code _is_ more understandible" or thumbs up for "undo last commit"? ?

My thumb up is for this:

> Anyways, I have no strong feelings here

This debate is really pointless bikeshedding. Either way is fine to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2408209652

From rriggs at openjdk.org  Fri Oct 11 22:49:15 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 11 Oct 2024 22:49:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
Message-ID: <8--zO54t6fGJpFLCpOscNnsEp7BhNwFHFzKFkfHPgT8=.6a0bb881-0e04-4a42-879f-03c04b2a4ab0@github.com>

On Thu, 10 Oct 2024 21:10:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   inc should be faster than add on most CPUs

src/java.base/share/classes/java/io/Reader.java line 212:

> 210:                     default -> {
> 211:                         for (int i = next, j = next + n; i < j;)
> 212:                             cbuf[off++] = cs.charAt(i++);

The single increment is fine and readable. 
Introducing a local variable for the end (j) seems unnecessary and its name is not indicative of its purpose as a limit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1797417092

From duke at openjdk.org  Fri Oct 11 22:49:15 2024
From: duke at openjdk.org (Markus KARG)
Date: Fri, 11 Oct 2024 22:49:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <8--zO54t6fGJpFLCpOscNnsEp7BhNwFHFzKFkfHPgT8=.6a0bb881-0e04-4a42-879f-03c04b2a4ab0@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <8--zO54t6fGJpFLCpOscNnsEp7BhNwFHFzKFkfHPgT8=.6a0bb881-0e04-4a42-879f-03c04b2a4ab0@github.com>
Message-ID: <tQy1sEgbwsdcLpIFN4YkZeH8_PBj3kXWBKmhU3Odv2U=.580d2b74-7166-4835-8a29-86dc8401eda2@github.com>

On Fri, 11 Oct 2024 20:56:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   inc should be faster than add on most CPUs
>
> src/java.base/share/classes/java/io/Reader.java line 212:
> 
>> 210:                     default -> {
>> 211:                         for (int i = next, j = next + n; i < j;)
>> 212:                             cbuf[off++] = cs.charAt(i++);
> 
> The single increment is fine and readable. 
> Introducing a local variable for the end (j) seems unnecessary and its name is not indicative of its purpose as a limit.

Uhm... actually that is a quite common pattern we even teach people everyday, and in the past 30 years none of them had a problem understanding it... ?  Anyways, really I don't see any benefit in this whole discussion, as I said, I have no feelings about that tiny part of this PR at all. Simply post the exact code you want to have and I am fine to put it into place! ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1797420964

From liach at openjdk.org  Fri Oct 11 22:49:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 11 Oct 2024 22:49:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <tQy1sEgbwsdcLpIFN4YkZeH8_PBj3kXWBKmhU3Odv2U=.580d2b74-7166-4835-8a29-86dc8401eda2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <8--zO54t6fGJpFLCpOscNnsEp7BhNwFHFzKFkfHPgT8=.6a0bb881-0e04-4a42-879f-03c04b2a4ab0@github.com>
 <tQy1sEgbwsdcLpIFN4YkZeH8_PBj3kXWBKmhU3Odv2U=.580d2b74-7166-4835-8a29-86dc8401eda2@github.com>
Message-ID: <OFkHVBUlX7Y2vg8LlagWV9hkpzLF8ykiKD-ynlIU_3M=.128d7ba0-089a-43fe-9bb1-32cde09e5d5b@github.com>

On Fri, 11 Oct 2024 21:02:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 212:
>> 
>>> 210:                     default -> {
>>> 211:                         for (int i = next, j = next + n; i < j;)
>>> 212:                             cbuf[off++] = cs.charAt(i++);
>> 
>> The single increment is fine and readable. 
>> Introducing a local variable for the end (j) seems unnecessary and its name is not indicative of its purpose as a limit.
>
> Uhm... actually that is a quite common pattern we even teach people everyday, and in the past 30 years none of them had a problem understanding it... ?  Anyways, really I don't see any benefit in this whole discussion, as I said, I have no feelings about that tiny part of this PR at all. Simply post the exact code you want to have and I am fine to put it into place! ?

I would say this current version is fine: that's how we handle encode/decode loop in classes like `String`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1797478583

From naoto at openjdk.org  Fri Oct 11 23:15:39 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 11 Oct 2024 23:15:39 GMT
Subject: RFR: 8341445: DecimalFormatSymbols setters should throw NPE [v4]
In-Reply-To: <lOTeegOFQ1CPt8HyJT0bvT8kUBiWTVFauivzqMRgMcU=.209911ea-67de-4e82-aa78-961b42b92ce1@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
 <lOTeegOFQ1CPt8HyJT0bvT8kUBiWTVFauivzqMRgMcU=.209911ea-67de-4e82-aa78-961b42b92ce1@github.com>
Message-ID: <ddfbkcGiYWDmwVYPVPrj5yde6JUmWxUj6T6vaA5B4ik=.f776af57-ee08-43f2-8ae4-b3e459091085@github.com>

On Fri, 11 Oct 2024 22:23:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols. As certain setters did not throw NPE, this allowed for NPE in the equality method. This PR now updates the setters to throw NPE.
>> 
>> In addition to the NPEs, there is also a behavioral change that `setInternationalCurrencySymbol` no longer sets currency to null if the `currencyCode` is invalid. Instead, it simply does not update `currency`. This must be done, because we do not want to allow nullable instance variables post `initalizeCurrency`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

Looks good overall. The test can also check the behavioral change in `setInternationalCurrencySymbol()`.

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 767:

> 765:             NaN.equals(other.NaN) &&
> 766:             // Currency fields are lazy. Init via get call to ensure non-null
> 767:             getCurrencySymbol().equals(other.getCurrencySymbol()) &&

Probably the same comment refinement can be applied to the location in `hashCode()`.

test/jdk/java/text/Format/DecimalFormat/SettersShouldThrowNPETest.java line 55:

> 53:             .filter(m -> Modifier.isPublic(m.getModifiers()))
> 54:             .filter(m -> m.getName().startsWith("set"))
> 55:             .filter(m -> Stream.of(m.getParameterTypes()).noneMatch(Class::isPrimitive))

Can consolidate into a single filter()?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21315#pullrequestreview-2363659166
PR Review Comment: https://git.openjdk.org/jdk/pull/21315#discussion_r1797484163
PR Review Comment: https://git.openjdk.org/jdk/pull/21315#discussion_r1797485380

From cjplummer at openjdk.org  Fri Oct 11 23:16:20 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Oct 2024 23:16:20 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v3]
In-Reply-To: <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>
Message-ID: <xL0CLfS6kApk2ez5VIqsGf1YTtAZbIhAwWEj8Mpqlqs=.e4fdb376-5af3-4ada-8512-c8a3c8d95c98@github.com>

On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas 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 tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - Remove XCollectedHeap from HSDB
>  - Fix typo in TestZUncommitEvent.java
>  - Add missing problem-listing
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/df0ae672...e58b4c5a

The serviceability related changes look good. I suppose the 6 or so SA bugs filed against the non-generational ZGC can be closed out. I have a note to myself to go through them and close if appropriate. We have [JDK-8307393](https://bugs.openjdk.org/browse/JDK-8307393) filed for the lack of SA support for generational ZGC, and that is probably the only SA ZGC related issue we need to keep around.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2363665123

From duke at openjdk.org  Fri Oct 11 23:16:50 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 11 Oct 2024 23:16:50 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v37]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <oxGOQvd9N3RRqnfoymZ69WOyU8NBDZQAijC6V5PiGrc=.251b297d-5763-40e0-ba97-5f7f9438ffcd@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added comments explaining the algorithm in more details

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/b30f5a35..dfc282fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=35-36

  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Sat Oct 12 00:45:40 2024
From: duke at openjdk.org (Johny Jose)
Date: Sat, 12 Oct 2024 00:45:40 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b [v3]
In-Reply-To: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
Message-ID: <fde92Kgy8JJIQNwOf-nvTAiwR4jkym_frXREp6gtNhA=.1b6c6858-a117-4bd8-829c-066b489f8e62@github.com>

> Timezone data 2024b changes

Johny Jose has updated the pull request incrementally with one additional commit since the last revision:

  Review changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21265/files
  - new: https://git.openjdk.org/jdk/pull/21265/files/c3238444..b3a092c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21265&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21265&range=01-02

  Stats: 14 lines in 2 files changed: 0 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21265/head:pull/21265

PR: https://git.openjdk.org/jdk/pull/21265

From rsunderbabu at openjdk.org  Sat Oct 12 03:28:17 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sat, 12 Oct 2024 03:28:17 GMT
Subject: Integrated: 8341138: Rename jtreg property docker.support as
 container.support
In-Reply-To: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
Message-ID: <j3p52OjHQUJMh9WD-RGUOS2cth5xigSxmQy0xUVQS80=.9fc9039c-8edc-4291-a1db-2b5c0a00559b@github.com>

On Wed, 9 Oct 2024 14:50:30 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
> 
> Positive Testing:
> tier1,tier2,tier3 - to check stability
> tier5 - to run container tests
> 
> Negative Testing:
> Ran the following groups in hosts where container is not present.
> open/test/hotspot/jtreg/containers/
> open/test/jdk/jdk/internal/platform/docker/
> open/test/jdk/jdk/internal/platform/cgroup/

This pull request has now been integrated.

Changeset: 41ee582d
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41ee582df8c65f2f26b21e46784cf0bc4ece0585
Stats:     54 lines in 26 files changed: 6 ins; 0 del; 48 mod

8341138: Rename jtreg property docker.support as container.support

Reviewed-by: sgehwolf, mseledtsov

-------------

PR: https://git.openjdk.org/jdk/pull/21423

From jpai at openjdk.org  Sat Oct 12 06:36:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 12 Oct 2024 06:36:54 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v2]
In-Reply-To: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
Message-ID: <F8-MUg92JLbt-5BOJW31FCFE3PkJZJA_7-agqNYcOgI=.536990a6-d44c-4e46-94a9-150312e9a090@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 two additional commits since the last revision:

 - 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/3cc3ecd6..d451ea0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=00-01

  Stats: 50272 lines in 797 files changed: 42232 ins; 4309 del; 3731 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  Sat Oct 12 07:00:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 12 Oct 2024 07:00:20 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <OFkHVBUlX7Y2vg8LlagWV9hkpzLF8ykiKD-ynlIU_3M=.128d7ba0-089a-43fe-9bb1-32cde09e5d5b@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <8--zO54t6fGJpFLCpOscNnsEp7BhNwFHFzKFkfHPgT8=.6a0bb881-0e04-4a42-879f-03c04b2a4ab0@github.com>
 <tQy1sEgbwsdcLpIFN4YkZeH8_PBj3kXWBKmhU3Odv2U=.580d2b74-7166-4835-8a29-86dc8401eda2@github.com>
 <OFkHVBUlX7Y2vg8LlagWV9hkpzLF8ykiKD-ynlIU_3M=.128d7ba0-089a-43fe-9bb1-32cde09e5d5b@github.com>
Message-ID: <R4lPycLTFstR11JONFyAUsqkqk1Wyza_QtQmPQALWKs=.697276c5-6276-40d2-a98a-c9ede5b6ff08@github.com>

On Fri, 11 Oct 2024 22:45:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Uhm... actually that is a quite common pattern we even teach people everyday, and in the past 30 years none of them had a problem understanding it... ?  Anyways, really I don't see any benefit in this whole discussion, as I said, I have no feelings about that tiny part of this PR at all. Simply post the exact code you want to have and I am fine to put it into place! ?
>
> I would say this current version is fine: that's how we handle encode/decode loop in classes like `String`.

I agree with Roger - the previous version you had:


for (int i = 0; i < n; i++)
    cbuf[off + i] = cs.charAt(next + i);


was trivial, easy to understand immediately without having to stare at it for a while to see what's being done there, compared to the current version:


for (int i = next, j = next + n; i < j;)
    cbuf[off++] = cs.charAt(i++);

I prefer switching to the former version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1797619050

From duke at openjdk.org  Sat Oct 12 07:47:56 2024
From: duke at openjdk.org (Markus KARG)
Date: Sat, 12 Oct 2024 07:47:56 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Revert 'inc should be faster than add on most CPUs'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/07215bbc..487b9386

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=09-10

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From duke at openjdk.org  Sat Oct 12 07:47:56 2024
From: duke at openjdk.org (Markus KARG)
Date: Sat, 12 Oct 2024 07:47:56 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v10]
In-Reply-To: <R4lPycLTFstR11JONFyAUsqkqk1Wyza_QtQmPQALWKs=.697276c5-6276-40d2-a98a-c9ede5b6ff08@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <Hj1vR82PJL9p15CschPiQItIAjyknVZhxdRKCdtA9hY=.92e433df-418a-41c4-a78a-388d2fddc3d3@github.com>
 <8--zO54t6fGJpFLCpOscNnsEp7BhNwFHFzKFkfHPgT8=.6a0bb881-0e04-4a42-879f-03c04b2a4ab0@github.com>
 <tQy1sEgbwsdcLpIFN4YkZeH8_PBj3kXWBKmhU3Odv2U=.580d2b74-7166-4835-8a29-86dc8401eda2@github.com>
 <OFkHVBUlX7Y2vg8LlagWV9hkpzLF8ykiKD-ynlIU_3M=.128d7ba0-089a-43fe-9bb1-32cde09e5d5b@github.com>
 <R4lPycLTFstR11JONFyAUsqkqk1Wyza_QtQmPQALWKs=.697276c5-6276-40d2-a98a-c9ede5b6ff08@github.com>
Message-ID: <uItotjz8cQI0WXS1Z0xZvs6J3bWc4i4x8nCpjq_VewQ=.b91e1da9-cfa8-473a-a34c-dafcf5167c69@github.com>

On Sat, 12 Oct 2024 06:57:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I would say this current version is fine: that's how we handle encode/decode loop in classes like `String`.
>
> I agree with Roger - the previous version you had:
> 
> 
> for (int i = 0; i < n; i++)
>     cbuf[off + i] = cs.charAt(next + i);
> 
> 
> was trivial, easy to understand immediately without having to stare at it for a while to see what's being done there, compared to the current version:
> 
> 
> for (int i = next, j = next + n; i < j;)
>     cbuf[off++] = cs.charAt(i++);
> 
> I prefer switching to the former version.

switched to previous version to end discussion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1797626955

From duke at openjdk.org  Sat Oct 12 07:50:31 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 12 Oct 2024 07:50:31 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v38]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <lq7Cyuus1oiq5_fNobA5T5Eus5YW8aHKKbsdma6sVv4=.250d9bdc-4975-4176-90f7-a17443287c8d@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Typo correction and code style simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/dfc282fa..7bfff357

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=36-37

  Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Sat Oct 12 07:52:14 2024
From: duke at openjdk.org (Markus KARG)
Date: Sat, 12 Oct 2024 07:52:14 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
Message-ID: <Xn1gTou54rTrS0jfuV5fv7ZCO2CXYW1Ck093pBcGN9Y=.73b72479-1362-4c7e-a5a7-f9d63e9496ba@github.com>

On Sat, 12 Oct 2024 07:47:56 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'inc should be faster than add on most CPUs'

> ... that's how we handle encode/decode loop in classes like `String` ... This debate is really pointless bikeshedding. Either way is fine to me.

Chen, I completely share your opinion here, but as Roger and Jaikiran apparently do have string feelings here, I have simply undone this last commit. This detail discussion is not worth spending any more of everybody's precious time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2408445227

From jpai at openjdk.org  Sat Oct 12 08:27:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 12 Oct 2024 08:27:14 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
Message-ID: <Q_MLcqdXT7rSVRa4fSrCV4n09QewxBVQ6Tw-iwhvgNk=.edd652c2-1840-4402-9fee-71bd3a3ae4aa@github.com>

On Sat, 12 Oct 2024 07:47:56 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'inc should be faster than add on most CPUs'

The latest version of this PR (commit `487b9386`) looks OK to me.

Thank you for the updates related to the review comments. I don't have anything more.
My only other comment was test related - to additionally test the returned `Reader`'s APIs against corner cases like an empty `CharSequence` and a `CharSequence` with `Integer.MAX_VALUE` length. However, if you have run out of time and energy on this one, then the test is fine in the current form. I don't have the necessary bandwidth to propose a test snippet for it right now and we can enhance the test separately at a later date.

test/jdk/java/io/Reader/Of.java line 92:

> 90: 
> 91:     @Test(dataProvider = "readers")
> 92:     public void testReadBII(Reader reader) throws IOException {

What does `BII` in some of these test method names represent?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2363830708
PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2408455268
PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1797632705

From duke at openjdk.org  Sat Oct 12 11:36:15 2024
From: duke at openjdk.org (Markus KARG)
Date: Sat, 12 Oct 2024 11:36:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <Q_MLcqdXT7rSVRa4fSrCV4n09QewxBVQ6Tw-iwhvgNk=.edd652c2-1840-4402-9fee-71bd3a3ae4aa@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
 <Q_MLcqdXT7rSVRa4fSrCV4n09QewxBVQ6Tw-iwhvgNk=.edd652c2-1840-4402-9fee-71bd3a3ae4aa@github.com>
Message-ID: <JcdaRvdOez3k0XQIpAcZSG3lB3gVWWSWI_2Uz_4nb8k=.9d32d70e-32f6-41f7-acd5-4bfd9b8d2646@github.com>

On Sat, 12 Oct 2024 08:24:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'inc should be faster than add on most CPUs'
>
> test/jdk/java/io/Reader/Of.java line 92:
> 
>> 90: 
>> 91:     @Test(dataProvider = "readers")
>> 92:     public void testReadBII(Reader reader) throws IOException {
> 
> What does `BII` in some of these test method names represent?

Good question. I hereby forward it to the original author of the existing tests I have copied from OpenJDK. I assume it was some kind of convention.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1797686743

From duke at openjdk.org  Sat Oct 12 13:53:50 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 12 Oct 2024 13:53:50 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v39]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <QXZfcEuZmVCo-Adw5WYy4PjE9d59VXvtafE8u9pecF4=.cecd3fe6-f315-48b2-a121-2d03a7caaa44@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refining comments describing the algorithm

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/7bfff357..3e61d935

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=37-38

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Sat Oct 12 13:58:52 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 12 Oct 2024 13:58:52 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v40]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <wn8oJ_mPtr-CBt4V_0x-zMty7BXzluPvHpQeeYVgI_E=.77e27c15-841c-4465-bf71-a5355ee4f2a6@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refining comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/3e61d935..ca133d70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=38-39

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Sat Oct 12 14:24:38 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 12 Oct 2024 14:24:38 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v41]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <8mNvZJivb1s4imlGoEBHwglPxAOnYenPnmSPUz5OQh0=.1b3a0bc4-977d-4741-ac87-efe90d4a186d@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Update BigDecimal.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/ca133d70..1a53a635

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=39-40

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Sat Oct 12 14:42:08 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Sat, 12 Oct 2024 14:42:08 GMT
Subject: RFR: 8341924: Improve error message with structurally malformed
 Code array
In-Reply-To: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
References: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
Message-ID: <_0TgCGtzxVQ1PjYkSyDCNHrbe0iFLDdLYGkXmAegY2s=.41106b35-fe21-4370-abb5-ed38826f768f@github.com>

On Fri, 11 Oct 2024 05:39:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Patch a tableswitch instruction's low value to be greater than a high value, previously, javap will not print any previous instruction and report problematic address/bci to be 0. This is because the iteration of bound models require first collecting all data into a buffer list. We call the eager `forEach` instead to avoid this problem.
> 
> Before:
> 
> $ javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
> Error: error at or after byte 0
> }
> 
> 
> Now:
> 
> $ $localjdk2/bin/javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
>        0: iload_0
> Error: error at or after address 1: Invalid tableswitch values low: 9 high: 5
> }

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21463#pullrequestreview-2363921436

From duke at openjdk.org  Sat Oct 12 17:37:25 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 12 Oct 2024 17:37:25 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Minor change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/1a53a635..0723858d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=40-41

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From jlu at openjdk.org  Sun Oct 13 03:52:01 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sun, 13 Oct 2024 03:52:01 GMT
Subject: RFR: 8341445: DecimalFormatSymbols setters should throw NPE [v5]
In-Reply-To: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
Message-ID: <7Glw4lRt23rtDnZQtUyTUWudAcm5ahpreW2tf1fR-Zo=.d2df847a-d075-4b29-863e-84cfaf7e35a0@github.com>

> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols. As certain setters did not throw NPE, this allowed for NPE in the equality method. This PR now updates the setters to throw NPE.
> 
> In addition to the NPEs, there is also a behavioral change that `setInternationalCurrencySymbol` no longer sets currency to null if the `currencyCode` is invalid. Instead, it simply does not update `currency`. This must be done, because we do not want to allow nullable instance variables post `initalizeCurrency`.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect further review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21315/files
  - new: https://git.openjdk.org/jdk/pull/21315/files/d0686b35..d31cb2eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21315&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21315&range=03-04

  Stats: 25 lines in 2 files changed: 21 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21315.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21315/head:pull/21315

PR: https://git.openjdk.org/jdk/pull/21315

From jlu at openjdk.org  Sun Oct 13 03:55:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sun, 13 Oct 2024 03:55:14 GMT
Subject: RFR: 8341445: DecimalFormatSymbols setters should throw NPE [v4]
In-Reply-To: <ddfbkcGiYWDmwVYPVPrj5yde6JUmWxUj6T6vaA5B4ik=.f776af57-ee08-43f2-8ae4-b3e459091085@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
 <lOTeegOFQ1CPt8HyJT0bvT8kUBiWTVFauivzqMRgMcU=.209911ea-67de-4e82-aa78-961b42b92ce1@github.com>
 <ddfbkcGiYWDmwVYPVPrj5yde6JUmWxUj6T6vaA5B4ik=.f776af57-ee08-43f2-8ae4-b3e459091085@github.com>
Message-ID: <dnonDwf3q2StXo3VPLj5nVLx24wy3dC1taq1qmh3Ooo=.bcaa700e-302c-42f9-b3cd-0d5f94cb7a95@github.com>

On Fri, 11 Oct 2024 23:01:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 767:
> 
>> 765:             NaN.equals(other.NaN) &&
>> 766:             // Currency fields are lazy. Init via get call to ensure non-null
>> 767:             getCurrencySymbol().equals(other.getCurrencySymbol()) &&
> 
> Probably the same comment refinement can be applied to the location in `hashCode()`.

This and the other comments addressed via https://github.com/openjdk/jdk/pull/21315/commits/d31cb2ebc5eb92978bed4c6f38f1ddfd7ff5452c. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21315#discussion_r1797998932

From jlu at openjdk.org  Sun Oct 13 04:14:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sun, 13 Oct 2024 04:14:18 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b [v3]
In-Reply-To: <fde92Kgy8JJIQNwOf-nvTAiwR4jkym_frXREp6gtNhA=.1b6c6858-a117-4bd8-829c-066b489f8e62@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
 <fde92Kgy8JJIQNwOf-nvTAiwR4jkym_frXREp6gtNhA=.1b6c6858-a117-4bd8-829c-066b489f8e62@github.com>
Message-ID: <P0-2Up_mm2ZhOJ-0xbM6FvJwTwQkgH6qaUCldM37DjU=.740e4901-3e60-42ec-a00d-348db6c8f517@github.com>

On Sat, 12 Oct 2024 00:45:40 GMT, Johny Jose <duke at openjdk.org> wrote:

>> Timezone data 2024b changes
>
> Johny Jose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review changes

Besides small comment, looks correct to me, thanks for the changes.

test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 282:

> 280:                                willGMTOffsetChange.getBoolean(tz));
> 281:     }
> 282: 

Patch will be cleaner if we remove the line change (L 282-283) as well.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21265#pullrequestreview-2364803270
PR Review Comment: https://git.openjdk.org/jdk/pull/21265#discussion_r1798009641

From jpai at openjdk.org  Sun Oct 13 07:10:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 13 Oct 2024 07:10:08 GMT
Subject: RFR: 8341957: Add test for URLClassLoader loading invalid class
 with mismatching CRC32
In-Reply-To: <q6Qz4Lg2ckHcy7_T5ZKWldYeo02iUwjfZ6D-cxa6E6U=.00d97bc2-4e51-4a04-9f8f-6192f47cb508@github.com>
References: <q6Qz4Lg2ckHcy7_T5ZKWldYeo02iUwjfZ6D-cxa6E6U=.00d97bc2-4e51-4a04-9f8f-6192f47cb508@github.com>
Message-ID: <iSfmTarrRd4DTsTn78baM-xkeWRnak5-mdKJKi7gdBw=.86a3abf8-b2cd-449c-becd-bd8b80a469f5@github.com>

On Fri, 11 Oct 2024 11:46:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which adds test coverage for the case where `URLClassLoader.defineClass` fails with a `ClassFormatError` _and_ the CRC32 checksum of the class file byte array did not match the CRC32 value stated in the JAR file's CEN header.
> 
> In such cases, an `IOException` with the message _"CRC error while extracting entry from JAR file"_ is added as a suppressed exception to the `ClassFormatError`.
> 
> Adding a test documents this unspecified, but long-standing behavior.
> 
> For good measure, the test also covers the existing behavior of the module system class loader. Since the module system does not add similar suppressed exception on a CRC32 mismatch, this test mostly serves the purpose of documentation. 
> 
> The test is parameterized, as such it covers all eight combinations of {URLClassLoader/module class loader, valid/invalid class data, valid/invalid CRC checksum}.
> 
> Should any of the class loaders change behavior in the future (with or without intent), this test will notice and may need to be updated to document the new behavior. Otherwise, it will catch unintended regressions.
> 
> Testing: This is a test-only enhancement PR, no existing tests are updated.

Hello Eirik, from what I can see, the fact that a `ClassFormatError` thrown from `URLClassLoader` has a suppressed exception and that the suppressed exception would contain CRC failure related exception message is merely an implementation detail (which should be free to change any time). I think asserting this internal detail through a test case isn't necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21469#issuecomment-2408854972

From eirbjo at openjdk.org  Sun Oct 13 07:34:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 13 Oct 2024 07:34:08 GMT
Subject: RFR: 8341957: Add test for URLClassLoader loading invalid class
 with mismatching CRC32
In-Reply-To: <iSfmTarrRd4DTsTn78baM-xkeWRnak5-mdKJKi7gdBw=.86a3abf8-b2cd-449c-becd-bd8b80a469f5@github.com>
References: <q6Qz4Lg2ckHcy7_T5ZKWldYeo02iUwjfZ6D-cxa6E6U=.00d97bc2-4e51-4a04-9f8f-6192f47cb508@github.com>
 <iSfmTarrRd4DTsTn78baM-xkeWRnak5-mdKJKi7gdBw=.86a3abf8-b2cd-449c-becd-bd8b80a469f5@github.com>
Message-ID: <knODmLWPgMovpAS5V6b7iMlBq6B7Th5Pa8B0_2g5E5s=.26966f54-8d33-4a14-888c-475bfda6c6be@github.com>

On Sun, 13 Oct 2024 07:07:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> .. is merely an implementation detail (which should be free to change any time). I think asserting this internal detail through a test case isn't necessary.

Thanks Jai. Sure, this test asserts invariants of the implementation, not in the specification. There is some precedence for this, consider the CEN size implemenation limit validation testing.  

The context for looking into this was that the CRC checksum is currently computed on the happy path. If we shift this computation to where there is an actual `ClassFormatError`, I observe  a ~10ms improvement on Spring Petclinic startup time on my computer. Given the complexity and sensitivity of this area, I would not be comfortable proposing such a change without having a solid test to catch regressions.

But yeah, the performance improvement isn't major, and the details of the the suppressed message is probably not very important for users.

I'll withdraw this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21469#issuecomment-2408861628

From eirbjo at openjdk.org  Sun Oct 13 07:41:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 13 Oct 2024 07:41:12 GMT
Subject: Withdrawn: 8341957: Add test for URLClassLoader loading invalid class
 with mismatching CRC32
In-Reply-To: <q6Qz4Lg2ckHcy7_T5ZKWldYeo02iUwjfZ6D-cxa6E6U=.00d97bc2-4e51-4a04-9f8f-6192f47cb508@github.com>
References: <q6Qz4Lg2ckHcy7_T5ZKWldYeo02iUwjfZ6D-cxa6E6U=.00d97bc2-4e51-4a04-9f8f-6192f47cb508@github.com>
Message-ID: <Zs7r-MLtrcvSIjmrItlG6lklgTWo8VviusOvG5WXI-0=.01608db4-d417-4852-9440-28bf493b35a1@github.com>

On Fri, 11 Oct 2024 11:46:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which adds test coverage for the case where `URLClassLoader.defineClass` fails with a `ClassFormatError` _and_ the CRC32 checksum of the class file byte array did not match the CRC32 value stated in the JAR file's CEN header.
> 
> In such cases, an `IOException` with the message _"CRC error while extracting entry from JAR file"_ is added as a suppressed exception to the `ClassFormatError`.
> 
> Adding a test documents this unspecified, but long-standing behavior.
> 
> For good measure, the test also covers the existing behavior of the module system class loader. Since the module system does not add similar suppressed exception on a CRC32 mismatch, this test mostly serves the purpose of documentation. 
> 
> The test is parameterized, as such it covers all eight combinations of {URLClassLoader/module class loader, valid/invalid class data, valid/invalid CRC checksum}.
> 
> Should any of the class loaders change behavior in the future (with or without intent), this test will notice and may need to be updated to document the new behavior. Otherwise, it will catch unintended regressions.
> 
> Testing: This is a test-only enhancement PR, no existing tests are updated.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21469

From jbhateja at openjdk.org  Sun Oct 13 09:57:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 13 Oct 2024 09:57:00 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Update adlc changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/ce76c3e5..506ae299

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=22-23

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Sun Oct 13 11:18:01 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 13 Oct 2024 11:18:01 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Updating tests to use floorMod

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/1cca8e24..79ee29c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=15-16

  Stats: 31 lines in 31 files changed: 0 ins; 0 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From rgiulietti at openjdk.org  Sun Oct 13 13:18:16 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 13 Oct 2024 13:18:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
Message-ID: <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>

On Sat, 12 Oct 2024 17:37:25 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor change

After the proposed modifications, which aim to clarify the numeric aspects, I'll wait for a couple of days before approval for you to commit possible last minute changes.

src/java.base/share/classes/java/math/BigDecimal.java line 5242:

> 5240:     }
> 5241: 
> 5242:     private static final double LOG_5_OF_2 = Math.log(2.0) / Math.log(5.0);

Suggestion:

    private static final double LOG_5_OF_2 = 0.43067655807339306; // double closest to log5(2)

to be sure that `LOG_5_OF_2` is the best possible, although it doesn't matter much.

src/java.base/share/classes/java/math/BigDecimal.java line 5270:

> 5268: 
> 5269:         intVal = intVal.shiftRight(powsOf2); // remove powers of 2
> 5270:         // maxPowsOf5 >= floor(log5(intVal)) >= max{n : (intVal % 5^n) == 0}

Suggestion:

        // Let k = max{n : (intVal % 5^n) == 0}, m = max{n : 5^n <= intVal}, so m >= k.
        // Let b = intVal.bitLength(). It can be shown that
        // | b * LOG_5_OF_2 - b log5(2) | < 2^(-21) (fp viz. real arithmetic),
        // which entails m <= maxPowsOf5 <= m + 1, where maxPowsOf5 is as below.
        // Hence, maxPowsOf5 >= k and is never off by more than 1 from the theoretical m.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21323#pullrequestreview-2364917422
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798328808
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798329279

From duke at openjdk.org  Sun Oct 13 14:43:16 2024
From: duke at openjdk.org (j3graham)
Date: Sun, 13 Oct 2024 14:43:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
Message-ID: <p2P_Rv6se-Elyc202OLrm97vThp5SsLwYXZjVeHufa8=.285fd859-3db3-43b1-9980-224592c0119b@github.com>

On Sat, 12 Oct 2024 17:37:25 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor change

src/java.base/share/classes/java/math/BigDecimal.java line 5234:

> 5232:      */
> 5233:     private static BigInteger fiveToTwoToThe(int n) {
> 5234:         int i = Math.min(n, FIVE_TO_2_TO.length - 1);

BigInteger has ?getRadixConversionCache? which could be made accessible and used here - perhaps with a better name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798379273

From duke at openjdk.org  Sun Oct 13 15:26:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 13 Oct 2024 15:26:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <p2P_Rv6se-Elyc202OLrm97vThp5SsLwYXZjVeHufa8=.285fd859-3db3-43b1-9980-224592c0119b@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <p2P_Rv6se-Elyc202OLrm97vThp5SsLwYXZjVeHufa8=.285fd859-3db3-43b1-9980-224592c0119b@github.com>
Message-ID: <govT3LcmnUKHCvkYMIcNTbY9LLL0yfYmm4Q4gEpET2E=.ddd2b10c-34c3-47d5-86fb-234089a57d3e@github.com>

On Sun, 13 Oct 2024 14:39:32 GMT, j3graham <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor change
>
> src/java.base/share/classes/java/math/BigDecimal.java line 5234:
> 
>> 5232:      */
>> 5233:     private static BigInteger fiveToTwoToThe(int n) {
>> 5234:         int i = Math.min(n, FIVE_TO_2_TO.length - 1);
> 
> BigInteger has ?getRadixConversionCache? which could be made accessible and used here - perhaps with a better name.

I already wrote about that method previously [here](https://github.com/openjdk/jdk/pull/21323#discussion_r1790787304).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798406008

From rgiulietti at openjdk.org  Sun Oct 13 15:33:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 13 Oct 2024 15:33:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <p2P_Rv6se-Elyc202OLrm97vThp5SsLwYXZjVeHufa8=.285fd859-3db3-43b1-9980-224592c0119b@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <p2P_Rv6se-Elyc202OLrm97vThp5SsLwYXZjVeHufa8=.285fd859-3db3-43b1-9980-224592c0119b@github.com>
Message-ID: <5S4sfPtaEit6w3AukmOVsBti5fj2OeBbh4Y1Otokamo=.5f8233a7-639b-4fca-8bda-6b30133ba7eb@github.com>

On Sun, 13 Oct 2024 14:39:32 GMT, j3graham <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor change
>
> src/java.base/share/classes/java/math/BigDecimal.java line 5234:
> 
>> 5232:      */
>> 5233:     private static BigInteger fiveToTwoToThe(int n) {
>> 5234:         int i = Math.min(n, FIVE_TO_2_TO.length - 1);
> 
> BigInteger has ?getRadixConversionCache? which could be made accessible and used here - perhaps with a better name.

@j3graham The benchmarks using `getRadixConversionCache()` look good (see below).
The problem with this is that the cache maintained by that method is unlimited, whereas the one controlled by `fiveToTwoToThe()` has modest memory requirements.


Benchmark                            Mode  Cnt          Score        Error  Units
BigDecimalStripTrailingZeros.testL   avgt   15    2723753.867 ?   9200.262  ns/op
BigDecimalStripTrailingZeros.testM   avgt   15       9269.359 ?     32.427  ns/op
BigDecimalStripTrailingZeros.testS   avgt   15        155.660 ?      0.807  ns/op
BigDecimalStripTrailingZeros.testXL  avgt   15  445079302.800 ? 969170.405  ns/op
BigDecimalStripTrailingZeros.testXS  avgt   15         21.305 ?      0.029  ns/op
Finished running test 'micro:java.math.BigDecimalStripTrailingZeros'

@j3graham The benchmarks using `getRadixConversionCache()` look good (see below).
The problem with this is that the cache maintained by that method is unlimited, whereas the one controlled by `fiveToTwoToThe()` has modest memory requirements.


Benchmark                            Mode  Cnt          Score        Error  Units
BigDecimalStripTrailingZeros.testL   avgt   15    2723753.867 ?   9200.262  ns/op
BigDecimalStripTrailingZeros.testM   avgt   15       9269.359 ?     32.427  ns/op
BigDecimalStripTrailingZeros.testS   avgt   15        155.660 ?      0.807  ns/op
BigDecimalStripTrailingZeros.testXL  avgt   15  445079302.800 ? 969170.405  ns/op
BigDecimalStripTrailingZeros.testXS  avgt   15         21.305 ?      0.029  ns/op
Finished running test 'micro:java.math.BigDecimalStripTrailingZeros'

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798409738
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798410039

From duke at openjdk.org  Sun Oct 13 15:43:13 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 13 Oct 2024 15:43:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>
Message-ID: <oBTTx7wHK8sBVuqUvtYN-T4EcriO4zhyE0Cfa9jQWgY=.4a3ddf22-13e1-4b5f-a207-23bc94f8b789@github.com>

On Sun, 13 Oct 2024 13:13:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor change
>
> src/java.base/share/classes/java/math/BigDecimal.java line 5270:
> 
>> 5268: 
>> 5269:         intVal = intVal.shiftRight(powsOf2); // remove powers of 2
>> 5270:         // maxPowsOf5 >= floor(log5(intVal)) >= max{n : (intVal % 5^n) == 0}
> 
> Suggestion:
> 
>         // Let k = max{n : (intVal % 5^n) == 0}, m = max{n : 5^n <= intVal}, so m >= k.
>         // Let b = intVal.bitLength(). It can be shown that
>         // | b * LOG_5_OF_2 - b log5(2) | < 2^(-21) (fp viz. real arithmetic),
>         // which entails m <= maxPowsOf5 <= m + 1, where maxPowsOf5 is as below.
>         // Hence, maxPowsOf5 >= k and is never off by more than 1 from the theoretical m.

@rgiulietti Good, but I would not put the inequality `maxPowsOf5 <= m + 1` and say that `maxPowsOf5` is never off by more than 1 from the theoretical `m`, because it is not crucial as `maxPowsOf5 >= k`, and because `m` is in function of `intVal`, while `maxPowsOf5` is in function of `2^b`, so it is not obvious that there's no power of five `pow` such that `intVal < pow < 2^b`...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798415994

From duke at openjdk.org  Sun Oct 13 15:54:28 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 13 Oct 2024 15:54:28 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v43]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <h-_frLTABZBFVP2-pvETQYR9jKMuhtvAWq0XVTlCH-0=.c18d2058-187c-451e-96f7-25ee9a1028eb@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Use log5(2) best approximation
  
  Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/0723858d..4d1a829c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=41-42

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From rgiulietti at openjdk.org  Sun Oct 13 16:06:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 13 Oct 2024 16:06:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <oBTTx7wHK8sBVuqUvtYN-T4EcriO4zhyE0Cfa9jQWgY=.4a3ddf22-13e1-4b5f-a207-23bc94f8b789@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>
 <oBTTx7wHK8sBVuqUvtYN-T4EcriO4zhyE0Cfa9jQWgY=.4a3ddf22-13e1-4b5f-a207-23bc94f8b789@github.com>
Message-ID: <0CmCmx2CUIRqB-P7ZuyiT7VomJ62ImRSFLkWOQRWSeo=.a554bbc2-7434-4287-84a3-c4965b7885c0@github.com>

On Sun, 13 Oct 2024 15:40:27 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 5270:
>> 
>>> 5268: 
>>> 5269:         intVal = intVal.shiftRight(powsOf2); // remove powers of 2
>>> 5270:         // maxPowsOf5 >= floor(log5(intVal)) >= max{n : (intVal % 5^n) == 0}
>> 
>> Suggestion:
>> 
>>         // Let k = max{n : (intVal % 5^n) == 0}, m = max{n : 5^n <= intVal}, so m >= k.
>>         // Let b = intVal.bitLength(). It can be shown that
>>         // | b * LOG_5_OF_2 - b log5(2) | < 2^(-21) (fp viz. real arithmetic),
>>         // which entails m <= maxPowsOf5 <= m + 1, where maxPowsOf5 is as below.
>>         // Hence, maxPowsOf5 >= k and is never off by more than 1 from the theoretical m.
>
> @rgiulietti Good, but I would not put the inequality `maxPowsOf5 <= m + 1` and say that `maxPowsOf5` is never off by more than 1 from the theoretical `m`, because it is not crucial as `m <= maxPowsOf5`, and because `m` is in function of `intVal`, while `maxPowsOf5` is in function of `2^b`, so it is not obvious that there's no power of five `pow` such that `intVal < pow < 2^b`...

What's really crucial for _correctness_ is to ensure maxPowsOf5 >= k.

But for performance you also want maxPowsOf5 to be as small as possible. So, the fact that it turns out that maxPowsOf5 <= m + 1 guarantees that maxPowsOf5 is the best value that can be computed very efficiently. It's more a "quality of service" guarantee than anything fundamental.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798429260

From rgiulietti at openjdk.org  Sun Oct 13 16:09:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 13 Oct 2024 16:09:11 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <0CmCmx2CUIRqB-P7ZuyiT7VomJ62ImRSFLkWOQRWSeo=.a554bbc2-7434-4287-84a3-c4965b7885c0@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>
 <oBTTx7wHK8sBVuqUvtYN-T4EcriO4zhyE0Cfa9jQWgY=.4a3ddf22-13e1-4b5f-a207-23bc94f8b789@github.com>
 <0CmCmx2CUIRqB-P7ZuyiT7VomJ62ImRSFLkWOQRWSeo=.a554bbc2-7434-4287-84a3-c4965b7885c0@github.com>
Message-ID: <6zbXR1r_VeVKFLWCxcjKHKnG4Uod7daj4KmMMa1LlUo=.02d95706-0b94-41c3-b0eb-33112bf9554c@github.com>

On Sun, 13 Oct 2024 16:03:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti Good, but I would not put the inequality `maxPowsOf5 <= m + 1` and say that `maxPowsOf5` is never off by more than 1 from the theoretical `m`, because it is not crucial as `m <= maxPowsOf5`, and because `m` is in function of `intVal`, while `maxPowsOf5` is in function of `2^b`, so it is not obvious that there's no power of five `pow` such that `intVal < pow < 2^b`...
>
> What's really crucial for _correctness_ is to ensure maxPowsOf5 >= k.
> 
> But for performance you also want maxPowsOf5 to be as small as possible. So, the fact that it turns out that maxPowsOf5 <= m + 1 guarantees that maxPowsOf5 is the best value that can be computed very efficiently. It's more a "quality of service" guarantee than anything fundamental.

Perhaps leave m <= maxPowsOf5 <= m + 1 and maxPowsOf5 >= k and drop the note "and is never off by more than 1 from the theoretical m"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798430974

From duke at openjdk.org  Sun Oct 13 16:21:12 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 13 Oct 2024 16:21:12 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <6zbXR1r_VeVKFLWCxcjKHKnG4Uod7daj4KmMMa1LlUo=.02d95706-0b94-41c3-b0eb-33112bf9554c@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>
 <oBTTx7wHK8sBVuqUvtYN-T4EcriO4zhyE0Cfa9jQWgY=.4a3ddf22-13e1-4b5f-a207-23bc94f8b789@github.com>
 <0CmCmx2CUIRqB-P7ZuyiT7VomJ62ImRSFLkWOQRWSeo=.a554bbc2-7434-4287-84a3-c4965b7885c0@github.com>
 <6zbXR1r_VeVKFLWCxcjKHKnG4Uod7daj4KmMMa1LlUo=.02d95706-0b94-41c3-b0eb-33112bf9554c@github.com>
Message-ID: <qffR6a8-J8ITtXP_ZmsgfspX2nvOcZ1aDZ9SNkOy8Ec=.ce382dbf-a620-42f6-b540-485098d9633b@github.com>

On Sun, 13 Oct 2024 16:06:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> What's really crucial for _correctness_ is to ensure maxPowsOf5 >= k.
>> 
>> But for performance you also want maxPowsOf5 to be as small as possible. So, the fact that it turns out that maxPowsOf5 <= m + 1 guarantees that maxPowsOf5 is the best value that can be computed very efficiently. It's more a "quality of service" guarantee than anything fundamental.
>
> Perhaps leave m <= maxPowsOf5 <= m + 1 and maxPowsOf5 >= k and drop the note "and is never off by more than 1 from the theoretical m"

> What's really crucial for _correctness_ is to ensure maxPowsOf5 >= k.

Yes, I meant that the only way we know to ensure that condition is to ensure `m <= maxPowsOf5`...

> Perhaps leave m <= maxPowsOf5 <= m + 1 and maxPowsOf5 >= k and drop the note "and is never off by more than 1 from the theoretical m"

I would put `maxPowsOf5 <= m + 2` instead, because `maxPowsOf5 <= m + 1` is not obvious to prove mathematically...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798437787

From rgiulietti at openjdk.org  Sun Oct 13 16:37:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 13 Oct 2024 16:37:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <qffR6a8-J8ITtXP_ZmsgfspX2nvOcZ1aDZ9SNkOy8Ec=.ce382dbf-a620-42f6-b540-485098d9633b@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>
 <oBTTx7wHK8sBVuqUvtYN-T4EcriO4zhyE0Cfa9jQWgY=.4a3ddf22-13e1-4b5f-a207-23bc94f8b789@github.com>
 <0CmCmx2CUIRqB-P7ZuyiT7VomJ62ImRSFLkWOQRWSeo=.a554bbc2-7434-4287-84a3-c4965b7885c0@github.com>
 <6zbXR1r_VeVKFLWCxcjKHKnG4Uod7daj4KmMMa1LlUo=.02d95706-0b94-41c3-b0eb-33112bf9554c@github.com>
 <qffR6a8-J8ITtXP_ZmsgfspX2nvOcZ1aDZ9SNkOy8Ec=.ce382dbf-a620-42f6-b540-485098d9633b@github.com>
Message-ID: <wuLT4Bp9zC52euRVoOtYzkfa0OKgrz9gDbhkBbrF_6U=.fec51869-fdbf-430b-aa2a-495428f0f867@github.com>

On Sun, 13 Oct 2024 16:18:03 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Perhaps leave m <= maxPowsOf5 <= m + 1 and maxPowsOf5 >= k and drop the note "and is never off by more than 1 from the theoretical m"
>
>> What's really crucial for _correctness_ is to ensure maxPowsOf5 >= k.
> 
> Yes, I meant that the only way we know to ensure that condition is to ensure `m <= maxPowsOf5`...
> 
>> Perhaps leave m <= maxPowsOf5 <= m + 1 and maxPowsOf5 >= k and drop the note "and is never off by more than 1 from the theoretical m"
> 
> I would put `maxPowsOf5 <= m + 2` instead, because `maxPowsOf5 <= m + 1` is not obvious to prove mathematically...

It can be proven by considering

- the inequality | b * LOG_5_OF_2 - b log5(2) | < 2^(-21)
- the properties of round() (to an integer)
- log5(2) < 1/2

The last one is crucial for the upper bound to be m + 1 rather than m + 2.

Feel free to use m + 2, though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798446904

From duke at openjdk.org  Sun Oct 13 17:00:13 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 13 Oct 2024 17:00:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <wuLT4Bp9zC52euRVoOtYzkfa0OKgrz9gDbhkBbrF_6U=.fec51869-fdbf-430b-aa2a-495428f0f867@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>
 <oBTTx7wHK8sBVuqUvtYN-T4EcriO4zhyE0Cfa9jQWgY=.4a3ddf22-13e1-4b5f-a207-23bc94f8b789@github.com>
 <0CmCmx2CUIRqB-P7ZuyiT7VomJ62ImRSFLkWOQRWSeo=.a554bbc2-7434-4287-84a3-c4965b7885c0@github.com>
 <6zbXR1r_VeVKFLWCxcjKHKnG4Uod7daj4KmMMa1LlUo=.02d95706-0b94-41c3-b0eb-33112bf9554c@github.com>
 <qffR6a8-J8ITtXP_ZmsgfspX2nvOcZ1aDZ9SNkOy8Ec=.ce382dbf-a620-42f6-b540-485098d9633b@github.com>
 <wuLT4Bp9zC52euRVoOtYzkfa0OKgrz9gDbhkBbrF_6U=.fec51869-fdbf-430b-aa2a-495428f0f867@github.com>
Message-ID: <u1qwxdr8rdi0Dy4gDaFWnPxsQbk4X6KpWHT3UP_x1rg=.a2dd535f-2a8a-4659-9ec3-0ea882adb2b4@github.com>

On Sun, 13 Oct 2024 16:34:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> What's really crucial for _correctness_ is to ensure maxPowsOf5 >= k.
>> 
>> Yes, I meant that the only way we know to ensure that condition is to ensure `m <= maxPowsOf5`...
>> 
>>> Perhaps leave m <= maxPowsOf5 <= m + 1 and maxPowsOf5 >= k and drop the note "and is never off by more than 1 from the theoretical m"
>> 
>> I would put `maxPowsOf5 <= m + 2` instead, because `maxPowsOf5 <= m + 1` is not obvious to prove mathematically...
>
> It can be proven by considering
> 
> - the inequality | b * LOG_5_OF_2 - b log5(2) | < 2^(-21)
> - the properties of round() (to an integer)
> - log5(2) < 1/2
> 
> The last one is crucial for the upper bound to be m + 1 rather than m + 2.
> 
> Feel free to use m + 2, though.

I understood that it follows from the fact that `log5(2^(n+1)) - log5(2^n) == [log5(2^n) + log5(2)] - log5(2^n)`, but I think it's superfluous having to explain it in the comments just to prove `maxPowsOf5 <= m + 1`, while it is more clear to understand why `maxPowsOf5 <= m + 2` is true. Anyway, thanks for the insight.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798459950

From duke at openjdk.org  Sun Oct 13 17:51:12 2024
From: duke at openjdk.org (j3graham)
Date: Sun, 13 Oct 2024 17:51:12 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <p2P_Rv6se-Elyc202OLrm97vThp5SsLwYXZjVeHufa8=.285fd859-3db3-43b1-9980-224592c0119b@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <p2P_Rv6se-Elyc202OLrm97vThp5SsLwYXZjVeHufa8=.285fd859-3db3-43b1-9980-224592c0119b@github.com>
Message-ID: <F6aMQOijLV7VBjQM6GSHXjwR-gYcqxG14BbExvpYzeE=.b20b6652-5515-4f2e-975e-44a7ebbb7134@github.com>

On Sun, 13 Oct 2024 14:39:32 GMT, j3graham <duke at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor change
>
> src/java.base/share/classes/java/math/BigDecimal.java line 5234:
> 
>> 5232:      */
>> 5233:     private static BigInteger fiveToTwoToThe(int n) {
>> 5234:         int i = Math.min(n, FIVE_TO_2_TO.length - 1);
> 
> BigInteger has ?getRadixConversionCache? which could be made accessible and used here - perhaps with a better name.

> @j3graham The benchmarks using `getRadixConversionCache()` look good (see below). The problem with this is that the cache maintained by that method is unlimited, whereas the one controlled by `fiveToTwoToThe()` has modest memory requirements.
> 
> ```

The method here could use the radix cache up to a safe value, and continue the calculation as it currently does beyond that. The benefit would be the existing incremental evaluation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798470489

From duke at openjdk.org  Sun Oct 13 17:51:13 2024
From: duke at openjdk.org (j3graham)
Date: Sun, 13 Oct 2024 17:51:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <F6aMQOijLV7VBjQM6GSHXjwR-gYcqxG14BbExvpYzeE=.b20b6652-5515-4f2e-975e-44a7ebbb7134@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <p2P_Rv6se-Elyc202OLrm97vThp5SsLwYXZjVeHufa8=.285fd859-3db3-43b1-9980-224592c0119b@github.com>
 <F6aMQOijLV7VBjQM6GSHXjwR-gYcqxG14BbExvpYzeE=.b20b6652-5515-4f2e-975e-44a7ebbb7134@github.com>
Message-ID: <7L9S5IlEpxHwTsz0A_kTA_i0WGwd_3yWaI3ihF6r9r0=.51827377-5ee2-48e2-a242-5796cbc6427a@github.com>

On Sun, 13 Oct 2024 17:48:15 GMT, j3graham <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 5234:
>> 
>>> 5232:      */
>>> 5233:     private static BigInteger fiveToTwoToThe(int n) {
>>> 5234:         int i = Math.min(n, FIVE_TO_2_TO.length - 1);
>> 
>> BigInteger has ?getRadixConversionCache? which could be made accessible and used here - perhaps with a better name.
>
>> @j3graham The benchmarks using `getRadixConversionCache()` look good (see below). The problem with this is that the cache maintained by that method is unlimited, whereas the one controlled by `fiveToTwoToThe()` has modest memory requirements.
>> 
>> ```
> 
> The method here could use the radix cache up to a safe value, and continue the calculation as it currently does beyond that. The benefit would be the existing incremental evaluation.

> I already wrote about that method previously [here](https://github.com/openjdk/jdk/pull/21323#discussion_r1790787304).

Sorry, missed that comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798470618

From eosterlund at openjdk.org  Sun Oct 13 18:24:13 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Sun, 13 Oct 2024 18:24:13 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <UbOLixLd3_OTxnT5Ff2vXnLGBj71Xr_kAqbavGNXS6M=.5f3d56d9-c880-47a2-93a9-9770f3074b8c@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2364968158

From rgiulietti at openjdk.org  Sun Oct 13 19:39:16 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sun, 13 Oct 2024 19:39:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v42]
In-Reply-To: <u1qwxdr8rdi0Dy4gDaFWnPxsQbk4X6KpWHT3UP_x1rg=.a2dd535f-2a8a-4659-9ec3-0ea882adb2b4@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <h4rFvktEeJMF1AQvX_QiB-kkx5b9V59c6og10e0BaUw=.36edca40-9786-4508-a71d-801ec5dd0762@github.com>
 <50aa9rMxszj9J2p4xxgayJfDNSIbN01L9C83eBkUs4U=.34959c42-4dc6-4e52-9a49-d59d6fc7e5b2@github.com>
 <oBTTx7wHK8sBVuqUvtYN-T4EcriO4zhyE0Cfa9jQWgY=.4a3ddf22-13e1-4b5f-a207-23bc94f8b789@github.com>
 <0CmCmx2CUIRqB-P7ZuyiT7VomJ62ImRSFLkWOQRWSeo=.a554bbc2-7434-4287-84a3-c4965b7885c0@github.com>
 <6zbXR1r_VeVKFLWCxcjKHKnG4Uod7daj4KmMMa1LlUo=.02d95706-0b94-41c3-b0eb-33112bf9554c@github.com>
 <qffR6a8-J8ITtXP_ZmsgfspX2nvOcZ1aDZ9SNkOy8Ec=.ce382dbf-a620-42f6-b540-485098d9633b@github.com>
 <wuLT4Bp9zC52euRVoOtYzkfa0OKgrz9gDbhkBbrF_6U=.fec51869-fdbf-430b-aa2a-495428f0f867@github.com>
 <u1qwxdr8rdi0Dy4gDaFWnPxsQbk4X6KpWHT3UP_x1rg=.a2dd535f-2a8a-4659-9ec3-0ea882adb2b4@github.com>
Message-ID: <UpPssJAYYNAZLbGHmhhi-ExLDtsVvtx5Ljhkz_q4CpU=.0bedce43-de1a-426b-815b-e30a97e31839@github.com>

On Sun, 13 Oct 2024 16:57:33 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> It can be proven by considering
>> 
>> - the inequality | b * LOG_5_OF_2 - b log5(2) | < 2^(-21)
>> - the properties of round() (to an integer)
>> - log5(2) < 1/2
>> 
>> The last one is crucial for the upper bound to be m + 1 rather than m + 2.
>> 
>> Feel free to use m + 2, though.
>
> I understood that it follows from the fact that `log5(2^(n+1)) - log5(2^n) == [log5(2^n) + log5(2)] - log5(2^n)`, but I think it's superfluous having to explain it in the comments just to prove `maxPowsOf5 <= m + 1`, while it is more clear to understand why `maxPowsOf5 <= m + 2` is true. Anyway, thanks for the insight.

With the notation above, the reasoning goes like so:

2^(b-1) <= v < 5^(m+1), hence b log5(2) < m + 1 + log5(2).
This implies b * LOG_5_OF_2 < m + 1 + log5(2) + 2^(-21) < m + 1 + 1/2,
which leads to round(b * LOG_5_OF_2) <= m + 1.

As said, I don't mind if you prefer m + 2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1798522972

From iklam at openjdk.org  Sun Oct 13 21:07:51 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 13 Oct 2024 21:07:51 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/e9995ea7..039fb65d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=02-03

  Stats: 115 lines in 6 files changed: 60 ins; 52 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From duke at openjdk.org  Sun Oct 13 22:45:25 2024
From: duke at openjdk.org (fabioromano1)
Date: Sun, 13 Oct 2024 22:45:25 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Added mathematical comments for maxPowsOf5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/4d1a829c..29114ed3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=42-43

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Mon Oct 14 04:13:46 2024
From: duke at openjdk.org (Johny Jose)
Date: Mon, 14 Oct 2024 04:13:46 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b [v4]
In-Reply-To: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
Message-ID: <Y0scCRnE7CerLHOA2D7r1P7gWD7Tjzhix3wPEiGzidw=.a0b98380-4308-404c-82f7-d798e5ea4522@github.com>

> Timezone data 2024b changes

Johny Jose has updated the pull request incrementally with one additional commit since the last revision:

  Review changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21265/files
  - new: https://git.openjdk.org/jdk/pull/21265/files/b3a092c3..a6aac06f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21265&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21265&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21265/head:pull/21265

PR: https://git.openjdk.org/jdk/pull/21265

From iklam at openjdk.org  Mon Oct 14 05:33:55 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Oct 2024 05:33:55 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v7]
In-Reply-To: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
Message-ID: <AFueBA58XCIF0EAP__qoGJtStxQMheYsRqYcsdHXJrk=.6da79931-0a15-4fdb-bfdf-71b4707823dd@github.com>

> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> Add the following command-line options as specified in JEP 483:
> 
> 
> - `-XX:AOTMode=off/record/create/auto/on`
> - `-XX:AOTConfiguration=<file>.aotconfig`
> - `-XX:AOTCache=<file>.aot`
> 
> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
> 
> Please see the CSR (TODO) for detailed specification.
> 
> -----
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 jep-483-step-01-8338017-add-aot-command-line-aliases
 - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
 - @macarte comments
 - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
 - @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c
 - Fixed copyright dates
 - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Fixed whitespaces
 - ... and 1 more: https://git.openjdk.org/jdk/compare/4a391e9c...d02959b8

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20516/files
  - new: https://git.openjdk.org/jdk/pull/20516/files/26df2d5a..d02959b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=05-06

  Stats: 57582 lines in 924 files changed: 46849 ins; 5815 del; 4918 mod
  Patch: https://git.openjdk.org/jdk/pull/20516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20516/head:pull/20516

PR: https://git.openjdk.org/jdk/pull/20516

From shade at openjdk.org  Mon Oct 14 09:32:22 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Oct 2024 09:32:22 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <i3s36Xix8ynmLxcCLP07q7e6BJXcmNnxRHMEQVl8WCE=.b985901d-4184-4d43-b2e8-eee8722049dc@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

Thanks! I see Kim reviewed JDK parts, so we need another Reviewer for Hotspot parts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2410579109

From lucy at openjdk.org  Mon Oct 14 09:58:11 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 14 Oct 2024 09:58:11 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
Message-ID: <5FaYEDyDdur7kMtmqUKFJT7qKmA22wU8YZ-TEbOtSZ8=.9d346ca9-ba0e-49d2-be6a-9e1433872f79@github.com>

On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8340801
>  - move ub.h to a better location
>  - remove ubsan changes from jni_md.h
>  - JDK-8340801

Marked as reviewed by lucy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21184#pullrequestreview-2366001983

From lucy at openjdk.org  Mon Oct 14 09:58:12 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Mon, 14 Oct 2024 09:58:12 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <yH_gGFizqXCy6EZ5cXYr99x0nGu99-tsGlct6b8NVr8=.cb7f5798-1959-43a6-8869-a40b24d634dd@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
 <yH_gGFizqXCy6EZ5cXYr99x0nGu99-tsGlct6b8NVr8=.cb7f5798-1959-43a6-8869-a40b24d634dd@github.com>
Message-ID: <KnxqSr7dDirBKVSRpB0saFNH3QHsM5kvUgVL3yQTrcs=.aafa3885-32ee-4dad-9c53-186bf45662a6@github.com>

On Fri, 11 Oct 2024 18:05:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8340801
>>  - move ub.h to a better location
>>  - remove ubsan changes from jni_md.h
>>  - JDK-8340801
>
> Not a review, just commenting.
> 
> I very much support the work @MBaesken has done with ubsan in HotSpot.
> There's a bit of a chicken or egg problem with this kind of thing.  ubsan
> isn't really usable and in any way supported or supportable until the code has
> been made pretty much ubsan-clean.  Matthias has made substantial progress
> toward that for HotSpot, and I thank him for this effort.
> 
> There are currently four uses of the disabling attribute in HotSpot.  Two are
> for intentional things (writing to address zero intentionally, for testing
> signal handling and the like).  One is for a known issue that is being worked
> on, with an associated JBS issue; the attribute is being used to reduce
> testing noise in the meantime.  The fourth is related to some of my recent
> work (adjacent to, not caused by), and something that I think ought to be
> fixed.  I'll be filing a JBS issue.  Along the way there have been a
> substantial number of real bugs uncovered and addressed.
> 
> My only complaint has been a tendency to be a bit too quick to reach for the
> disabling attribute, without sufficient analysis and attempt to resolve in a
> way that corrects the problem.  Of the issues I've observed, the result of a
> real fix nearly always ben a straight-up improvement.

I agree with @kimbarrett in his fear that a convenience macro may lower the hurdle of just suppressing an ubsan complaint. On the other hand, using a macro makes the code look cleaner. Should there ever be a need to change how ubsan is quiesced, it can be done at one place with the use of a macro. I therefore will give the change a LGTM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2410653806

From jbhateja at openjdk.org  Mon Oct 14 12:15:11 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 14 Oct 2024 12:15:11 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <dFk8CH3PN2SgyZ_VAef0uhWsdqj8D73_c1RTBsYUBrw=.164ea5ab-990d-4300-a77b-d8013089452a@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.4e3d7ba2-872f-4407-8bb0-1b9388614660@github.com>
 <dFk8CH3PN2SgyZ_VAef0uhWsdqj8D73_c1RTBsYUBrw=.164ea5ab-990d-4300-a77b-d8013089452a@github.com>
Message-ID: <aENxkYVram8hqkBGhMQ1V9RaKr0qmpeT61KZ78-yRmQ=.7511a9e3-77ab-47ed-8947-5ce3b884fb06@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 on existing MulVL IR, we already use such tricks for relaxed unsafe reductions. Patch is performing point optimization for specific set of constrained multiplication patterns.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2411053693

From pminborg at openjdk.org  Mon Oct 14 12:45:36 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 14 Oct 2024 12:45:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v6]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <23p_5whctCaOQb7tR39LY1OBBralAX2SN936TuQLaXw=.f836844c-40e4-415c-9348-e5123f71d230@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 13 additional commits since the last revision:

 - 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
 - Check exception message
 - Remove redundant doc section
 - Merge branch 'master' into linker-padding-layout-only
 - Improve excception message
 - ... and 3 more: https://git.openjdk.org/jdk/compare/64a4707a...b5e795f3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/b755c61d..b5e795f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=04-05

  Stats: 67207 lines in 1109 files changed: 54440 ins; 7122 del; 5645 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 jlahoda at openjdk.org  Mon Oct 14 12:46:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Oct 2024 12:46:29 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@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 15 commits:

 - Merge branch 'master' into JDK-8335989
 - Reflecting review feedback.
 - Cleanup.
 - Cleanup.
 - Fixing tests
 - Adding a separate scope for module imports.
 - Cleanup.
 - Make very sure java.base is completed.
 - Keep jdk.internal.javac qualified export from java.base.
 - Adding forgotten change.
 - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

-------------

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=02
  Stats: 761 lines in 27 files changed: 580 ins; 46 del; 135 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 pminborg at openjdk.org  Mon Oct 14 12:56:16 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 14 Oct 2024 12:56:16 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v6]
In-Reply-To: <23p_5whctCaOQb7tR39LY1OBBralAX2SN936TuQLaXw=.f836844c-40e4-415c-9348-e5123f71d230@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <23p_5whctCaOQb7tR39LY1OBBralAX2SN936TuQLaXw=.f836844c-40e4-415c-9348-e5123f71d230@github.com>
Message-ID: <CJXMpMg2KI9AJQDV7ei-KRKnEhmInBczfnJd-OfbH84=.2b9eaaba-b3cf-4922-8727-4983a850dc3e@github.com>

On Mon, 14 Oct 2024 12:45: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 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:
> 
>  - 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
>  - Check exception message
>  - Remove redundant doc section
>  - Merge branch 'master' into linker-padding-layout-only
>  - Improve excception message
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/2b9b3036...b5e795f3

Additional tests are to be added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2411151868

From aph at openjdk.org  Mon Oct 14 13:40:50 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 13:40:50 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v3]
In-Reply-To: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
Message-ID: <hq9kyxTFvSrKRsDfstHkUaMm0wAxCWO7BaDSfkqyuig=.9ced3392-3ecf-4766-9e95-b5c1da9c6ad3@github.com>

> The fourth preview of scoped values.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Scoped values
 - Scoped values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21456/files
  - new: https://git.openjdk.org/jdk/pull/21456/files/0d178006..90a344a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 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 rriggs at openjdk.org  Mon Oct 14 14:05:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Oct 2024 14:05:26 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <JcdaRvdOez3k0XQIpAcZSG3lB3gVWWSWI_2Uz_4nb8k=.9d32d70e-32f6-41f7-acd5-4bfd9b8d2646@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
 <Q_MLcqdXT7rSVRa4fSrCV4n09QewxBVQ6Tw-iwhvgNk=.edd652c2-1840-4402-9fee-71bd3a3ae4aa@github.com>
 <JcdaRvdOez3k0XQIpAcZSG3lB3gVWWSWI_2Uz_4nb8k=.9d32d70e-32f6-41f7-acd5-4bfd9b8d2646@github.com>
Message-ID: <lhS7YaIwZgnEoYuHGLXrX2l6OyObku5bKpUqjp9aUF8=.daf0cef9-004e-4c2e-8ea9-c054802d16dc@github.com>

On Sat, 12 Oct 2024 11:33:33 GMT, Markus KARG <duke at openjdk.org> wrote:

>> test/jdk/java/io/Reader/Of.java line 92:
>> 
>>> 90: 
>>> 91:     @Test(dataProvider = "readers")
>>> 92:     public void testReadBII(Reader reader) throws IOException {
>> 
>> What does `BII` in some of these test method names represent?
>
> Good question. I hereby forward it to the original author of the existing tests I have copied from OpenJDK. I assume it was some kind of convention.

`BII` is shorthand for the arguments in the signature of the method under test. In this case, its a byte array, and two int's. Try `javap -s java.io.Reader` for other examples.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1799577772

From alanb at openjdk.org  Mon Oct 14 14:07:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 14 Oct 2024 14:07:14 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v3]
In-Reply-To: <hq9kyxTFvSrKRsDfstHkUaMm0wAxCWO7BaDSfkqyuig=.9ced3392-3ecf-4766-9e95-b5c1da9c6ad3@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
 <hq9kyxTFvSrKRsDfstHkUaMm0wAxCWO7BaDSfkqyuig=.9ced3392-3ecf-4766-9e95-b5c1da9c6ad3@github.com>
Message-ID: <0tKeT1dnFZRWD2jI39x_DdsqfFOWw_6GOf0VHrNbdu0=.dc762f86-648e-4455-9308-823be0ddb75b@github.com>

On Mon, 14 Oct 2024 13:40:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The fourth preview of scoped values.
>
> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Scoped values
>  - Scoped values

The changes in update 90a344a3 looks okay, just one example in the ScopedValue docs that was missed (the example is correct in the loom repo).

src/java.base/share/classes/java/lang/ScopedValue.java line 160:

> 158:  *     private static final ScopedValue<String> NAME = ScopedValue.newInstance();
> 159: 
> 160:  *     ScopedValue.runWhere(NAME, "duke", () -> {

This should be `ScopedValue.where(NAME, "duke").run(() -> {`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21456#issuecomment-2411371574
PR Review Comment: https://git.openjdk.org/jdk/pull/21456#discussion_r1799579699

From qamai at openjdk.org  Mon Oct 14 14:14:13 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 14 Oct 2024 14:14:13 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aENxkYVram8hqkBGhMQ1V9RaKr0qmpeT61KZ78-yRmQ=.7511a9e3-77ab-47ed-8947-5ce3b884fb06@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.4e3d7ba2-872f-4407-8bb0-1b9388614660@github.com>
 <dFk8CH3PN2SgyZ_VAef0uhWsdqj8D73_c1RTBsYUBrw=.164ea5ab-990d-4300-a77b-d8013089452a@github.com>
 <aENxkYVram8hqkBGhMQ1V9RaKr0qmpeT61KZ78-yRmQ=.7511a9e3-77ab-47ed-8947-5ce3b884fb06@github.com>
Message-ID: <2g_Hm5UuVBqoklekkaxtnYn05JYKmosnzaMefQi_q3s=.aea039bb-d80c-4863-986b-d73d7cf71fcc@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 alanb at openjdk.org  Mon Oct 14 14:26:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 14 Oct 2024 14:26:15 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <Rd5Q3wc6sWFHwg1UH6WJjCjX2wDXhXxRFbKYJJ43ttk=.c160e1cf-0b9f-40bb-a922-756bcc1018ee@github.com>

On Mon, 14 Oct 2024 12:46:29 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 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 350:

> 348:      */
> 349:     private Builder readModuleAttribute(DataInput in, ConstantPool cpool, int major,
> 350:                                         boolean previewClassfile)

It's isPreview in the caller, would be clearer to use the same here.

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 421:

> 419:                     && ((mods.contains(Requires.Modifier.TRANSITIVE) &&
> 420:                          !previewClassfile &&
> 421:                          !mn.startsWith("java."))

Just to double, will be JLS update specify that it's only allow for java.* aggregator modules?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1799608875
PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1799610658

From eirbjo at openjdk.org  Mon Oct 14 14:37:21 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 14 Oct 2024 14:37:21 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs
Message-ID: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>

Please review this PR which speeds up `JarFile::getEntry` lookup significantly for multi-release JAR files.

The changes in this PR are motivated by the following insights:

* `META-INF/versions/` is sparsely populated.
* Most entries are not versioned
* The number of unique versions for each versioned entry is small
* Many JAR files are 'accidentally' multi-release; they use the feature to hide `module-info.class` from Java 8.

Instead of  performing one lookup for every version identified in the JAR, this PR narrows the version search down to only the number of versions found for the entry being looked up, which will most often be zero. This speeds up lookup for non-versioned entries, and provides a more targeted search for versioned entries.

An alternative approach could be to normalize the hash code to use the none-versioned name such that versioned and non-versioned names would be resolved in the same lookup. This was quickly abandoned since the code changes were intrusive and mixed too many JAR specific concerns into `ZipFile`.

Testing: The existing `JarFileGetEntry` benchmark is updated to optionally test a multi-release JAR file with one versioned entry for `module-info.class` plus two other versioned class files for two distinct versions. Performance results in [first comment](#issuecomment-2410901754).

Running `ZipFileOpen` on a multi-release JAR did not show a significat difference between this PR and mainline. 

The JAR and ZIP tests are run locally. GHA results green. The `noreg-perf` label is added in JBS.

-------------

Commit messages:
 - Update field comment for metaVersions
 - Update copyright year
 - Only check versions for the particular entry being looked up

Changes: https://git.openjdk.org/jdk/pull/21489/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342040
  Stats: 54 lines in 4 files changed: 31 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/21489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21489/head:pull/21489

PR: https://git.openjdk.org/jdk/pull/21489

From eirbjo at openjdk.org  Mon Oct 14 14:37:22 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 14 Oct 2024 14:37:22 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs
In-Reply-To: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
Message-ID: <KHT2dY9mrpnJs4W3I9Oc7NXb1_xTNr-sMy6wzLgEc0E=.8905709d-9e03-4a63-bb54-dd7a6110ef10@github.com>

On Mon, 14 Oct 2024 11:01:21 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which speeds up `JarFile::getEntry` lookup significantly for multi-release JAR files.
> 
> The changes in this PR are motivated by the following insights:
> 
> * `META-INF/versions/` is sparsely populated.
> * Most entries are not versioned
> * The number of unique versions for each versioned entry is small
> * Many JAR files are 'accidentally' multi-release; they use the feature to hide `module-info.class` from Java 8.
> 
> Instead of  performing one lookup for every version identified in the JAR, this PR narrows the version search down to only the number of versions found for the entry being looked up, which will most often be zero. This speeds up lookup for non-versioned entries, and provides a more targeted search for versioned entries.
> 
> An alternative approach could be to normalize the hash code to use the none-versioned name such that versioned and non-versioned names would be resolved in the same lookup. This was quickly abandoned since the code changes were intrusive and mixed too many JAR specific concerns into `ZipFile`.
> 
> Testing: The existing `JarFileGetEntry` benchmark is updated to optionally test a multi-release JAR file with one versioned entry for `module-info.class` plus two other versioned class files for two distinct versions. Performance results in [first comment](#issuecomment-2410901754).
> 
> Running `ZipFileOpen` on a multi-release JAR did not show a significat difference between this PR and mainline. 
> 
> The JAR and ZIP tests are run locally. GHA results green. The `noreg-perf` label is added in JBS.

Performance results:

Baseline:


JarFileGetEntry.getEntryHit           false    1024  avgt   15   64.619 ? 6.633  ns/op
JarFileGetEntry.getEntryHit            true    1024  avgt   15  301.770 ? 4.819  ns/op
JarFileGetEntry.getEntryHitUncached   false    1024  avgt   15   82.030 ? 2.057  ns/op
JarFileGetEntry.getEntryHitUncached    true    1024  avgt   15  327.966 ? 3.092  ns/op
JarFileGetEntry.getEntryMiss          false    1024  avgt   15   27.937 ? 0.982  ns/op
JarFileGetEntry.getEntryMiss           true    1024  avgt   15  267.280 ? 2.196  ns/op
JarFileGetEntry.getEntryMissUncached  false    1024  avgt   15   53.214 ? 1.085  ns/op
JarFileGetEntry.getEntryMissUncached   true    1024  avgt   15  290.904 ? 2.359  ns/op


PR:


Benchmark                              (mr)  (size)  Mode  Cnt   Score   Error  Units
JarFileGetEntry.getEntryHit           false    1024  avgt   15  63.311 ? 3.014  ns/op
JarFileGetEntry.getEntryHit            true    1024  avgt   15  71.333 ? 1.510  ns/op
JarFileGetEntry.getEntryHitUncached   false    1024  avgt   15  80.401 ? 0.516  ns/op
JarFileGetEntry.getEntryHitUncached    true    1024  avgt   15  94.810 ? 1.136  ns/op
JarFileGetEntry.getEntryMiss          false    1024  avgt   15  26.717 ? 0.276  ns/op
JarFileGetEntry.getEntryMiss           true    1024  avgt   15  45.677 ? 0.412  ns/op
JarFileGetEntry.getEntryMissUncached  false    1024  avgt   15  53.122 ? 0.954  ns/op
JarFileGetEntry.getEntryMissUncached   true    1024  avgt   15  66.583 ? 0.425  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21489#issuecomment-2410901754

From aph at openjdk.org  Mon Oct 14 14:44:12 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 14:44:12 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v3]
In-Reply-To: <hq9kyxTFvSrKRsDfstHkUaMm0wAxCWO7BaDSfkqyuig=.9ced3392-3ecf-4766-9e95-b5c1da9c6ad3@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
 <hq9kyxTFvSrKRsDfstHkUaMm0wAxCWO7BaDSfkqyuig=.9ced3392-3ecf-4766-9e95-b5c1da9c6ad3@github.com>
Message-ID: <hFttk2LTzyJug5mhQSivQSlhKlg3JcPRagts-k69jfY=.544b3b60-2420-410f-914c-a12cad02b70b@github.com>

On Mon, 14 Oct 2024 13:40:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The fourth preview of scoped values.
>
> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Scoped values
>  - Scoped values

Tier1 and Tier2 done. I had one tier2 failure, java/net/URL/EarlyOrDelayedParsing.java. I don't think that's anything to do with these changes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21456#issuecomment-2411463381

From jkarthikeyan at openjdk.org  Mon Oct 14 15:07:21 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Mon, 14 Oct 2024 15:07:21 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
Message-ID: <LVbFDa_FZ_V5orhL67wpHeIm7Jx4YFFmPVyQvpERKpY=.15e52f7c-5233-4813-a95f-a3300afe9ae2@github.com>

On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2411538179

From rgiulietti at openjdk.org  Mon Oct 14 15:11:21 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 14 Oct 2024 15:11:21 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
Message-ID: <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>

On Sun, 13 Oct 2024 22:45:25 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added mathematical comments for maxPowsOf5

Will approve in a couple of days if by then there are no other substantial changes.

src/java.base/share/classes/java/math/BigDecimal.java line 5280:

> 5278:         BigInteger[] qr; // quotient-remainder pair
> 5279:         // Remove 5^(2^i) from the factors of intVal, until 5^remainingZeros < 5^(2^i)
> 5280:         // (i.e., there are too few powers of five left to remove).

It's a bit unclear what's meant here with "_too few_ powers of five left to remove".
Can we have something more explicit?

src/java.base/share/classes/java/math/BigDecimal.java line 5297:

> 5295:         // bitLength(remainingZeros) == min{n >= 0 : 5^(2^n) > 5^remainingZeros}
> 5296:         // so, while the loop condition is true,
> 5297:         // the invariant i == max{n : 5^(2^n) <= 5^remainingZeros}

Suggestion:

        // the invariant i == max{n : 5^(2^n) <= 5^remainingZeros},
        // which is equivalent to i = bitLengthForLong(remainingZeros) - 1,

-------------

PR Review: https://git.openjdk.org/jdk/pull/21323#pullrequestreview-2366952196
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1799690935
PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1799691009

From duke at openjdk.org  Mon Oct 14 15:19:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Oct 2024 15:19:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
Message-ID: <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>

On Mon, 14 Oct 2024 15:06:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added mathematical comments for maxPowsOf5
>
> src/java.base/share/classes/java/math/BigDecimal.java line 5280:
> 
>> 5278:         BigInteger[] qr; // quotient-remainder pair
>> 5279:         // Remove 5^(2^i) from the factors of intVal, until 5^remainingZeros < 5^(2^i)
>> 5280:         // (i.e., there are too few powers of five left to remove).
> 
> It's a bit unclear what's meant here with "_too few_ powers of five left to remove".
> Can we have something more explicit?

It's hard for me to think of something more explicit than the mathematical definitions already present in the comments...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1799704982

From duke at openjdk.org  Mon Oct 14 15:28:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Oct 2024 15:28:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
Message-ID: <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>

On Mon, 14 Oct 2024 15:16:49 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 5280:
>> 
>>> 5278:         BigInteger[] qr; // quotient-remainder pair
>>> 5279:         // Remove 5^(2^i) from the factors of intVal, until 5^remainingZeros < 5^(2^i)
>>> 5280:         // (i.e., there are too few powers of five left to remove).
>> 
>> It's a bit unclear what's meant here with "_too few_ powers of five left to remove".
>> Can we have something more explicit?
>
> It's hard for me to think of something more explicit than the mathematical definitions already present in the comments...

Maybe something like "too few powers of five left to remove with respect to the maximum number of removable zeros in the original value of intVal", I can't think of anything better for now...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1799717603

From rgiulietti at openjdk.org  Mon Oct 14 15:33:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 14 Oct 2024 15:33:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
Message-ID: <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>

On Mon, 14 Oct 2024 15:25:44 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> It's hard for me to think of something more explicit than the mathematical definitions already present in the comments...
>
> Maybe something like "too few powers of five left to remove with respect to the maximum number of removable zeros in the original value of intVal", I can't think of anything better for now...

OK, let me give it a try, maybe tomorrow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1799723701

From psandoz at openjdk.org  Mon Oct 14 15:37:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 14 Oct 2024 15:37:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
Message-ID: <UsqqMNHzM7w57ZAtry8JImA2Ol3i749xdBlNinxA9_Y=.7602385d-b323-4fab-bfdc-70e5ded2bdd0@github.com>

On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating tests to use floorMod

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2367019017

From aph at openjdk.org  Mon Oct 14 15:39:31 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 14 Oct 2024 15:39:31 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v4]
In-Reply-To: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
Message-ID: <AXDTliN3zhOrLYIg7Woe2P5MLvmaYOzIAU_Oy3qovKU=.66f25aad-943d-4601-8dfd-f9c4dcae0f3a@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 seven additional commits since the last revision:

 - 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/90a344a3..052553ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=02-03

  Stats: 7874 lines in 151 files changed: 7141 ins; 234 del; 499 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 naoto at openjdk.org  Mon Oct 14 15:42:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Oct 2024 15:42:13 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b [v4]
In-Reply-To: <Y0scCRnE7CerLHOA2D7r1P7gWD7Tjzhix3wPEiGzidw=.a0b98380-4308-404c-82f7-d798e5ea4522@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
 <Y0scCRnE7CerLHOA2D7r1P7gWD7Tjzhix3wPEiGzidw=.a0b98380-4308-404c-82f7-d798e5ea4522@github.com>
Message-ID: <6isNL4X6OW5JSZEYXuJWFGyh0j6kftFvGiXQKtSu3V4=.f189323e-257d-4d65-89e3-70bb120d1ca2@github.com>

On Mon, 14 Oct 2024 04:13:46 GMT, Johny Jose <duke at openjdk.org> wrote:

>> Timezone data 2024b changes
>
> Johny Jose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review changes

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21265#pullrequestreview-2367031598

From duke at openjdk.org  Mon Oct 14 15:47:13 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Oct 2024 15:47:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
Message-ID: <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>

On Mon, 14 Oct 2024 15:30:16 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Maybe something like "too few powers of five left to remove with respect to the number of removable zeros in the initial value of intVal", I can't think of anything better for now...
>
> OK, let me give it a try, maybe tomorrow.

@rgiulietti Or maybe "i.e., 5^(2^i) is larger than the largest power of five that is still removable from intVal", could it be ok?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1799742736

From rfscholte at apache.org  Sun Oct 13 11:53:44 2024
From: rfscholte at apache.org (Robert Scholte)
Date: Sun, 13 Oct 2024 13:53:44 +0200
Subject: ServiceLoader fails for Java 23 with preview enabled
Message-ID: <012901db1d66$8e348d40$aa9da7c0$@apache.org>

Hi,

 

It seems there's a change in the ServiceLoader, and it looks like regression
to me.

I've created a small project to reproduce it (I can provide it if wanted and
confirmed this is indeed a bug).

 

What it basically does is just: 

ServiceLoader.load(Car.class).findFirst().orElseThrow();

 

This succeeds with OpenJDK 22 (with and without preview enabled flag)

 

It also succeeds with OpenJDK 23 without the preview flag.

 

However, when adding the preview flag I get:

 

java.util.NoSuchElementException: No value present

        at java.base/java.util.Optional.orElseThrow(Optional.java:377)

        at
nl.sourcegrounds.serviceloader.tck.CarTest.<init>(CarTest.java:16)

 

Anyone who can already explain this with this small amount of information?

 

Thanks,

Robert Scholte

 

These are the details for both versions (Windows OS)

 

openjdk version "22" 2024-03-19

OpenJDK Runtime Environment (build 22+36-2370)

OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)

 

 

openjdk version "23" 2024-09-17

OpenJDK Runtime Environment (build 23+37-2369)

OpenJDK 64-Bit Server VM (build 23+37-2369, mixed mode, sharing)

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241013/220668b6/attachment-0001.htm>

From jpai at openjdk.org  Mon Oct 14 15:56:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 14 Oct 2024 15:56:19 GMT
Subject: RFR: 8341593: Problemlist java/foreign/TestUpcallStress.java in
 Xcomp mode
In-Reply-To: <OyJB8JgYuk6oNtoh9JCIyYxN-6HXp3QPP015v2d1itg=.35a94c53-8ca0-4761-a3dd-8cfdf97fb6e1@github.com>
References: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
 <OyJB8JgYuk6oNtoh9JCIyYxN-6HXp3QPP015v2d1itg=.35a94c53-8ca0-4761-a3dd-8cfdf97fb6e1@github.com>
Message-ID: <LqQyD88N_V1uvDAFFAbZCFCHwSP0QRJ8NMhNLq2f3DA=.db3992e4-4244-4754-a0e8-017e2f1a1140@github.com>

On Mon, 7 Oct 2024 14:53:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp mode.
>
> Thanks for the review.

Hello @sendaoYan, I noticed this PR today. For tests that we want to exclude from Xcomp testing, the convention has been to use a `@requires vm.compMode != "Xcomp"` in the test definition of the test case instead of problem listing it. Problemlisting is prefered if there is any genuine issue that needs to be addressed at a later date. In this current case, based on what Jorn noted in this PR, I think the right thing to do would be to use the `@requires` in the test case and remove this test from the problem listing.

I think you can use JDK-8341584 to remove the test from the problem list and use `@requires` instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21375#issuecomment-2411655223

From jai.forums2013 at gmail.com  Mon Oct 14 16:02:18 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 14 Oct 2024 21:32:18 +0530
Subject: ServiceLoader fails for Java 23 with preview enabled
In-Reply-To: <012901db1d66$8e348d40$aa9da7c0$@apache.org>
References: <012901db1d66$8e348d40$aa9da7c0$@apache.org>
Message-ID: <a375ce5c-fab9-40c7-aebb-35c500b473af@gmail.com>

Hello Robert,

This certainly looks like a behavioural change that would need 
investigation. So yes, a reproducer will be helpful.

-Jaikiran

On 13/10/24 5:23 pm, Robert Scholte wrote:
>
> Hi,
>
> It seems there?s a change in the ServiceLoader, and it looks like 
> regression to me.
>
> I?ve created a small project to reproduce it (I can provide it if 
> wanted and confirmed this is indeed a bug).
>
> What it basically does is just:
>
> ServiceLoader.load(Car.class).findFirst().orElseThrow();
>
> This succeeds with OpenJDK 22 (with and without preview enabled flag)
>
> It also succeeds with OpenJDK 23 without the preview flag.
>
> However, when adding the preview flag I get:
>
> java.util.NoSuchElementException: No value present
>
> ??????? at java.base/java.util.Optional.orElseThrow(Optional.java:377)
>
> ??????? at 
> nl.sourcegrounds.serviceloader.tck.CarTest.<init>(CarTest.java:16)
>
> Anyone who can already explain this with this small amount of information?
>
> Thanks,
>
> Robert Scholte
>
> These are the details for both versions (Windows OS)
>
> openjdk version "22" 2024-03-19
>
> OpenJDK Runtime Environment (build 22+36-2370)
>
> OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)
>
> openjdk version "23" 2024-09-17
>
> OpenJDK Runtime Environment (build 23+37-2369)
>
> OpenJDK 64-Bit Server VM (build 23+37-2369, mixed mode, sharing)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241014/cf28cb58/attachment.htm>

From alan.bateman at oracle.com  Mon Oct 14 16:09:05 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 14 Oct 2024 17:09:05 +0100
Subject: ServiceLoader fails for Java 23 with preview enabled
In-Reply-To: <012901db1d66$8e348d40$aa9da7c0$@apache.org>
References: <012901db1d66$8e348d40$aa9da7c0$@apache.org>
Message-ID: <3a25beb0-8d05-44ec-a44c-439c939f657c@oracle.com>


Christian Stein mentioned that this is something to due with Surefire 
not supporting JDK 23 class files, is that right?

-Alan

On 13/10/2024 12:53, Robert Scholte wrote:
>
> Hi,
>
> It seems there?s a change in the ServiceLoader, and it looks like 
> regression to me.
>
> I?ve created a small project to reproduce it (I can provide it if 
> wanted and confirmed this is indeed a bug).
>
> What it basically does is just:
>
> ServiceLoader.load(Car.class).findFirst().orElseThrow();
>
> This succeeds with OpenJDK 22 (with and without preview enabled flag)
>
> It also succeeds with OpenJDK 23 without the preview flag.
>
> However, when adding the preview flag I get:
>
> java.util.NoSuchElementException: No value present
>
> ??????? at java.base/java.util.Optional.orElseThrow(Optional.java:377)
>
> ??????? at 
> nl.sourcegrounds.serviceloader.tck.CarTest.<init>(CarTest.java:16)
>
> Anyone who can already explain this with this small amount of information?
>
> Thanks,
>
> Robert Scholte
>
> These are the details for both versions (Windows OS)
>
> openjdk version "22" 2024-03-19
>
> OpenJDK Runtime Environment (build 22+36-2370)
>
> OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)
>
> openjdk version "23" 2024-09-17
>
> OpenJDK Runtime Environment (build 23+37-2369)
>
> OpenJDK 64-Bit Server VM (build 23+37-2369, mixed mode, sharing)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241014/c387343d/attachment-0001.htm>

From alexey.semenyuk at oracle.com  Mon Oct 14 16:12:14 2024
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Mon, 14 Oct 2024 12:12:14 -0400
Subject: Running a jpackage app-image inside Flatpak
In-Reply-To: <06d87ce2-30be-4bd7-a1c9-4fc276ad7acf@io7m.com>
References: <06d87ce2-30be-4bd7-a1c9-4fc276ad7acf@io7m.com>
Message-ID: <fead7c77-1d4d-4c27-b22c-9858636f4992@oracle.com>

Hi Mark,

Try running app launcher with JPACKAGE_DEBUG env variable set to "true":

$ env JPACKAGE_DEBUG=true /app/bin/example


It will produce debug output in the console that might give a clue what 
went wrong.

- Alexey


On 10/5/2024 10:15 AM, Mark Raynsford wrote:
> Hello!
>
> I've been working on some tools to produce Flatpaks[1].
>
> My thinking was that I could use jpackage to produce an app-image and
> then simply copy that app-image into a Flatpak and run it that way.
>
> This almost works, except that it seems that the actual executable
> produced by jpackage doesn't work, although running (ostensibly) the
> same thing the executable _would_ run via the "java" executable does
> work. So for example, inside the Flatpak:
>
> $ /app/bin/example
>
> ... Fails silently, returning a 1 exit code. But:
>
> $ /app/lib/runtime/bin/java -p /app/lib/app/mods -m
> com.io7m.example/com.io7m.example.Main
>
> ... Runs the application without issue.
>
> Running the application with strace doesn't show anything that looks
> obviously wrong to me.
>
> I feel like the only difference between those two invocations is that
> the executable goes through libapplauncher.so to load the application
> .cfg file produced by jpackage.
>
> I did notice something slightly suspicious on the libapplauncher.so
> binary itself:
>
> $ ldd /app/lib/libapplauncher.so
> /app/lib/libapplauncher.so: /usr/lib/x86_64-linux-gnu/libstdc++.so.6:
> version `CXXABI_1.3.15' not found (required by /app/lib/libapplauncher.so)
> ...
>
> Would this be enough to cause an otherwise silent failure?
>
> [1] https://www.flatpak.org/
>


From uschindler at apache.org  Mon Oct 14 16:39:54 2024
From: uschindler at apache.org (Uwe Schindler)
Date: Mon, 14 Oct 2024 18:39:54 +0200
Subject: ServiceLoader fails for Java 23 with preview enabled
In-Reply-To: <012901db1d66$8e348d40$aa9da7c0$@apache.org>
References: <012901db1d66$8e348d40$aa9da7c0$@apache.org>
Message-ID: <effe1df9-c9cd-4fca-987c-19ce5263da3a@apache.org>

Hi,

I cannot confirm this. Apache Lucene (just released today in version 
10.0.0, but also previous veersion 9.12.0) can open indexes just fine, 
both with preview enabled or not. I modified the start script of the 
"Luke" GUI to use classpath mode and add the "--enable-preview" flag. 
All variants work (SPI from declared module-info.class SPIs or using 
META-INF/services).

If ServiceLoader won't work, Lucene would fails to open any indexes.

To test, just download Apache Lucene, put JDK 23 as first entry on your 
$PATH and start bin/luke.sh. To test other variants change the script 
file by changing to use classpath mode (by invoking 
"org.apache.lucene.luke.app.desktop.LukeMain" class directly and change 
module-path to classpath with "/*").

Uwe

Am 13.10.2024 um 13:53 schrieb Robert Scholte:
>
> Hi,
>
> It seems there?s a change in the ServiceLoader, and it looks like 
> regression to me.
>
> I?ve created a small project to reproduce it (I can provide it if 
> wanted and confirmed this is indeed a bug).
>
> What it basically does is just:
>
> ServiceLoader.load(Car.class).findFirst().orElseThrow();
>
> This succeeds with OpenJDK 22 (with and without preview enabled flag)
>
> It also succeeds with OpenJDK 23 without the preview flag.
>
> However, when adding the preview flag I get:
>
> java.util.NoSuchElementException: No value present
>
> ??????? at java.base/java.util.Optional.orElseThrow(Optional.java:377)
>
> ??????? at 
> nl.sourcegrounds.serviceloader.tck.CarTest.<init>(CarTest.java:16)
>
> Anyone who can already explain this with this small amount of information?
>
> Thanks,
>
> Robert Scholte
>
> These are the details for both versions (Windows OS)
>
> openjdk version "22" 2024-03-19
>
> OpenJDK Runtime Environment (build 22+36-2370)
>
> OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)
>
> openjdk version "23" 2024-09-17
>
> OpenJDK Runtime Environment (build 23+37-2369)
>
> OpenJDK 64-Bit Server VM (build 23+37-2369, mixed mode, sharing)
>
-- 
Uwe Schindler
uschindler at apache.org 
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241014/c2ea8a6a/attachment.htm>

From pminborg at openjdk.org  Mon Oct 14 17:03:49 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 14 Oct 2024 17:03:49 GMT
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
Message-ID: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>

This PR suggests fixing a problem on big-endian platforms.

-------------

Commit messages:
 - Remove debug info
 - Add debug logs
 - Use another way for BE
 - Merge branch 'master' into mismatch-big-endian
 - Always use little endian in get operations

Changes: https://git.openjdk.org/jdk/pull/21258/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21258&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340189
  Stats: 17 lines in 1 file changed: 0 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21258/head:pull/21258

PR: https://git.openjdk.org/jdk/pull/21258

From amitkumar at openjdk.org  Mon Oct 14 17:03:49 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 14 Oct 2024 17:03:49 GMT
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
Message-ID: <A2wn-lAJzQmC_IEwXOLI0NzR7xiChC2_fRY3q5yo_uQ=.914253cf-f74e-4b4f-9926-127fa1b8d4af@github.com>

On Mon, 30 Sep 2024 09:19:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests fixing a problem on big-endian platforms.

@minborg , I am still getting error on s390x (big endian): 

STDOUT:
test TestMismatch.random(): failure [197ms]
java.lang.AssertionError: expected [1] but found [0]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.random(TestMismatch.java:163)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)
test TestMismatch.testClosed(): success [8ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 16 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 79db868b, jdk.internal.foreign.NativeMemorySegmentImpl at 1d41d265): failure [18ms]
java.lang.AssertionError: expected [15] but found [8]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.testDifferentValues(TestMismatch.java:200)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 289e3d63, jdk.internal.foreign.NativeMemorySegmentImpl at 3bdf10ef): failure [0ms]
java.lang.AssertionError: expected [7] but found [0]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.testDifferentValues(TestMismatch.java:203)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134678, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3076fab5, jdk.internal.foreign.NativeMemorySegmentImpl at 736ddc3c): failure [1ms]
java.lang.AssertionError: expected [7] but found [0]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.testDifferentValues(TestMismatch.java:203)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 7494a82d, jdk.internal.foreign.NativeMemorySegmentImpl at 73305758): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134671, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 43d0c28b, jdk.internal.foreign.NativeMemorySegmentImpl at 12d4df1c): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134672, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 226addb, jdk.internal.foreign.NativeMemorySegmentImpl at 4727e38e): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134673, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 6e09453f, jdk.internal.foreign.NativeMemorySegmentImpl at 59f67550): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134674, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 2dc49fbc, jdk.internal.foreign.NativeMemorySegmentImpl at 9c00786): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134675, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 6c7f7b48, jdk.internal.foreign.NativeMemorySegmentImpl at 654f3004): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134676, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3ae203e7, jdk.internal.foreign.NativeMemorySegmentImpl at 2dd08ac8): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134677, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at aba434d, jdk.internal.foreign.NativeMemorySegmentImpl at 20ed94c6): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134678, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 22692de7, jdk.internal.foreign.NativeMemorySegmentImpl at 7a91b2cc): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134679, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 292d64e3, jdk.internal.foreign.NativeMemorySegmentImpl at 42c07234): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467a, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 31358a9a, jdk.internal.foreign.NativeMemorySegmentImpl at 737dea23): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467b, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 29615aa, jdk.internal.foreign.NativeMemorySegmentImpl at 1fea2e38): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467c, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 5ad384e2, jdk.internal.foreign.NativeMemorySegmentImpl at 685af157): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467d, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 72199c1c, jdk.internal.foreign.NativeMemorySegmentImpl at 342bf229): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467e, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 515de689, jdk.internal.foreign.NativeMemorySegmentImpl at 6f1a69c2): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467f, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 2ccab064, jdk.internal.foreign.NativeMemorySegmentImpl at 121d62da): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x0, byteSize: 16 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 71863d10, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 751e725f): failure [1ms]
java.lang.AssertionError: expected [15] but found [8]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.testDifferentValues(TestMismatch.java:200)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x0, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 4a4103b4, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 4ccb1c29): failure [0ms]
java.lang.AssertionError: expected [7] but found [0]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.testDifferentValues(TestMismatch.java:203)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x8, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3d618d5b, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 29dfe48a): failure [0ms]
java.lang.AssertionError: expected [7] but found [0]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.testDifferentValues(TestMismatch.java:203)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x0, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 5598151d, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 642241a0): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x1, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 14647199, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 1c1aef5): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x2, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3dcd8317, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at a92c58e): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x3, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3700cd66, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 660425aa): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x4, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3feab836, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at eb02950): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x5, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 2a16399, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 68e050f3): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x6, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 5d535201, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 54674f99): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x7, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 7140364b, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 3644b138): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x8, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 31e3815c, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 41e10b45): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x9, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 38000c2, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 2ec4888f): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xa, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 485fe0d8, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 4bda7f01): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xb, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 16988c83, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 2176e7a8): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xc, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 786d6fe2, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 2ac318f8): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xd, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 60b9abea, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 7338da60): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xe, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at a569a20, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 279d867b): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xf, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 23bd5e7d, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 1d8447b0): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 8 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 16 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 10b33405, jdk.internal.foreign.NativeMemorySegmentImpl at 2fb54864): failure [1ms]
java.lang.AssertionError: expected [7] but found [0]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.testDifferentValues(TestMismatch.java:208)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 8 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 2400da3, jdk.internal.foreign.NativeMemorySegmentImpl at 7b393e7): failure [0ms]
java.lang.AssertionError: expected [7] but found [0]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
	at org.testng.Assert.assertEquals(Assert.java:122)
	at org.testng.Assert.assertEquals(Assert.java:797)
	at org.testng.Assert.assertEquals(Assert.java:807)
	at TestMismatch.testDifferentValues(TestMismatch.java:200)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:10

...
Output overflow:
JT Harness has limited the test output to the text
at the beginning and the end, so that you can see how the
test began, and how it completed.

If you need to see more of the output from the test,
set the system property javatest.maxOutputSize to a higher
value. The current value is 100000
...

=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 6a7bd57d): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 134a4987): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 572f7c5b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 4ace38e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 175220fd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 6d153923): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 4aa79e20): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 3098562b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 2a74f1d5): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 2973980f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 593add7f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 72a8cb41): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 42a772bf): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 45fe21cd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 142ed8c2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 72fc2e6b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 2a3659): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 760db5be): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 45560d6e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 3193ac23): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 2b619db4): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 6f1b3e9e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 583ad1a2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 64d437e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 7c6f63e0): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 373a571): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 46ce7521): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 7d0ec2ed): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 421bc22a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 6f391808): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 4a6b54b9): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 54191071): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 7cb42822): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 11289dde): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 41a6cd46): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 359c4bca): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at c7eae01): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 4498b47a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 6a7bd57d): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 134a4987): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 572f7c5b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 4ace38e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 175220fd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 6d153923): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 4aa79e20): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 3098562b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 2a74f1d5): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 2973980f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 593add7f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 72a8cb41): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 42a772bf): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 45fe21cd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 142ed8c2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 72fc2e6b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 2a3659): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 760db5be): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 45560d6e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 3193ac23): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 2b619db4): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 6f1b3e9e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 583ad1a2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 64d437e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 7c6f63e0): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 373a571): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 46ce7521): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 7d0ec2ed): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 421bc22a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 6f391808): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 4a6b54b9): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 54191071): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 7cb42822): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 11289dde): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 41a6cd46): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 359c4bca): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at c7eae01): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 4498b47a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 6a7bd57d): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 134a4987): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 572f7c5b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 4ace38e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 175220fd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 6d153923): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 4aa79e20): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 3098562b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 2a74f1d5): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 2973980f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 593add7f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 72a8cb41): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 42a772bf): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 45fe21cd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 142ed8c2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 72fc2e6b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 2a3659): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 760db5be): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 45560d6e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 3193ac23): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 2b619db4): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 6f1b3e9e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 583ad1a2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 64d437e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 7c6f63e0): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 373a571): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 46ce7521): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 7d0ec2ed): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 421bc22a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 6f391808): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 4a6b54b9): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 54191071): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 7cb42822): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 11289dde): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 41a6cd46): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 359c4bca): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at c7eae01): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 4498b47a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 6a7bd57d): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 134a4987): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 572f7c5b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 4ace38e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 175220fd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 6d153923): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 4aa79e20): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 3098562b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 2a74f1d5): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 2973980f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 593add7f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 72a8cb41): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 42a772bf): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 45fe21cd): success [0ms]
test TestMismatch.testThreadAccess(): success [13ms]

===============================================
java/foreign/TestMismatch.java
Total tests run: 14446, Passes: 14372, Failures: 74, Skips: 0
===============================================

STDERR:
java.lang.Exception: failures: 74
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:108)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)

JavaTest Message: Test threw exception: java.lang.Exception
JavaTest Message: shutting down test


TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 74
--------------------------------------------------
Test results: failed: 1
Report written to /home/amit/jdk/build/linux-s390x-server-fastdebug/test-results/jtreg_test_jdk_java_foreign_TestMismatch_java/html/report.html
Results written to /home/amit/jdk/build/linux-s390x-server-fastdebug/test-support/jtreg_test_jdk_java_foreign_TestMismatch_java
Error: Some tests failed or other problems occurred.
Finished running test 'jtreg:./test/jdk/java/foreign/TestMismatch.java'
Test report is stored in build/linux-s390x-server-fastdebug/test-results/jtreg_test_jdk_java_foreign_TestMismatch_java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:./test/jdk/java/foreign/TestMismatch.java       1     0     1     0 <<
==============================
TEST FAILURE

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21258#issuecomment-2382665498

From mdoerr at openjdk.org  Mon Oct 14 17:03:49 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 14 Oct 2024 17:03:49 GMT
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <A2wn-lAJzQmC_IEwXOLI0NzR7xiChC2_fRY3q5yo_uQ=.914253cf-f74e-4b4f-9926-127fa1b8d4af@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
 <A2wn-lAJzQmC_IEwXOLI0NzR7xiChC2_fRY3q5yo_uQ=.914253cf-f74e-4b4f-9926-127fa1b8d4af@github.com>
Message-ID: <kZKjmMYK9N1bt29aE4hNGIPFmzC2u0WVnyAc7NCKT4E=.2c8a4333-6907-40f7-b8a9-722375f575c4@github.com>

On Mon, 30 Sep 2024 09:57:11 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This PR suggests fixing a problem on big-endian platforms.
>
> @minborg , I am still getting error on s390x (big endian): 
> 
> STDOUT:
> test TestMismatch.random(): failure [197ms]
> java.lang.AssertionError: expected [1] but found [0]
> 	at org.testng.Assert.fail(Assert.java:99)
> 	at org.testng.Assert.failNotEquals(Assert.java:1037)
> 	at org.testng.Assert.assertEqualsImpl(Assert.java:140)
> 	at org.testng.Assert.assertEquals(Assert.java:122)
> 	at org.testng.Assert.assertEquals(Assert.java:797)
> 	at org.testng.Assert.assertEquals(Assert.java:807)
> 	at TestMismatch.random(TestMismatch.java:163)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> 	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> 	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> 	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> 	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
> 	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
> 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:764)
> 	at org.testng.TestRunner.run(TestRunner.java:585)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> 	at org.testng.TestNG.runSuites(TestNG.java:1069)
> 	at org.testng.TestNG.run(TestNG.java:1037)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> 	at java.base/java.lang.Thread.run(Thread.java:1576)
> test TestMismatch.testClos...

Thanks for testing, @offamitkumar!
@minborg: My first guess was wrong. The change is too big to see immediately what could be wrong. Is there anything we can take out to isolate the problem? Does the error message provide a valuable hint?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21258#issuecomment-2389752610

From per-ake.minborg at oracle.com  Mon Oct 14 17:12:12 2024
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 14 Oct 2024 17:12:12 +0000
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <A2wn-lAJzQmC_IEwXOLI0NzR7xiChC2_fRY3q5yo_uQ=.914253cf-f74e-4b4f-9926-127fa1b8d4af@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
 <A2wn-lAJzQmC_IEwXOLI0NzR7xiChC2_fRY3q5yo_uQ=.914253cf-f74e-4b4f-9926-127fa1b8d4af@github.com>
Message-ID: <CH2PR10MB427914AA384B8B44F37FC156DA442@CH2PR10MB4279.namprd10.prod.outlook.com>

I am confused as I saw this in a recent mail:

"
Test is passing with current changes.

Thanks,
Amit
"

What did I miss?

/Per

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Amit Kumar <amitkumar at openjdk.org>
Sent: Monday, October 14, 2024 7:03 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: RFR: 8340189: 8339531 incorrect for Big Endian platforms

On Mon, 30 Sep 2024 09:19:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests fixing a problem on big-endian platforms.

@minborg , I am still getting error on s390x (big endian):

STDOUT:
test TestMismatch.random(): failure [197ms]
java.lang.AssertionError: expected [1] but found [0]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.random(TestMismatch.java:163)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)
test TestMismatch.testClosed(): success [8ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 16 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 79db868b, jdk.internal.foreign.NativeMemorySegmentImpl at 1d41d265): failure [18ms]
java.lang.AssertionError: expected [15] but found [8]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.testDifferentValues(TestMismatch.java:200)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 289e3d63, jdk.internal.foreign.NativeMemorySegmentImpl at 3bdf10ef): failure [0ms]
java.lang.AssertionError: expected [7] but found [0]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.testDifferentValues(TestMismatch.java:203)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134678, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3076fab5, jdk.internal.foreign.NativeMemorySegmentImpl at 736ddc3c): failure [1ms]
java.lang.AssertionError: expected [7] but found [0]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.testDifferentValues(TestMismatch.java:203)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 7494a82d, jdk.internal.foreign.NativeMemorySegmentImpl at 73305758): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134671, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 43d0c28b, jdk.internal.foreign.NativeMemorySegmentImpl at 12d4df1c): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134672, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 226addb, jdk.internal.foreign.NativeMemorySegmentImpl at 4727e38e): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134673, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 6e09453f, jdk.internal.foreign.NativeMemorySegmentImpl at 59f67550): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134674, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 2dc49fbc, jdk.internal.foreign.NativeMemorySegmentImpl at 9c00786): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134675, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 6c7f7b48, jdk.internal.foreign.NativeMemorySegmentImpl at 654f3004): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134676, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3ae203e7, jdk.internal.foreign.NativeMemorySegmentImpl at 2dd08ac8): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134677, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at aba434d, jdk.internal.foreign.NativeMemorySegmentImpl at 20ed94c6): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134678, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 22692de7, jdk.internal.foreign.NativeMemorySegmentImpl at 7a91b2cc): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff10134679, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 292d64e3, jdk.internal.foreign.NativeMemorySegmentImpl at 42c07234): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467a, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 31358a9a, jdk.internal.foreign.NativeMemorySegmentImpl at 737dea23): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467b, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 29615aa, jdk.internal.foreign.NativeMemorySegmentImpl at 1fea2e38): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467c, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 5ad384e2, jdk.internal.foreign.NativeMemorySegmentImpl at 685af157): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467d, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 72199c1c, jdk.internal.foreign.NativeMemorySegmentImpl at 342bf229): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467e, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 515de689, jdk.internal.foreign.NativeMemorySegmentImpl at 6f1a69c2): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ address: 0x3ff1013467f, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 2ccab064, jdk.internal.foreign.NativeMemorySegmentImpl at 121d62da): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x0, byteSize: 16 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 71863d10, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 751e725f): failure [1ms]
java.lang.AssertionError: expected [15] but found [8]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.testDifferentValues(TestMismatch.java:200)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x0, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 4a4103b4, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 4ccb1c29): failure [0ms]
java.lang.AssertionError: expected [7] but found [0]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.testDifferentValues(TestMismatch.java:203)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x8, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3d618d5b, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 29dfe48a): failure [0ms]
java.lang.AssertionError: expected [7] but found [0]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.testDifferentValues(TestMismatch.java:203)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x0, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 5598151d, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 642241a0): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x1, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 14647199, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 1c1aef5): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x2, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3dcd8317, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at a92c58e): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x3, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3700cd66, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 660425aa): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x4, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 3feab836, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at eb02950): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x5, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 2a16399, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 68e050f3): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x6, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 5d535201, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 54674f99): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x7, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 7140364b, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 3644b138): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x8, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 31e3815c, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 41e10b45): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0x9, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 38000c2, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 2ec4888f): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xa, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 485fe0d8, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 4bda7f01): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xb, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 16988c83, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 2176e7a8): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xc, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 786d6fe2, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 2ac318f8): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xd, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 60b9abea, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 7338da60): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xe, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at a569a20, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 279d867b): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 16 }, s2:MemorySegment{ heapBase: [B at 71c442ba, address: 0xf, byteSize: 1 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 23bd5e7d, jdk.internal.foreign.HeapMemorySegmentImpl$OfByte at 1d8447b0): success [0ms]
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 8 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 16 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 10b33405, jdk.internal.foreign.NativeMemorySegmentImpl at 2fb54864): failure [1ms]
java.lang.AssertionError: expected [7] but found [0]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.testDifferentValues(TestMismatch.java:208)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:106)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)
testDifferentValues s1:MemorySegment{ address: 0x3ff1012e4f0, byteSize: 8 }, s2:MemorySegment{ address: 0x3ff10134670, byteSize: 8 }
test TestMismatch.testDifferentValues(jdk.internal.foreign.NativeMemorySegmentImpl at 2400da3, jdk.internal.foreign.NativeMemorySegmentImpl at 7b393e7): failure [0ms]
java.lang.AssertionError: expected [7] but found [0]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertEqualsImpl(Assert.java:140)
        at org.testng.Assert.assertEquals(Assert.java:122)
        at org.testng.Assert.assertEquals(Assert.java:797)
        at org.testng.Assert.assertEquals(Assert.java:807)
        at TestMismatch.testDifferentValues(TestMismatch.java:200)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
        at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
        at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
        at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
        at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
        at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
        at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
        at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
        at org.testng.TestRunner.privateRun(TestRunner.java:764)
        at org.testng.TestRunner.run(TestRunner.java:585)
        at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
        at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
        at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
        at org.testng.SuiteRunner.run(SuiteRunner.java:286)
        at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
        at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
        at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
        at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
        at org.testng.TestNG.runSuites(TestNG.java:1069)
        at org.testng.TestNG.run(TestNG.java:1037)
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:10

...
Output overflow:
JT Harness has limited the test output to the text
at the beginning and the end, so that you can see how the
test began, and how it completed.

If you need to see more of the output from the test,
set the system property javatest.maxOutputSize to a higher
value. The current value is 100000
...

=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 6a7bd57d): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 134a4987): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 572f7c5b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 4ace38e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 175220fd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 6d153923): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 4aa79e20): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 3098562b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 2a74f1d5): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 2973980f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 593add7f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 72a8cb41): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 42a772bf): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=12, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 7e76d91d, TestMismatch$SliceOffsetAndSize at 45fe21cd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 142ed8c2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 72fc2e6b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 2a3659): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 760db5be): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 45560d6e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 3193ac23): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 2b619db4): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 6f1b3e9e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 583ad1a2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 64d437e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 7c6f63e0): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 373a571): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 46ce7521): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 7d0ec2ed): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 421bc22a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 6f391808): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 4a6b54b9): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 54191071): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 7cb42822): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 11289dde): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 41a6cd46): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 359c4bca): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at c7eae01): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 4498b47a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 6a7bd57d): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 134a4987): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 572f7c5b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 4ace38e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 175220fd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 6d153923): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 4aa79e20): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 3098562b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 2a74f1d5): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 2973980f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 593add7f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 72a8cb41): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 42a772bf): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=13, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 29f037dd, TestMismatch$SliceOffsetAndSize at 45fe21cd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 142ed8c2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 72fc2e6b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 2a3659): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 760db5be): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 45560d6e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 3193ac23): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 2b619db4): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 6f1b3e9e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 583ad1a2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 64d437e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 7c6f63e0): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 373a571): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 46ce7521): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 7d0ec2ed): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 421bc22a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 6f391808): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 4a6b54b9): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 54191071): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 7cb42822): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 11289dde): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 41a6cd46): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 359c4bca): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at c7eae01): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 4498b47a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 6a7bd57d): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 134a4987): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 572f7c5b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 4ace38e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 175220fd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 6d153923): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 4aa79e20): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 3098562b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 2a74f1d5): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 2973980f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 593add7f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 72a8cb41): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 42a772bf): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=14, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 422ec5d0, TestMismatch$SliceOffsetAndSize at 45fe21cd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 142ed8c2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 72fc2e6b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 2a3659): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 760db5be): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 45560d6e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 3193ac23): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 2b619db4): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 6f1b3e9e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 583ad1a2): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 64d437e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 7c6f63e0): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 373a571): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 46ce7521): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 7d0ec2ed): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 421bc22a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 6f391808): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 4a6b54b9): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 54191071): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ address: 0x3ff1032b090, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 7cb42822): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=16]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 11289dde): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 41a6cd46): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=8]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 359c4bca): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=0, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at c7eae01): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=1, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 4498b47a): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=2, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 6a7bd57d): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=3, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 134a4987): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=4, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 572f7c5b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=5, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 4ace38e): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=6, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 175220fd): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=7, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 6d153923): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=8, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 4aa79e20): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=9, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 3098562b): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=10, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 2a74f1d5): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=11, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 2973980f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=12, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 593add7f): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=13, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 72a8cb41): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=14, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 42a772bf): success [0ms]
testSameValuesStatic s1:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 4c10061d, address: 0x0, byteSize: 16 }, offset=15, size=1], s2:SliceOffsetAndSize[segment=MemorySegment{ heapBase: [B at 2e41e93b, address: 0x0, byteSize: 16 }, offset=15, size=1]
test TestMismatch.testSameValuesStatic(TestMismatch$SliceOffsetAndSize at 50098045, TestMismatch$SliceOffsetAndSize at 45fe21cd): success [0ms]
test TestMismatch.testThreadAccess(): success [13ms]

===============================================
java/foreign/TestMismatch.java
Total tests run: 14446, Passes: 14372, Failures: 74, Skips: 0
===============================================

STDERR:
java.lang.Exception: failures: 74
        at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:108)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:573)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1576)

JavaTest Message: Test threw exception: java.lang.Exception
JavaTest Message: shutting down test


TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 74
--------------------------------------------------
Test results: failed: 1
Report written to /home/amit/jdk/build/linux-s390x-server-fastdebug/test-results/jtreg_test_jdk_java_foreign_TestMismatch_java/html/report.html
Results written to /home/amit/jdk/build/linux-s390x-server-fastdebug/test-support/jtreg_test_jdk_java_foreign_TestMismatch_java
Error: Some tests failed or other problems occurred.
Finished running test 'jtreg:./test/jdk/java/foreign/TestMismatch.java'
Test report is stored in build/linux-s390x-server-fastdebug/test-results/jtreg_test_jdk_java_foreign_TestMismatch_java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:./test/jdk/java/foreign/TestMismatch.java       1     0     1     0 <<
==============================
TEST FAILURE

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21258#issuecomment-2382665498
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241014/aff84e1a/attachment-0001.htm>

From rfscholte at apache.org  Mon Oct 14 17:05:33 2024
From: rfscholte at apache.org (Robert Scholte)
Date: Mon, 14 Oct 2024 19:05:33 +0200
Subject: ServiceLoader fails for Java 23 with preview enabled
In-Reply-To: <3a25beb0-8d05-44ec-a44c-439c939f657c@oracle.com>
References: <012901db1d66$8e348d40$aa9da7c0$@apache.org>
 <3a25beb0-8d05-44ec-a44c-439c939f657c@oracle.com>
Message-ID: <005301db1e5b$4834f910$d89eeb30$@apache.org>

Right, the issue has been solved.

 

The library ended up on the classpath, because the module descriptor could not be read (Classfile API will solve this in the future).

Plexus-java is the library responsible for this.

The latest version op plexus-java supports Java 23, and based on the documentation of the maven-surefire-plugin it should be using the latest version of plexus-java.

What I didn?t notice is that the maven-plugin *overview* says 3.5.0 is the latest maven-surefire-plugin version, whereas the documentation was generated for *3.5.1*.

 

So it was a mismatch in the documentation that confused me.

 

Sorry for the noise,

Robert

 

From: Alan Bateman <alan.bateman at oracle.com> 
Sent: maandag 14 oktober 2024 18:09
To: rfscholte at apache.org; core-libs-dev at openjdk.org
Subject: Re: ServiceLoader fails for Java 23 with preview enabled

 


Christian Stein mentioned that this is something to due with Surefire not supporting JDK 23 class files, is that right?

-Alan

On 13/10/2024 12:53, Robert Scholte wrote:

Hi,

 

It seems there?s a change in the ServiceLoader, and it looks like regression to me.

I?ve created a small project to reproduce it (I can provide it if wanted and confirmed this is indeed a bug).

 

What it basically does is just: 

ServiceLoader.load(Car.class).findFirst().orElseThrow();

 

This succeeds with OpenJDK 22 (with and without preview enabled flag)

 

It also succeeds with OpenJDK 23 without the preview flag.

 

However, when adding the preview flag I get:

 

java.util.NoSuchElementException: No value present

        at java.base/java.util.Optional.orElseThrow(Optional.java:377)

        at nl.sourcegrounds.serviceloader.tck.CarTest.<init>(CarTest.java:16)

 

Anyone who can already explain this with this small amount of information?

 

Thanks,

Robert Scholte

 

These are the details for both versions (Windows OS)

 

openjdk version "22" 2024-03-19

OpenJDK Runtime Environment (build 22+36-2370)

OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)

 

 

openjdk version "23" 2024-09-17

OpenJDK Runtime Environment (build 23+37-2369)

OpenJDK 64-Bit Server VM (build 23+37-2369, mixed mode, sharing)

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241014/7cf4d6ca/attachment.htm>

From liach at openjdk.org  Mon Oct 14 17:24:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Oct 2024 17:24:19 GMT
Subject: RFR: 8317356: Fix missing null checks in the ClassFile API [v2]
In-Reply-To: <4N8U8IZlBtCnhyvamwRyjGP-PtLeEJJ1ZWFFNAGjp0E=.03112658-2220-4cf2-a144-f78c3a478720@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
 <4N8U8IZlBtCnhyvamwRyjGP-PtLeEJJ1ZWFFNAGjp0E=.03112658-2220-4cf2-a144-f78c3a478720@github.com>
Message-ID: <CGUQpYjzd5YmybThWrmBWP-Wf9SpSFnAzjQj4HLFc6U=.aa43449d-2e1d-4d8a-aded-9f76d114b02d@github.com>

On Fri, 11 Oct 2024 16:21:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
>> 
>> Notes:
>> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
>> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
>> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   asotona review remarks

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21458#issuecomment-2411835818

From liach at openjdk.org  Mon Oct 14 17:24:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Oct 2024 17:24:20 GMT
Subject: Integrated: 8317356: Fix missing null checks in the ClassFile API
In-Reply-To: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
References: <sYvku-25Ey98JYfo4wOz2v4LAtKFQsdt72kFoK-777g=.8c4411f0-4646-439b-8fe0-7ca343c03a51@github.com>
Message-ID: <kKPPoL7IgiaNeDgwWtqfm9uwQWgVIWEMVS7B6XiX1V8=.784269a4-dd15-4f2b-92a9-a7c998b080a2@github.com>

On Thu, 10 Oct 2024 19:13:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch that adds a test by @nizarbenalla to perform null checks across the ClassFile API. This is an updated version of #20556 that minimizes impact on our implementation code.
> 
> Notes:
> 1. There's one change in `MethodHandleProxies` to explicitly use platform class loader instead of `null` for boot class loader. Tests work fine.
> 2. The null check test uses the same set of classes as CorpusTest to make it suitable for tier 1.
> 3. The test is not comprehensive; currently it is permissive toward IAE, because sometimes some substitution arguments are invalid, especially primitive ClassDesc or Opcode with wrong types.

This pull request has now been integrated.

Changeset: a2c77522
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2c775222e17a3ba2e388c9a0eb9ffd33efad219
Stats:     262 lines in 36 files changed: 146 ins; 13 del; 103 mod

8317356: Fix missing null checks in the ClassFile API

Co-authored-by: Nizar Benalla <nbenalla at openjdk.org>
Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/21458

From liach at openjdk.org  Mon Oct 14 17:25:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Oct 2024 17:25:22 GMT
Subject: Integrated: 8341924: Improve error message with structurally malformed
 Code array
In-Reply-To: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
References: <MVGjpUHnUS74mCCZbAymZJZantHoBoEui8H9jixNzRI=.af48539e-0fad-4c93-989f-2cd11d4e5bb5@github.com>
Message-ID: <7ko6G-uetrubRkroxD2h-2Vi4mAbzNljFGb24KENj1w=.a683dd73-b87f-42cb-8c12-1081850775b9@github.com>

On Fri, 11 Oct 2024 05:39:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Patch a tableswitch instruction's low value to be greater than a high value, previously, javap will not print any previous instruction and report problematic address/bci to be 0. This is because the iteration of bound models require first collecting all data into a buffer list. We call the eager `forEach` instead to avoid this problem.
> 
> Before:
> 
> $ javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
> Error: error at or after byte 0
> }
> 
> 
> Now:
> 
> $ $localjdk2/bin/javap -c BadSwitch.class
> Compiled from "BadSwitch.java"
> final class BadSwitch {
>   static void work(int);
>     Code:
>        0: iload_0
> Error: error at or after address 1: Invalid tableswitch values low: 9 high: 5
> }

This pull request has now been integrated.

Changeset: bd626442
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd6264420b9f248999dd8387c25c549b08bd193a
Stats:     9 lines in 1 file changed: 2 ins; 0 del; 7 mod

8341924: Improve error message with structurally malformed Code array

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/21463

From bpb at openjdk.org  Mon Oct 14 17:42:45 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 17:42:45 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch dir
Message-ID: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>

Change property `test.src` to `test.dir`.

-------------

Commit messages:
 - 8341997: Tests create files in src tree instead of scratch dir

Changes: https://git.openjdk.org/jdk/pull/21503/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341997
  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21503.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21503/head:pull/21503

PR: https://git.openjdk.org/jdk/pull/21503

From jbhateja at openjdk.org  Mon Oct 14 17:50:14 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 14 Oct 2024 17:50:14 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <LVbFDa_FZ_V5orhL67wpHeIm7Jx4YFFmPVyQvpERKpY=.15e52f7c-5233-4813-a95f-a3300afe9ae2@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <LVbFDa_FZ_V5orhL67wpHeIm7Jx4YFFmPVyQvpERKpY=.15e52f7c-5233-4813-a95f-a3300afe9ae2@github.com>
Message-ID: <To-H_9U4QY2FqB2D_kRKrHxAND2gSmcN3iQhMKW9quw=.2e0872ae-3a46-400e-ad32-7c3051b7ff18@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 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2411884206

From erikj at openjdk.org  Mon Oct 14 17:54:09 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Oct 2024 17:54:09 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir
In-Reply-To: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
Message-ID: <TkWFxqqLjnbuuhBp4l7zJ14IMcLNbucK8c2fTypoJjM=.cd6d207d-4d17-4a0a-823e-f967e90b9b6d@github.com>

On Mon, 14 Oct 2024 17:37:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change property `test.src` to `test.dir`.

I can't find any reference to `test.dir` in the jtreg documentation. I would expect to see it here https://openjdk.org/jtreg/tag-spec.html#testvars. My understanding is that you should just use the current working directory for temporary files: https://openjdk.org/jtreg/faq.html#scratch-directory

-------------

PR Review: https://git.openjdk.org/jdk/pull/21503#pullrequestreview-2367294246

From bpb at openjdk.org  Mon Oct 14 17:58:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 17:58:12 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir
In-Reply-To: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
Message-ID: <zgysPI8B4ekLWw88LzJcTPDRLYxfH5OUrqO36olZDio=.f8eecf56-2cb5-46f3-81dc-7f2245432338@github.com>

On Mon, 14 Oct 2024 17:37:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change property `test.src` to `test.dir`.

The property `test.dir` has been used as a convention but I've no problem with changing it to the CWD.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2411903557

From bpb at openjdk.org  Mon Oct 14 18:02:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 18:02:44 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
Message-ID: <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>

> Change property `test.src` to `test.dir`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8341997: Replace test.dir property with CWD

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21503/files
  - new: https://git.openjdk.org/jdk/pull/21503/files/2216404d..0f2af647

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21503&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21503&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21503.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21503/head:pull/21503

PR: https://git.openjdk.org/jdk/pull/21503

From mdoerr at openjdk.org  Mon Oct 14 18:20:10 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 14 Oct 2024 18:20:10 GMT
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
Message-ID: <LFNK4V03VSlMWMQteoDySahr8dbMHWJp3mHlS3mSU_E=.94af9f64-6a1c-47a7-bbaf-a38df13bf2d6@github.com>

On Mon, 30 Sep 2024 09:19:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests fixing a problem on big-endian platforms.

This version uses little endian accesses on big endian machines. This may defeat the purpose of [JDK-8339531](https://bugs.openjdk.org/browse/JDK-8339531) for those platforms. Accesses are typically slower when using them with endianness mismatch. But it looks at least correct.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21258#pullrequestreview-2367346560

From liach at openjdk.org  Mon Oct 14 18:25:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Oct 2024 18:25:11 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs
In-Reply-To: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
Message-ID: <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>

On Mon, 14 Oct 2024 11:01:21 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which speeds up `JarFile::getEntry` lookup significantly for multi-release JAR files.
> 
> The changes in this PR are motivated by the following insights:
> 
> * `META-INF/versions/` is sparsely populated.
> * Most entries are not versioned
> * The number of unique versions for each versioned entry is small
> * Many JAR files are 'accidentally' multi-release; they use the feature to hide `module-info.class` from Java 8.
> 
> Instead of  performing one lookup for every version identified in the JAR, this PR narrows the version search down to only the number of versions found for the entry being looked up, which will most often be zero. This speeds up lookup for non-versioned entries, and provides a more targeted search for versioned entries.
> 
> An alternative approach could be to normalize the hash code to use the none-versioned name such that versioned and non-versioned names would be resolved in the same lookup. This was quickly abandoned since the code changes were intrusive and mixed too many JAR specific concerns into `ZipFile`.
> 
> Testing: The existing `JarFileGetEntry` benchmark is updated to optionally test a multi-release JAR file with one versioned entry for `module-info.class` plus two other versioned class files for two distinct versions. Performance results in [first comment](#issuecomment-2410901754).
> 
> Running `ZipFileOpen` on a multi-release JAR did not show a significat difference between this PR and mainline. 
> 
> The JAR and ZIP tests are run locally. GHA results green. The `noreg-perf` label is added in JBS.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1831:

> 1829:                 metaVersions = new HashMap<>();
> 1830:                 for (var entry : metaVersionsMap.entrySet()) {
> 1831:                     // Convert TreeSet<Integer> to int[] for performance

I think if you just require order upon final freezing, you can just use a HashSet or ArrayList, and perform the sorting and deduplication when you compile to an int array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1799921281

From naoto at openjdk.org  Mon Oct 14 18:51:10 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 14 Oct 2024 18:51:10 GMT
Subject: RFR: 8341445: DecimalFormatSymbols setters should throw NPE [v5]
In-Reply-To: <7Glw4lRt23rtDnZQtUyTUWudAcm5ahpreW2tf1fR-Zo=.d2df847a-d075-4b29-863e-84cfaf7e35a0@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
 <7Glw4lRt23rtDnZQtUyTUWudAcm5ahpreW2tf1fR-Zo=.d2df847a-d075-4b29-863e-84cfaf7e35a0@github.com>
Message-ID: <9ER0NnjmjNR1GMlIziO6wdNC2UGpIcv413rCjgWCYpg=.9bdbf691-2372-4f36-a7c7-748b046021e7@github.com>

On Sun, 13 Oct 2024 03:52:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols. As certain setters did not throw NPE, this allowed for NPE in the equality method. This PR now updates the setters to throw NPE.
>> 
>> In addition to the NPEs, there is also a behavioral change that `setInternationalCurrencySymbol` no longer sets currency to null if the `currencyCode` is invalid. Instead, it simply does not update `currency`. This must be done, because we do not want to allow nullable instance variables post `initalizeCurrency`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect further review

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21315#pullrequestreview-2367398290

From cay.horstmann at gmail.com  Mon Oct 14 19:27:03 2024
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Mon, 14 Oct 2024 21:27:03 +0200
Subject: Fw: New candidate JEP: 485: Stream Gatherers
Message-ID: <07710471-f249-48dc-bac8-40e00960febe@gmail.com>

Hi Viktor,

thanks for your clarifications.

I agree that from a performance point of view, there isn't all that much to be gained. I thought more about parallelizing distinctBy and windowSliding, Perhaps one can squeeze out a modest gain, but I am not excited by the potential.

AFAIK, the "greedy/short-circuiting" decision point doesn't have a major impact on performance either. Or am I wrong there?

In my mind, given that performance is not worth more than maybe a tweak, this amplifies my first issue with the surface API.

I started out thinking that almost nobody is going to write a gatherer, so why worry? But I found myself writing a couple in the last few days. And I wonder whether the current API is at "peak complexity".

If I use the factory methods, I have to make a choice between of/ofGreedy and ofSequential/of.

And if I don't use the factory methods, I have to mess with a marker interface or a method yielding a magic default.

Is there some virtuous collapse?

First off, I think factory methods should be the favored approach. And "of" should be the safe choice. That's why I would rename ofSequential into of, and introduce ofParallel for optimization. Like with of/ofGreedy.

I have seen some gatherer implementations that don't use the factory methods, even though they could have. Is this flexibility useful? The details are fussy, with the marker interface and the magic default combiner. That's where I thought the characteristics approach is a better API. It has precedence, and it is unfussy.

I realize it's not a big deal, and I was going to let it slide. Until I heard Brian's Devoxx talk where he mentioned "peak complexity", and I felt, that's, in a small way, what is present here.

Cheers,

Cay

--

(Moving this to core-libs-dev)

Cay,

Regarding 1, Characteristics was a part of the Gatherers-contract for a very long time, alas it didn't end up worth its cost. There's a longer discussion on the topic here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/118138.html (and I'm sure that there were more, but that's the one which comes to mind)

Regarding 2, I did have a prototype which had a Downstream in the Combiner, but created a new dimension of complexity which made it even harder for people to move from sequential to parallelizable. The door isn't closed on it, but I remain unconvinced it's worth the surface area for performance reasons.

As a bit of a side-note, it's worth knowing that in the reference stream implementation, it is not unusual that parallel-capable stages are executed as "islands" which means that short-circuiting signals cannot travel across those islands. Since parallel-capable Gatherers can be fused to execute in the same "island" if we get to a place where "all" intermediate operations are parallel-capable Gatherers, there'd be a single end-to-end "island" and hence the ability to propagate the short-circuiting would be preserved in all modes of execution. Also worth knowing that a `gather(?)` immediately followed by a `collect(?)` can also be fused to run together.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: jdk-dev <jdk-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
Sent: Friday, 4 October 2024 19:58
To: jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: Re: New candidate JEP: 485: Stream Gatherers

Hi, I have some belated questions about the design choices in this API that I could not find addressed in the JEP.

1. Why aren't characteristics used to express "greediness/short-circuiting" or "sequentialness/parallelizability"?

I understand that for the former I use ofGreedy/of, or implement Gatherers.Integrator.Greedy/Gatherers.Integrator. And for the latter, I use ofSequential/of, or, if I implement the Gatherer interface, have the combiner return defaultCombiner() or not.

But it seems a bit complex and less familiar than the characteristics mechanism that exists for spliterators, streams, and collectors.

The original design document (https://cr.openjdk.org/~vklang/Gatherers.html) used characteristics, so I wonder what motivated the change.

2. Why wasn't the combiner() designed to allow pushing of elements to the end of the first range's sink? Then distinctBy could be parallelized without buffering the elements. More generally, with some state fiddling one can then handle the elements around range splits.

As it is, I don't see how to parallelize such computations other than to buffer all elements.

I looked at the project at https://github.com/jhspetersson/packrat that implements a number of gatherers. Only one uses a combiner, to join buffers until their contents can be pushed in the finisher.

Cheers,

Cay
-- 

Cay S. Horstmann | https://horstmann.com


From eirbjo at openjdk.org  Mon Oct 14 19:30:21 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 14 Oct 2024 19:30:21 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
Message-ID: <y67oHoQy2QrjjMT6lZBAETAvvgD88dnpxP1nFGWIs_c=.45ee0379-b518-480a-b957-6d15300dd373@github.com>

On Sat, 12 Oct 2024 07:47:56 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'inc should be faster than add on most CPUs'

src/java.base/share/classes/java/io/Reader.java line 214:

> 212:                             cbuf[off + i] = cs.charAt(next + i);
> 213:                     }
> 214:                 }

Just a drive-by observation, not for this PR to handle:

If four out of five `CharSequence` implementations in the JDK include fast-path methods for copying char ranges into an output buffer, perhaps it is time to introduce `CharSequence::getChars` as a default method? 

That way, code like this wouldn't need to special-case for the known fast-paths, and external implementations could also join the party.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1799981701

From jlahoda at openjdk.org  Mon Oct 14 19:44:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 14 Oct 2024 19:44:15 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <Rd5Q3wc6sWFHwg1UH6WJjCjX2wDXhXxRFbKYJJ43ttk=.c160e1cf-0b9f-40bb-a922-756bcc1018ee@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
 <Rd5Q3wc6sWFHwg1UH6WJjCjX2wDXhXxRFbKYJJ43ttk=.c160e1cf-0b9f-40bb-a922-756bcc1018ee@github.com>
Message-ID: <6uy_EuWrx1eCnZ9s5Ots60R5SnAYR8Ux6FbyvF8ZoHA=.d093896d-fa7f-4ad3-ba45-a45fd5b45813@github.com>

On Mon, 14 Oct 2024 14:23:22 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 pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - Make very sure java.base is completed.
>>  - Keep jdk.internal.javac qualified export from java.base.
>>  - Adding forgotten change.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a
>
> src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 421:
> 
>> 419:                     && ((mods.contains(Requires.Modifier.TRANSITIVE) &&
>> 420:                          !previewClassfile &&
>> 421:                          !mn.startsWith("java."))
> 
> Just to double check, will be JLS update specify that it's only allow for java.* aggregator modules?

Only modules that participate in preview should be able to use `requires transitive java.base;` without having the preview flag set. And only modules in the JDK can participate in preview. I believe the JVMS will be updated to cover this.

We may want to restrict the condition here to only `java.se`, I am not sure. (Unless there are other modules that would use the directive, but I am not aware about any right now.)

Normally, the modules that "participate in preview" are those to which `java.base` exports the `jdk.internal.javac` package (and hence can use the `ParticipatesInPreview` annotation), but it didn't seem I can check the `java.base`'s exports at this place, so resorted to this hard-coded check. Hopefully, should only be temporary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1799993112

From eirbjo at openjdk.org  Mon Oct 14 19:50:45 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 14 Oct 2024 19:50:45 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
Message-ID: <ZZAq8q5mhcTAdSJhTreqT6hUfqyjmYxEP0TTvYbH7qk=.ce1ad101-8fd9-4ba9-836c-7afbac86caa0@github.com>

> Please review this PR which speeds up `JarFile::getEntry` lookup significantly for multi-release JAR files.
> 
> The changes in this PR are motivated by the following insights:
> 
> * `META-INF/versions/` is sparsely populated.
> * Most entries are not versioned
> * The number of unique versions for each versioned entry is small
> * Many JAR files are 'accidentally' multi-release; they use the feature to hide `module-info.class` from Java 8.
> 
> Instead of  performing one lookup for every version identified in the JAR, this PR narrows the version search down to only the number of versions found for the entry being looked up, which will most often be zero. This speeds up lookup for non-versioned entries, and provides a more targeted search for versioned entries.
> 
> An alternative approach could be to normalize the hash code to use the none-versioned name such that versioned and non-versioned names would be resolved in the same lookup. This was quickly abandoned since the code changes were intrusive and mixed too many JAR specific concerns into `ZipFile`.
> 
> Testing: The existing `JarFileGetEntry` benchmark is updated to optionally test a multi-release JAR file with one versioned entry for `module-info.class` plus two other versioned class files for two distinct versions. Performance results in [first comment](#issuecomment-2410901754).
> 
> Running `ZipFileOpen` on a multi-release JAR did not show a significat difference between this PR and mainline. 
> 
> The JAR and ZIP tests are run locally. GHA results green. The `noreg-perf` label is added in JBS.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Use Arrays.sort instead of TreeSet

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21489/files
  - new: https://git.openjdk.org/jdk/pull/21489/files/b2c900d4..826d78a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21489&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21489&range=00-01

  Stats: 22 lines in 1 file changed: 2 ins; 17 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21489/head:pull/21489

PR: https://git.openjdk.org/jdk/pull/21489

From kvn at openjdk.org  Mon Oct 14 19:51:15 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 14 Oct 2024 19:51:15 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <k6adkbs4u0vM0qV_wucCPj971XDScEfvRZbOIVCP4Gw=.aace15a9-9720-44c0-a295-61915f42cae4@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

C2 change (intrinsics code) is fine.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2367483219

From eirbjo at openjdk.org  Mon Oct 14 19:57:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 14 Oct 2024 19:57:13 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
Message-ID: <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>

On Mon, 14 Oct 2024 18:17:15 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:
>> 
>>   Use Arrays.sort instead of TreeSet
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1831:
> 
>> 1829:                 metaVersions = new HashMap<>();
>> 1830:                 for (var entry : metaVersionsMap.entrySet()) {
>> 1831:                     // Convert TreeSet<Integer> to int[] for performance
> 
> I think if you just require order upon final freezing, you can just use a HashSet or ArrayList, and perform the sorting and deduplication when you compile to an int array.

If we trust that versioned entries are rare, this should not matter much either way. But I pushed a commit which uses HashSet and Arrays::sort on freezing instead. WDYT?

Given that most versioned entries will only have a single version, we may save some memory and speed by special-casing for sets with one or two versions:


switch (metaVersionsMap.get(name)) {
    case null -> {
        // Special-case for set of size 1
        metaVersionsMap.put(name, Set.of(version));
    }
    case Set<Integer> versions when versions.size() == 1 -> {
        // Special-case for set of size 2
        metaVersionsMap.put(name, Set.of(version, versions.iterator().next()));
    }
    case Set<Integer> versions when versions.size() == 2 -> {
        // Now we convert to HashSet
        HashSet<Integer> set = new HashSet<>(versions);
        set.add(version);
        metaVersionsMap.put(name, set);
    }
    case HashSet<Integer> versions -> {
        // Just add
        versions.add(version);
    }
    default -> throw new AssertionError("Illegal state");
}



But again, versioned entries are rare, so perhaps better to keep it simple. Does @cl4es have thoughts about this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1800001845

From aturbanov at openjdk.org  Mon Oct 14 19:57:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 14 Oct 2024 19:57:23 GMT
Subject: RFR: 8342083: Make a few fields in FileSystemPreferences final
Message-ID: <nmDjJHEue_WGeD-ipZtWp3aUfmjNonrOo0cfyl3Am6Q=.17200a50-48cd-4528-95d5-2a66c7476d52@github.com>

8342083: Make a few fields in FileSystemPreferences final

-------------

Commit messages:
 - [PATCH] Make a few fields in FileSystemPreferences final

Changes: https://git.openjdk.org/jdk/pull/21131/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342083
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21131/head:pull/21131

PR: https://git.openjdk.org/jdk/pull/21131

From duke at openjdk.org  Mon Oct 14 20:04:14 2024
From: duke at openjdk.org (Rob Spoor)
Date: Mon, 14 Oct 2024 20:04:14 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <y67oHoQy2QrjjMT6lZBAETAvvgD88dnpxP1nFGWIs_c=.45ee0379-b518-480a-b957-6d15300dd373@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
 <y67oHoQy2QrjjMT6lZBAETAvvgD88dnpxP1nFGWIs_c=.45ee0379-b518-480a-b957-6d15300dd373@github.com>
Message-ID: <v26h3lXEUlXaTDPXu_4jKbRvIKbmNMXlNAbZOw4b0_Y=.8287ddf9-b79c-411e-af8e-1d7ce04e7ac2@github.com>

On Mon, 14 Oct 2024 19:27:00 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'inc should be faster than add on most CPUs'
>
> src/java.base/share/classes/java/io/Reader.java line 214:
> 
>> 212:                             cbuf[off + i] = cs.charAt(next + i);
>> 213:                     }
>> 214:                 }
> 
> Just a drive-by observation, not for this PR to handle:
> 
> If four out of five `CharSequence` implementations in the JDK include fast-path methods for copying char ranges into an output buffer, perhaps it is time to introduce `CharSequence::getChars` as a default method? 
> 
> That way, code like this wouldn't need to special-case for the known fast-paths, and external implementations could also join the party.

That had been discussed here: https://github.com/openjdk/jdk/pull/21371#pullrequestreview-2350588453

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1800009004

From mcimadamore at openjdk.org  Mon Oct 14 20:51:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 14 Oct 2024 20:51:15 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v8]
In-Reply-To: <0WeR12j3CDMiE5v6OT8XA0uiSok4bCtpN7NP26AQdc0=.15131fa1-930c-4c61-85d1-d9a999d4b64d@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <0WeR12j3CDMiE5v6OT8XA0uiSok4bCtpN7NP26AQdc0=.15131fa1-930c-4c61-85d1-d9a999d4b64d@github.com>
Message-ID: <_0r-cdNgMF7WLNU_XkfSRviUoDp_RHJiIk2YMyerWbg=.0085d5ea-b6a9-4072-990b-f246fd9e1b72@github.com>

On Wed, 9 Oct 2024 11:24:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore 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 'master' into restricted_better_javadoc
>  - Merge pull request #22 from hns/restricted_better_javadoc
>    
>    Only link restricted method doc-file if it is available
>  - Only link restricted method doc-file if it is available
>  - Fix paths to links
>  - Fix javadoc test failure
>  - Revert reference to caller stack
>  - Update src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Move restricted method page to `java.lang`
>    Update restricted method page
>  - Initial push

This needs a re-approval, due to the last round of javadoc changes. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2412307379

From redestad at openjdk.org  Mon Oct 14 21:00:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 14 Oct 2024 21:00:13 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
Message-ID: <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>

On Mon, 14 Oct 2024 19:52:50 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1831:
>> 
>>> 1829:                 metaVersions = new HashMap<>();
>>> 1830:                 for (var entry : metaVersionsMap.entrySet()) {
>>> 1831:                     // Convert TreeSet<Integer> to int[] for performance
>> 
>> I think if you just require order upon final freezing, you can just use a HashSet or ArrayList, and perform the sorting and deduplication when you compile to an int array.
>
> If we trust that versioned entries are rare, this should not matter much either way. But I pushed a commit which uses HashSet and Arrays::sort on freezing instead. WDYT?
> 
> Given that most versioned entries will only have a single version, we may save some memory and speed by special-casing for sets with one or two versions:
> 
> 
> switch (metaVersionsMap.get(name)) {
>     case null -> {
>         // Special-case for set of size 1
>         metaVersionsMap.put(name, Set.of(version));
>     }
>     case Set<Integer> versions when versions.size() == 1 -> {
>         // Special-case for set of size 2
>         metaVersionsMap.put(name, Set.of(version, versions.iterator().next()));
>     }
>     case Set<Integer> versions when versions.size() == 2 -> {
>         // Now we convert to HashSet
>         HashSet<Integer> set = new HashSet<>(versions);
>         set.add(version);
>         metaVersionsMap.put(name, set);
>     }
>     case HashSet<Integer> versions -> {
>         // Just add
>         versions.add(version);
>     }
>     default -> throw new AssertionError("Illegal state");
> }
> 
> 
> 
> But again, versioned entries are rare, so perhaps better to keep it simple. Does @cl4es have thoughts about this?

I like simple. 

Mixing Set.of and HashSet means a lot of semantic fu-fu (throwing/not throwing on nulls) and risks being suboptimal due making some call sites megamorphic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1800131485

From dl at openjdk.org  Mon Oct 14 21:07:54 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 14 Oct 2024 21:07:54 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
Message-ID: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@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),

-------------

Commit messages:
 - Consistent constructions; remove no-longer needed checks; update internal docs
 - Reconcile constuctions
 - Fencing
 - experiment
 - Merge branch 'openjdk:master' into JDK-8336707
 - Reactivation
 - Recheck
 - Uniform access expressions
 - Another diagnostic
 - More diagnostics
 - ... and 6 more: https://git.openjdk.org/jdk/compare/7312eea3...a1ad02fc

Changes: https://git.openjdk.org/jdk/pull/21507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336707
  Stats: 288 lines in 1 file changed: 42 ins; 95 del; 151 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  Mon Oct 14 21:09:52 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 14 Oct 2024 21:09:52 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v45]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <q8z7gm5KzGV4VOgycuCJC6ba8QfjFYYWi21YIM2e24E=.09e8da1b-a8fe-4d73-92f9-4dac30195843@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/29114ed3..1af73f00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=43-44

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From jkarthikeyan at openjdk.org  Mon Oct 14 21:53:15 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Mon, 14 Oct 2024 21:53:15 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
Message-ID: <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.a6df3ca8-6ddd-4c7e-a803-292a5695f1e4@github.com>

On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

> 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.

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 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 erikj at openjdk.org  Mon Oct 14 23:06:09 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Oct 2024 23:06:09 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
Message-ID: <vJK4YjVEux-8jGSawkp70qZcJ61r_17mQinikCeGLMY=.1b203fba-9c87-4eda-81cc-a970b7c1e745@github.com>

On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341997: Replace test.dir property with CWD

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21503#pullrequestreview-2367784645

From erikj at openjdk.org  Mon Oct 14 23:06:10 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Oct 2024 23:06:10 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir
In-Reply-To: <zgysPI8B4ekLWw88LzJcTPDRLYxfH5OUrqO36olZDio=.f8eecf56-2cb5-46f3-81dc-7f2245432338@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <zgysPI8B4ekLWw88LzJcTPDRLYxfH5OUrqO36olZDio=.f8eecf56-2cb5-46f3-81dc-7f2245432338@github.com>
Message-ID: <Wo0A9eGSZZgQXe_JoLpOyIPNHYN5D6c1AkCXDlzdqJY=.7dde1e68-2ce0-4aaa-8ea6-084d5d85bee8@github.com>

On Mon, 14 Oct 2024 17:55:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The property `test.dir` has been used as a convention but I've no problem with changing it to the CWD.

I wasn't aware, but if it's convention, I'm ok with it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2412484744

From erikj at openjdk.org  Mon Oct 14 23:10:10 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 14 Oct 2024 23:10:10 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
Message-ID: <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>

On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341997: Replace test.dir property with CWD

I'm taking this fix for a spin over night in the environment where I noticed the problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2412488255

From bpb at openjdk.org  Mon Oct 14 23:29:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 23:29:09 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
 <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>
Message-ID: <btMPe3zI6BNHXOgftx7p6SfrSmaQ4FzHHk67OZhSZog=.7d072c29-5d9f-4859-9f9f-f53e018e2d74@github.com>

On Mon, 14 Oct 2024 23:07:28 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I'm taking this fix for a spin over night in the environment where I noticed the problem.

I'll hold off integrating until that is over.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2412512411

From bpb at openjdk.org  Mon Oct 14 23:34:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 14 Oct 2024 23:34:22 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
Message-ID: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>

Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

-------------

Commit messages:
 - 8233451: (fs) Files.newInputStream() cannot be used with character special files

Changes: https://git.openjdk.org/jdk/pull/21508/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8233451
  Stats: 204 lines in 11 files changed: 188 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

PR: https://git.openjdk.org/jdk/pull/21508

From vlivanov at openjdk.org  Tue Oct 15 00:31:12 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 15 Oct 2024 00:31:12 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
Message-ID: <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.7580c0c3-0bdb-44c5-afd2-2a4226ff7274@github.com>

On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2412582542

From serb at openjdk.org  Tue Oct 15 00:32:14 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Oct 2024 00:32:14 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
Message-ID: <cJS-KS6m52_Nz2I91qLEq7DebAPhX6gwmiH2Ap3T9Kk=.31079cc6-261c-4390-9d8e-0ac4ed26c460@github.com>

On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8340801
>  - move ub.h to a better location
>  - remove ubsan changes from jni_md.h
>  - JDK-8340801

Can you please add a comment to the jbs - what warning is actually fixed by this change, and how to reproduce that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2412583603

From syan at openjdk.org  Tue Oct 15 01:13:19 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 15 Oct 2024 01:13:19 GMT
Subject: RFR: 8341593: Problemlist java/foreign/TestUpcallStress.java in
 Xcomp mode
In-Reply-To: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
References: <0dWMSQee71K4tIBHtxRPyhQ9NfEw9bQqWA2dgUc923Q=.14e7c257-e093-4c7c-9b2c-da812fe5bd4c@github.com>
Message-ID: <UlbbcloixcA4f7-y1HkgsHQX1k6n80gzz6DWfSg_kkY=.643ea4c5-d4d8-4d92-b279-402a10a73675@github.com>

On Sun, 6 Oct 2024 09:15:58 GMT, SendaoYan <syan at openjdk.org> wrote:

> A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp mode.

Okey, I will create a new PR to the test from the problem list and use `@requires` instead. Thanks for the correction.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21375#issuecomment-2412619173

From syan at openjdk.org  Tue Oct 15 01:30:25 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 15 Oct 2024 01:30:25 GMT
Subject: RFR: 8341584: Test java/foreign/TestUpcallStress.java intermittent
 timeout with -Xcomp
Message-ID: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>

Hi all,
Test `java/foreign/TestUpcallStress.java` intermittent timeout with -Xcomp, and this test use a very precise race, thus `-Xcomp` probably will never trigger the problematic use-case. So this test not suitable for -Xcomp mode.I add `@requires vm.compMode != "Xcomp"` to exclude from Xcomp testing and remove this test from `ProblemList-Xcomp.txt`.
Trivial fix, test-fix only, no risk.

-------------

Commit messages:
 - 8341584: Test java/foreign/TestUpcallStress.java intermittent timeout with -Xcomp

Changes: https://git.openjdk.org/jdk/pull/21512/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21512&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341584
  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21512.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21512/head:pull/21512

PR: https://git.openjdk.org/jdk/pull/21512

From amitkumar at openjdk.org  Tue Oct 15 04:49:16 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 15 Oct 2024 04:49:16 GMT
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
Message-ID: <FfFlOF7vobdiihfmnwjivV1lYCOjkqwVVMDVj-yun_M=.09a60dd0-08d9-4e77-ad76-50d996454d01@github.com>

On Mon, 30 Sep 2024 09:19:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests fixing a problem on big-endian platforms.

Ran tier1 and got no regression for s390x. LGTM

-------------

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21258#pullrequestreview-2368158515

From liach at openjdk.org  Tue Oct 15 05:16:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 05:16:17 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
Message-ID: <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>

On Mon, 14 Oct 2024 20:57:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> If we trust that versioned entries are rare, this should not matter much either way. But I pushed a commit which uses HashSet and Arrays::sort on freezing instead. WDYT?
>> 
>> Given that most versioned entries will only have a single version, we may save some memory and speed by special-casing for sets with one or two versions:
>> 
>> 
>> switch (metaVersionsMap.get(name)) {
>>     case null -> {
>>         // Special-case for set of size 1
>>         metaVersionsMap.put(name, Set.of(version));
>>     }
>>     case Set<Integer> versions when versions.size() == 1 -> {
>>         // Special-case for set of size 2
>>         metaVersionsMap.put(name, Set.of(version, versions.iterator().next()));
>>     }
>>     case Set<Integer> versions when versions.size() == 2 -> {
>>         // Now we convert to HashSet
>>         HashSet<Integer> set = new HashSet<>(versions);
>>         set.add(version);
>>         metaVersionsMap.put(name, set);
>>     }
>>     case HashSet<Integer> versions -> {
>>         // Just add
>>         versions.add(version);
>>     }
>>     default -> throw new AssertionError("Illegal state");
>> }
>> 
>> 
>> 
>> But again, versioned entries are rare, so perhaps better to keep it simple. Does @cl4es have thoughts about this?
>
> I like simple. 
> 
> Mixing Set.of and HashSet means a lot of semantic fu-fu (throwing/not throwing on nulls) and risks being suboptimal due making some call sites megamorphic.

Yep, looks good. And I agree with Claes' evaluation that we should not complicate this construction further, especially that the result is quickly garbage collected when we compile into the string to int array map.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1800467908

From iklam at openjdk.org  Tue Oct 15 05:16:58 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 05:16:58 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v8]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <ew24DuvX35iwH5D8e9NkB8EHjP9X6syl7sIci23CW6g=.26a35da7-3476-4167-82c5-8446229aa757@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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:

 - reviews from @iwanowww and @rose00 -- move USE_SOFT_CACHE to MethodHandleNatives as a @Stable field; use system prop for init
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @liach and @cl4es comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @dholmes-ora review comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - ... and 5 more: https://git.openjdk.org/jdk/compare/6fd4c342...e46b910a

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/1b067b7b..e46b910a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=06-07

  Stats: 57637 lines in 929 files changed: 46880 ins; 5833 del; 4924 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From alanb at openjdk.org  Tue Oct 15 05:18:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 05:18:14 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <ZZzZB-lArNX3FJ83V0nCkgOBCVBYdNp6Y_eY37UFR88=.37cdcb77-b3dc-4657-88c2-0b2ea427f78a@github.com>

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

src/java.base/windows/native/libjava/io_util_md.h line 44:

> 42: WCHAR* currentDir(int di);
> 43: int currentDirLength(const WCHAR* path, int pathlen);
> 44: JNIEXPORT int handleAvailable(FD fd, jlong *pbytes);

This should not be exported.

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 402:

> 400:     HANDLE handle = (HANDLE)(handleval(env, fdo));
> 401:     jlong available;
> 402:     if (handleAvailable((jlong)handle, &available)) {

Ugh, we shouldn't be using handleAvailable here. This native method needs to stand on its own.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1800469509
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1800469147

From iklam at openjdk.org  Tue Oct 15 05:20:13 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 05:20:13 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v8]
In-Reply-To: <ew24DuvX35iwH5D8e9NkB8EHjP9X6syl7sIci23CW6g=.26a35da7-3476-4167-82c5-8446229aa757@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <ew24DuvX35iwH5D8e9NkB8EHjP9X6syl7sIci23CW6g=.26a35da7-3476-4167-82c5-8446229aa757@github.com>
Message-ID: <PRkGVZWm_MyUSvhueU62Jbqhia3cn1L0bDqlgZ_JmYQ=.6e9c0174-d472-48f9-9fd6-a2dcf845faef@github.com>

On Tue, 15 Oct 2024 05:16:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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:
> 
>  - reviews from @iwanowww and @rose00 -- move USE_SOFT_CACHE to MethodHandleNatives as a @Stable field; use system prop for init
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/144bcc30...e46b910a

> This is good although hacky, due to incomplete "build out" of Leyden-related functionality. For a first JEP it is fine. But it leaves some debt to pay off later.
> 
> Later, we need to decide how to more fully embrace SoftReference. There is nothing inherently wrong with mixing SR's and AOT, even if they interfere somewhat. I think the right answer might be forcing them to get along better. We need to get their queueing status into a quiet state order to push them into the AOT cache (and then pull them out as the production run states). It seems to me we should (first) try pruning away most of the queueing infrastructure during the assembly phase, and patching it up in the production run (at some appropriate `VM::initState` level), so that the SRs "go live" at a controlled point during boot-up.
> 
> Or, we could do a Three Table (or Two Table) solution. This PR is an example of a Two Table solution. (One could say the handoff from AOT table to runtime table is overly subtle but it works, and maybe that subtlety just comes with the territory.) The various cache variables (`Transform.cache` and `MTF.LFs/MHs`) right now are polymorphically SRs or hard references. The variable `MethodHandleStatics.NO_SOFT_CACHE` controls which "table" is active. (This is a sort of "sharded" table, not a centralized table object.) Cached values are inserted into the table using soft or hard refs, depending on NO_SOFT_CACHE. They are extracted in a robust way, using instanceof, which is good. There is no plan for converting hard to soft refs, which is probably OK; we can fix this later if we need to.
> 
> If we have a sudden flash of insight how to support AOT of soft references (SRs), then this PR goes away. Otherwise, I have one request, related to MethodHandleStatics. I think we should be moving towards respecting the finals of that class, like any other class, as AOT-able values. Using just one static as a secret channel for AOT logic is too edgy for my taste.
> 
> First, `NO_SOFT_CACHE should probably be a @Stable variable, not a final, so it can be patched. And it should be inverted: `@stable boolean USE_SOFT_CACHES`. When the VM goes to the right init-phase (but never during assembly phase), that boolean should be set true, and it will act like a constant true boolean forever after.
> 
> Also, consider moving it (as a stable non-final) to `MethodHandleNatives`, since its state depends on stuff below the level of Java proper. I think `MethodHandleStatics` stuff has a different area of responsibility than `USE_SOFT_CACHES`.

Hi John, I've moved the variable  to `MethodHandleNatives` as `static @Stable boolean USE_SOFT_CACHE`. Please let me know if it looks good to you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21049#issuecomment-2412919559

From iklam at openjdk.org  Tue Oct 15 05:21:53 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 05:21:53 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
 - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
 - @adinn comments
 - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
 - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
 - Limit the use of AOTHolder
 - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

-------------

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=04
  Stats: 2172 lines in 64 files changed: 1928 ins; 103 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From henryjen at openjdk.org  Tue Oct 15 05:22:05 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 15 Oct 2024 05:22:05 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v5]
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: <LDfj6rSOnjY24swwbw68lAroC4rUVjD7opitFGNarU0=.6dd785b3-7391-4901-b821-4bc80a65062a@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:

  Add more comments, move snippet generation code into standalone class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21022/files
  - new: https://git.openjdk.org/jdk/pull/21022/files/b2794018..ab6459d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=03-04

  Stats: 343 lines in 2 files changed: 182 ins; 109 del; 52 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  Tue Oct 15 05:42:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 05:42:09 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <sgK6A1OW4YhCFAYE-gGeASpWuwFVgRPIK0yHV4ofs4Q=.19bdb957-d434-4d58-b31d-e519ee3ed07e@github.com>

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Overall the approach is good, except for the Windows implementation of "available" that will need re-work. For ChannelInputStream.isOther then it's effective a stable field, we can do some improvements there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2412941018

From alanb at openjdk.org  Tue Oct 15 06:07:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 06:07:14 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v8]
In-Reply-To: <0WeR12j3CDMiE5v6OT8XA0uiSok4bCtpN7NP26AQdc0=.15131fa1-930c-4c61-85d1-d9a999d4b64d@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <0WeR12j3CDMiE5v6OT8XA0uiSok4bCtpN7NP26AQdc0=.15131fa1-930c-4c61-85d1-d9a999d4b64d@github.com>
Message-ID: <RZ6EmqP7cJ45ZbAXZ2tCJBuPXQl0TVrx0vQXgOhWhno=.8e1afca9-a0bd-4518-a413-a1eb7cc86fa9@github.com>

On Wed, 9 Oct 2024 11:24:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore 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 'master' into restricted_better_javadoc
>  - Merge pull request #22 from hns/restricted_better_javadoc
>    
>    Only link restricted method doc-file if it is available
>  - Only link restricted method doc-file if it is available
>  - Fix paths to links
>  - Fix javadoc test failure
>  - Revert reference to caller stack
>  - Update src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Move restricted method page to `java.lang`
>    Update restricted method page
>  - Initial push

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21067#pullrequestreview-2368250090

From jpai at openjdk.org  Tue Oct 15 06:39:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Oct 2024 06:39:08 GMT
Subject: RFR: 8341584: Test java/foreign/TestUpcallStress.java intermittent
 timeout with -Xcomp
In-Reply-To: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
References: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
Message-ID: <iKveUlMpkHC4DKVKAL94TEzAZV-6QMtGRW4CphyGNXU=.e01929ba-2e46-4151-8f97-90b373c9f766@github.com>

On Tue, 15 Oct 2024 01:25:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `java/foreign/TestUpcallStress.java` intermittent timeout with -Xcomp, and this test use a very precise race, thus `-Xcomp` probably will never trigger the problematic use-case. So this test not suitable for -Xcomp mode.I add `@requires vm.compMode != "Xcomp"` to exclude from Xcomp testing and remove this test from `ProblemList-Xcomp.txt`.
> Trivial fix, test-fix only, no risk.

The change looks OK to me. Please wait for Jorn @JornVernee to take a look, before integrating.

@sendaoYan  I forgot to ask, were you able to verify that this change continues to prevent the failures that were noticed previously?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21512#pullrequestreview-2368296431
PR Comment: https://git.openjdk.org/jdk/pull/21512#issuecomment-2413014555

From syan at openjdk.org  Tue Oct 15 06:48:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 15 Oct 2024 06:48:09 GMT
Subject: RFR: 8341584: Test java/foreign/TestUpcallStress.java intermittent
 timeout with -Xcomp
In-Reply-To: <iKveUlMpkHC4DKVKAL94TEzAZV-6QMtGRW4CphyGNXU=.e01929ba-2e46-4151-8f97-90b373c9f766@github.com>
References: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
 <iKveUlMpkHC4DKVKAL94TEzAZV-6QMtGRW4CphyGNXU=.e01929ba-2e46-4151-8f97-90b373c9f766@github.com>
Message-ID: <w01WJkORol3A1LBFA6ybvZrJLkXkwnF3hD8bK7N7eZ8=.4a3ed78d-e408-4922-8463-cb5ac5fb709c@github.com>

On Tue, 15 Oct 2024 06:34:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The change looks OK to me. Please wait for Jorn @JornVernee to take a look, before integrating.

Okey.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21512#issuecomment-2413025856

From syan at openjdk.org  Tue Oct 15 06:48:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 15 Oct 2024 06:48:09 GMT
Subject: RFR: 8341584: Test java/foreign/TestUpcallStress.java intermittent
 timeout with -Xcomp
In-Reply-To: <w01WJkORol3A1LBFA6ybvZrJLkXkwnF3hD8bK7N7eZ8=.4a3ed78d-e408-4922-8463-cb5ac5fb709c@github.com>
References: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
 <iKveUlMpkHC4DKVKAL94TEzAZV-6QMtGRW4CphyGNXU=.e01929ba-2e46-4151-8f97-90b373c9f766@github.com>
 <w01WJkORol3A1LBFA6ybvZrJLkXkwnF3hD8bK7N7eZ8=.4a3ed78d-e408-4922-8463-cb5ac5fb709c@github.com>
Message-ID: <kqc8STCjuGYTEYiq2Ek2PCn6Xl0ZbjoAg0FmDayGJB8=.ef79fdb3-f3a3-43cb-b0f9-9263b0337b37@github.com>

On Tue, 15 Oct 2024 06:43:47 GMT, SendaoYan <syan at openjdk.org> wrote:

>> The change looks OK to me. Please wait for Jorn @JornVernee to take a look, before integrating.
>
>> The change looks OK to me. Please wait for Jorn @JornVernee to take a look, before integrating.
> 
> Okey.

> @sendaoYan I forgot to ask, were you able to verify that this change continues to prevent the failures that were noticed previously?

Yes, I have verify that locally. After the `@requires` flags has been added, jtreg will not select this test in Xcomp test mode.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21512#issuecomment-2413029165

From jpai at openjdk.org  Tue Oct 15 07:14:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 15 Oct 2024 07:14:10 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
Message-ID: <toz-ptgJs8JkEeTm7MGh5o_Zw4GozAg9_mHwGQdjjNE=.386941b9-894d-4179-be5a-3be4acdaf69d@github.com>

On Mon, 14 Oct 2024 18:02:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change property `test.src` to `test.dir`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341997: Replace test.dir property with CWD

This test-only change looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21503#pullrequestreview-2368367164

From mbaesken at openjdk.org  Tue Oct 15 07:42:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 15 Oct 2024 07:42:12 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]
In-Reply-To: <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
 <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>
Message-ID: <QaftUrPcphsru27INtBdAFqQlRY1vF-cVYftlZGHOv0=.ab482032-14dc-40ac-8501-7210ab1808c0@github.com>

On Wed, 2 Oct 2024 20:29:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove ubsan changes from jni_md.h
>
> jni_util.h is used across all modules but it is located in `java.base/share/native/libjava` not `java.base/unix/native/libjava`. 
> 
> I think you could probably place ub.h along-side jni_util.h in that directory.

@dholmes-ora  are you fine with the latest version ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2413125667

From pminborg at openjdk.org  Tue Oct 15 08:02:16 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Oct 2024 08:02:16 GMT
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <LFNK4V03VSlMWMQteoDySahr8dbMHWJp3mHlS3mSU_E=.94af9f64-6a1c-47a7-bbaf-a38df13bf2d6@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
 <LFNK4V03VSlMWMQteoDySahr8dbMHWJp3mHlS3mSU_E=.94af9f64-6a1c-47a7-bbaf-a38df13bf2d6@github.com>
Message-ID: <tbcIBJ-GWYdoj0_r3lYliMRkqZUAQnq5gMKNJCQoMFs=.29677ff6-e6de-4a5b-9f2e-5a7926bfc06b@github.com>

On Mon, 14 Oct 2024 18:17:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This version uses little endian accesses on big endian machines. This may defeat the purpose of [JDK-8339531](https://bugs.openjdk.org/browse/JDK-8339531) for those platforms. Accesses are typically slower when using them with endianness mismatch. But it looks at least correct. Thanks for providing a fix.

Are you able to run the `SegmentBulkMismatch` benchmark on the various BE platforms? This will provide us with clear figures if there is an improvement or not.  (The benchmark runs both the old and new code path)

When we have the figures, we could (if necessary) open up a new issue targeting improved performance for BE platforms. I could help in such an effort but I can't drive it because I don't have access to a BE platform.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21258#issuecomment-2413160489

From pminborg at openjdk.org  Tue Oct 15 08:02:16 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Oct 2024 08:02:16 GMT
Subject: Integrated: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
Message-ID: <LMxXAm7sYOTa62QvgrdUSaL2bsSy2V-SDIznZa2bHXk=.199fd82e-195e-48e3-bbb2-eb3bef94431d@github.com>

On Mon, 30 Sep 2024 09:19:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests fixing a problem on big-endian platforms.

This pull request has now been integrated.

Changeset: 521effe0
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/521effe017b9b6322036f1851220056a637d6b1c
Stats:     17 lines in 1 file changed: 0 ins; 8 del; 9 mod

8340189: 8339531 incorrect for Big Endian platforms

Reviewed-by: mdoerr, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/21258

From eirbjo at openjdk.org  Tue Oct 15 08:08:11 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 15 Oct 2024 08:08:11 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
Message-ID: <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>

On Tue, 15 Oct 2024 05:13:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I like simple. 
>> 
>> Mixing Set.of and HashSet means a lot of semantic fu-fu (throwing/not throwing on nulls) and risks being suboptimal due making some call sites megamorphic.
>
> Yep, looks good. And I agree with Claes' evaluation that we should not complicate this construction further, especially that the result is quickly garbage collected when we compile into the string to int array map.

We could also just use `Map<String, int[]>`. This would allow us to skip the whole `Set<Integer>` to `int[]`  transition step, and the temporary `HashMap` is no longer needed.

Deduplication could occur during registration:


metaVersions.merge(name, new int[] {version}, (current, val) -> {
    // Check duplicates
    for (int v : current) {
        if (v == version) {
            return current;
        }
    }
    // Add version
    int[] merged = Arrays.copyOf(current, current.length + 1);
    merged[merged.length - 1] = version;
    return merged;
});


while the postprocessing step would simply sort each array:


for (int[] versions : metaVersions.values()) {
    // JarFile::getVersionedEntry expects sorted versions
    Arrays.sort(versions);
}


This performs ~10% better on a version-heavy `ZipFileOpen`, and I think the code is reasonably simple compared to the current state of the PR. Thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1800657937

From rgiulietti at openjdk.org  Tue Oct 15 08:26:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 15 Oct 2024 08:26:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
Message-ID: <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>

On Mon, 14 Oct 2024 15:44:20 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> OK, let me give it a try, maybe tomorrow.
>
> @rgiulietti Or maybe "i.e., 5^(2^i) is larger than the largest power of five that is still removable from intVal", could it be ok?

While I intuitively understand, and I'm convinced of the clever algorithm, I'm struggling to find a proof, in particular to formulate a useful invariant for the first loop which seamlessly would bind with the second loop and its invariant.
I need to find more time for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1800684712

From duke at openjdk.org  Tue Oct 15 09:07:14 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 15 Oct 2024 09:07:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
Message-ID: <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>

On Tue, 15 Oct 2024 08:23:23 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti Or maybe "i.e., 5^(2^i) is larger than the largest power of five that is still removable from intVal", could it be ok?
>
> While I intuitively understand, and I'm convinced of the clever algorithm, I'm struggling to find a proof, in particular to formulate a useful invariant for the first loop which seamlessly would bind with the second loop and its invariant.
> I need to find more time for this.

@rgiulietti Actually, an useful invariant for `remainingZeros` follows directly from its definition: letting `z = max{n : ((intVal * 2^powsOf2) % 10^n) == 0 && n <= scale - preferredScale}`, at the first iteration, it is true that `remainingZeros >= z`, and the loop condition is `remainingZeros >= 2^i`. So, if `z < 2^i`, then `intVal % 5^(2^i) != 0` and the "then" branch of the "if" is executed, otherwise `z >= 2^i` and the "else" branch is executed. In both branchs, the invariant `remainingZeros >= z` is preserved by the instructions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1800746960

From mcimadamore at openjdk.org  Tue Oct 15 09:13:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 15 Oct 2024 09:13:18 GMT
Subject: Integrated: 8338596: Clarify handling of restricted and
 caller-sensitive methods
In-Reply-To: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
Message-ID: <p-NKEhKCUvfpbGButYI_oc-9Z5PEYmSkeTzrifzCm-c=.c2978a45-33d2-48e1-a6cf-cf1bc9e05b08@github.com>

On Wed, 18 Sep 2024 15:47:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
> 
> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
> 
> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
> 
> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).

This pull request has now been integrated.

Changeset: f4dccfd4
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4dccfd4cf354f360b823c8cce15bb54ef90e9ca
Stats:     119 lines in 5 files changed: 70 ins; 41 del; 8 mod

8338596: Clarify handling of restricted and caller-sensitive methods

Co-authored-by: Hannes Walln?fer <hannesw at openjdk.org>
Reviewed-by: alanb, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/21067

From rgiulietti at openjdk.org  Tue Oct 15 09:16:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 15 Oct 2024 09:16:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
Message-ID: <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>

On Tue, 15 Oct 2024 09:02:58 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> While I intuitively understand, and I'm convinced of the clever algorithm, I'm struggling to find a proof, in particular to formulate a useful invariant for the first loop which seamlessly would bind with the second loop and its invariant.
>> I need to find more time for this.
>
> @rgiulietti Actually, an useful invariant for `remainingZeros` follows directly from its definition: letting `z = max{n : ((intVal * 2^powsOf2) % 10^n) == 0 && n <= scale - preferredScale}`, at the first iteration, it is true that `remainingZeros >= z`, and the loop condition is `remainingZeros >= 2^i`. So, if `z < 2^i`, then `intVal % 5^(2^i) != 0` and the "then" branch of the "if" is executed, otherwise `z >= 2^i` and the "else" branch is executed. In both branches, the invariant `remainingZeros >= z` is preserved by the instructions.

Yes, I considered that as well.
Not sure, however, if this is sufficient to prove that intVal has been indeed divided by 5^z after the 2nd loop is terminated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1800761892

From rgiulietti at openjdk.org  Tue Oct 15 09:16:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 15 Oct 2024 09:16:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
Message-ID: <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>

On Tue, 15 Oct 2024 09:11:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti Actually, an useful invariant for `remainingZeros` follows directly from its definition: letting `z = max{n : ((intVal * 2^powsOf2) % 10^n) == 0 && n <= scale - preferredScale}`, at the first iteration, it is true that `remainingZeros >= z`, and the loop condition is `remainingZeros >= 2^i`. So, if `z < 2^i`, then `intVal % 5^(2^i) != 0` and the "then" branch of the "if" is executed, otherwise `z >= 2^i` and the "else" branch is executed. In both branches, the invariant `remainingZeros >= z` is preserved by the instructions.
>
> Yes, I considered that as well.
> Not sure, however, if this is sufficient to prove that intVal has been indeed divided by 5^z after the 2nd loop is terminated.

Anyway, if you find a nice proof please add it to the comments. The algorithm is quite sophisticated, so it needs one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1800765293

From shade at openjdk.org  Tue Oct 15 09:21:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 09:21:18 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <3YCl5AAk6GEqSTEHET6IloTiEkiGPUjvJnHA--F8ctU=.bfdb7898-7ece-41dc-9c04-971234a74d0f@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

Thanks for review, folks. I am re-running testing locally here. Would appreciate if you can give this patch a spin through your CIs as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2413348085

From duke at openjdk.org  Tue Oct 15 09:22:16 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 15 Oct 2024 09:22:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
Message-ID: <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>

On Tue, 15 Oct 2024 09:13:48 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Yes, I considered that as well.
>> Not sure, however, if this is sufficient to prove that intVal has been indeed divided by 5^z after the 2nd loop is terminated.
>
> Anyway, if you find a nice proof please add it to the comments. The algorithm is quite sophisticated, so it needs one.

I would say yes... The invariant `i == max{n : 5^(2^n) <= 5^remainingZeros}` should be a sufficient condition to affirm it, indeed the 2nd loop ends when `remainingZeros == 0`, so `remainingZeros >= z` implies `z == 0`...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1800778340

From rcastanedalo at openjdk.org  Tue Oct 15 09:27:12 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 15 Oct 2024 09:27:12 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <3YCl5AAk6GEqSTEHET6IloTiEkiGPUjvJnHA--F8ctU=.bfdb7898-7ece-41dc-9c04-971234a74d0f@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
 <3YCl5AAk6GEqSTEHET6IloTiEkiGPUjvJnHA--F8ctU=.bfdb7898-7ece-41dc-9c04-971234a74d0f@github.com>
Message-ID: <MX2iRPfi5jOwWg7t9Nrg204dQ3QBVGgIXjJ_bYhm9Zk=.ef3f8b90-1717-4f00-8128-b12567b5df4d@github.com>

On Tue, 15 Oct 2024 09:18:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Thanks for review, folks. I am re-running testing locally here. Would appreciate if you can give this patch a spin through your CIs as well.

I will run some internal CI testing and report back in one or two days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2413362811

From sgehwolf at openjdk.org  Tue Oct 15 09:29:48 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 09:29:48 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v38]
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: <mjmqM8K8zpix5cV27K6MwmxGTQskHBqH15mpSXOweAo=.dd4384bf-b3d5-4a5f-8598-557ff8b5bdc1@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 145 commits:

 - Only show info message about runtime link when verbose
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Update error message when linking jdk.jlink
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - JLinkDedupTestBatchSizeOne.java test fix
   
   Run only the packaged modules version if we have a linkable JDK runtime
   with packaged modules available as well in the JDK install.
 - Enable IncludeLocalesPluginTest
 - ... and 135 more: https://git.openjdk.org/jdk/compare/521effe0...6859a3be

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=37
  Stats: 3960 lines in 42 files changed: 3763 ins; 117 del; 80 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 epeter at openjdk.org  Tue Oct 15 09:38:22 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 15 Oct 2024 09:38:22 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
Message-ID: <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>

On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating tests to use floorMod

I gave it a quick scan, and I have no further comments. LGTM.

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2368730929

From sgehwolf at openjdk.org  Tue Oct 15 09:43:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 09:43:02 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v10]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <_wzqCdQ-RVPJsfS1tjWnorQJpINjfP3RA4O14xNMGdU=.4a9b6e43-d199-4dcf-851e-9c297b58e647@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 35 commits:

 - 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
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - ... and 25 more: https://git.openjdk.org/jdk/compare/521effe0...03699b08

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=09
  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 duke at openjdk.org  Tue Oct 15 09:55:30 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 15 Oct 2024 09:55:30 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v46]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <6QJifFJcDBsSKhMBtozk3F-1tj-kNiAyqH1cI_Z03E4=.66faa034-1af9-4b1c-b2f0-e906220e6dc1@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  More comments for correctness proof

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/1af73f00..e91ebe83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=44-45

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From duke at openjdk.org  Tue Oct 15 09:59:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 15 Oct 2024 09:59:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
Message-ID: <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>

On Tue, 15 Oct 2024 09:18:59 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Anyway, if you find a nice proof please add it to the comments. The algorithm is quite sophisticated, so it needs one.
>
> I would say yes... The invariant `i == max{n : 5^(2^n) <= 5^remainingZeros}` should be a sufficient condition to affirm it, indeed the 2nd loop ends when `remainingZeros == 0`, so `remainingZeros >= z` implies `z == 0`...

> Yes, I considered that as well. Not sure, however, if this is sufficient to prove that intVal has been indeed divided by 5^z after the 2nd loop is terminated.

New comments just added should be sufficient to prove it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1800837070

From yzheng at openjdk.org  Tue Oct 15 10:05:16 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 15 Oct 2024 10:05:16 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
Message-ID: <_jxZbWC74sQnUsT7Pher9IhyI2zWos38DYNsnB6azSo=.e90cf5e6-d008-4022-a752-61c26505b560@github.com>

On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Simplify: just do keep alive checks
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - More precise bit-unmasks
>  - Reconcile with late barrier expansion in G1
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Review comments
>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>  - Also dispatch to slow-path on other arches
>  - Fix other arches
>  - Tighten up comments in Reference javadoc
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab

src/hotspot/share/gc/z/zBarrierSetRuntime.hpp line 43:

> 41:   static void store_barrier_on_oop_field_with_healing(oop* p);
> 42:   static void store_barrier_on_oop_field_without_healing(oop* p);
> 43:   static void no_keepalive_store_barrier_on_oop_field_without_healing(oop* p);

Could you please export this to JVMCI? I.e.,

diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 5452cca96b8..46aeb996c56 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -847,6 +847,7 @@
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::load_barrier_on_oop_field_preloaded_store_good))           \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_load_barrier_on_weak_oop_field_preloaded))    \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_load_barrier_on_phantom_oop_field_preloaded)) \
+  ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing)   \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_native_oop_field_without_healing))        \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_oop_field_with_healing))                  \
   ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_oop_field_without_healing))               \

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1800848130

From epeter at openjdk.org  Tue Oct 15 10:22:21 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 15 Oct 2024 10:22:21 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
Message-ID: <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>

On Sun, 13 Oct 2024 09:57:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update adlc changes.

Are there any IR rules that verify that the correct C2 nodes are used? Is that a thing you generally do with the VectorAPI, just to make sure things get correctly intrinsified?

src/hotspot/share/opto/vectornode.hpp line 161:

> 159:   // Needed for proper cloning.
> 160:   virtual uint size_of() const { return sizeof(*this); }
> 161:   bool is_unsigned() { return _is_unsigned; }

Can you put this in the `print_spec`, so the IR dump shows if it is unsigned?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2368845862
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1800870852

From duke at openjdk.org  Tue Oct 15 10:46:17 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 15 Oct 2024 10:46:17 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <v26h3lXEUlXaTDPXu_4jKbRvIKbmNMXlNAbZOw4b0_Y=.8287ddf9-b79c-411e-af8e-1d7ce04e7ac2@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
 <y67oHoQy2QrjjMT6lZBAETAvvgD88dnpxP1nFGWIs_c=.45ee0379-b518-480a-b957-6d15300dd373@github.com>
 <v26h3lXEUlXaTDPXu_4jKbRvIKbmNMXlNAbZOw4b0_Y=.8287ddf9-b79c-411e-af8e-1d7ce04e7ac2@github.com>
Message-ID: <Gb0zpIPaov-9DEr21KXyqiWjfTKnzw0KYN83mS5JlbM=.03a192d5-b8e7-4389-b4b4-400ab431d15b@github.com>

On Mon, 14 Oct 2024 20:01:42 GMT, Rob Spoor <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 214:
>> 
>>> 212:                             cbuf[off + i] = cs.charAt(next + i);
>>> 213:                     }
>>> 214:                 }
>> 
>> Just a drive-by observation, not for this PR to handle:
>> 
>> If four out of five `CharSequence` implementations in the JDK include fast-path methods for copying char ranges into an output buffer, perhaps it is time to introduce `CharSequence::getChars` as a default method? 
>> 
>> That way, code like this wouldn't need to special-case for the known fast-paths, and external implementations could also join the party.
>
> That had been discussed here: https://github.com/openjdk/jdk/pull/21371#pullrequestreview-2350588453

Stay tuned. I have already forwarded a subsequent RFE and PR to cover this topic. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21371#discussion_r1800909261

From shade at openjdk.org  Tue Oct 15 11:07:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 11:07:32 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v10]
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Export in JVMCI too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20139/files
  - new: https://git.openjdk.org/jdk/pull/20139/files/9f7ad7ab..479781df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20139&range=08-09

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20139/head:pull/20139

PR: https://git.openjdk.org/jdk/pull/20139

From shade at openjdk.org  Tue Oct 15 11:07:34 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Oct 2024 11:07:34 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <_jxZbWC74sQnUsT7Pher9IhyI2zWos38DYNsnB6azSo=.e90cf5e6-d008-4022-a752-61c26505b560@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
 <_jxZbWC74sQnUsT7Pher9IhyI2zWos38DYNsnB6azSo=.e90cf5e6-d008-4022-a752-61c26505b560@github.com>
Message-ID: <ASHyXEP0mr5bgz9zwh0OeUOn3qdO6jB10Qt7lHLVF8s=.5f85dc2c-f2ba-4e47-a334-a0e9ddaeabc1@github.com>

On Tue, 15 Oct 2024 10:02:15 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Simplify: just do keep alive checks
>>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>>  - More precise bit-unmasks
>>  - Reconcile with late barrier expansion in G1
>>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>>  - Review comments
>>  - Merge branch 'master' into JDK-8329597-intrinsify-reference-clear
>>  - Also dispatch to slow-path on other arches
>>  - Fix other arches
>>  - Tighten up comments in Reference javadoc
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/580eb62d...9f7ad7ab
>
> src/hotspot/share/gc/z/zBarrierSetRuntime.hpp line 43:
> 
>> 41:   static void store_barrier_on_oop_field_with_healing(oop* p);
>> 42:   static void store_barrier_on_oop_field_without_healing(oop* p);
>> 43:   static void no_keepalive_store_barrier_on_oop_field_without_healing(oop* p);
> 
> Could you please export this to JVMCI? I.e.,
> 
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 5452cca96b8..46aeb996c56 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -847,6 +847,7 @@
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::load_barrier_on_oop_field_preloaded_store_good))           \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_load_barrier_on_weak_oop_field_preloaded))    \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_load_barrier_on_phantom_oop_field_preloaded)) \
> +  ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing)   \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_native_oop_field_without_healing))        \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_oop_field_with_healing))                  \
>    ZGC_ONLY(DECLARE_FUNCTION_FROM_ADDR(declare_function_with_value, ZBarrierSetRuntime::store_barrier_on_oop_field_without_healing))               \
> 
> Thanks!

Done!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20139#discussion_r1800937787

From ihse at openjdk.org  Tue Oct 15 11:12:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 11:12:31 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v38]
In-Reply-To: <mjmqM8K8zpix5cV27K6MwmxGTQskHBqH15mpSXOweAo=.dd4384bf-b3d5-4a5f-8598-557ff8b5bdc1@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <mjmqM8K8zpix5cV27K6MwmxGTQskHBqH15mpSXOweAo=.dd4384bf-b3d5-4a5f-8598-557ff8b5bdc1@github.com>
Message-ID: <LpQOmJXx99_WcORp_wkDOdIwfHG_q7JOVgxrVF5afSA=.b651e96b-e9cc-49a9-8c57-f8042a077518@github.com>

On Tue, 15 Oct 2024 09:29:48 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 145 commits:
> 
>  - Only show info message about runtime link when verbose
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Update error message when linking jdk.jlink
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - JLinkDedupTestBatchSizeOne.java test fix
>    
>    Run only the packaged modules version if we have a linkable JDK runtime
>    with packaged modules available as well in the JDK install.
>  - Enable IncludeLocalesPluginTest
>  - ... and 135 more: https://git.openjdk.org/jdk/compare/521effe0...6859a3be

Bot, keep this alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2413589428

From viktor.klang at oracle.com  Tue Oct 15 11:46:34 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 15 Oct 2024 11:46:34 +0000
Subject: Fw: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <07710471-f249-48dc-bac8-40e00960febe@gmail.com>
References: <07710471-f249-48dc-bac8-40e00960febe@gmail.com>
Message-ID: <MW4PR10MB577400AB29878DB7401D3400FF452@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Cay!

>AFAIK, the "greedy/short-circuiting" decision point doesn't have a major impact on performance either. Or am I wrong there?

One of my personal goals was to arrive at a point where the built-in intermediate Stream operations could be implemented as Gatherers with a performance around-the-same-or-better. Greedy allows for less signal tracking which in aggregate over several operations can have a noticeable advantage. Keep in mind that this is primarily around sequential performance, which in my experience is vastly more common than parallel streams.

>If I use the factory methods, I have to make a choice between of/ofGreedy

Back when GREEDY was a Characteristic, you'd still have the choice of adding that or not, and since it was served on the side, it'd be much more likely that developers wouldn't know that was a choice they could make, and wouldn't be connected to the Integrator itself. Making of() the short-name is because it is more capable than ofGreedy() (which does not support short-circuiting). So using it signals a choice of less capability.

>and ofSequential/of.

The reason for ofSequential/of instead of ofParallel/of is that a parallel-capable Gatherer covers more scenarios than a sequential-only versison, so giving the shorter name to the less-capable version would not stand out in the same way when reviewing, and Collector.of is parallel-capable, which seemed more consistent to make Gatherer.of parallel-capable as well.

>First off, I think factory methods should be the favored approach.

Is there something which could be made clearer around that, because that's how I already view it.

>I have seen some gatherer implementations that don't use the factory methods, even though they could have. Is this flexibility useful?

Yes, being able to move from an in-line definition, to a class-local implementation, to a dedicated file implementation provides a gradual path based on user needs and operation evolution. That's the same as for Collector.

>The details are fussy, with the marker interface and the magic default combiner.

I think this is worth expanding a bit on, in what way are they fussy?

>That's where I thought the characteristics approach is a better API. It has precedence, and it is unfussy.

See the archives for the discussion around why Characteristics (which were there for a long time) didn't make it.

>I realize it's not a big deal, and I was going to let it slide. Until I heard Brian's Devoxx talk where he mentioned "peak complexity", and I felt, that's, in a small way, what is present here.

I completely understand your line of thinking, and I'm not sure what'll convince you that we're quite far from the peak (you should have seen some of my prototypes! ?). It is important to remember that there's a pretty vast space of use-cases which needs to be supported, so designing an abstraction which makes sense for a 2-element sequential stream as well as a 1m-element parallel stream, and everything in between had proven to be elusive ever since Streams were introduced in Java 8.

I think it is also worth noting that usage of Gatherers will by far outnumber definition of Gatherers, so appropriate emphasis needs to be placed on usage ergonomics, capabilities, and runtime performance.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
Sent: Monday, 14 October 2024 21:27
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Fw: New candidate JEP: 485: Stream Gatherers

Hi Viktor,

thanks for your clarifications.

I agree that from a performance point of view, there isn't all that much to be gained. I thought more about parallelizing distinctBy and windowSliding, Perhaps one can squeeze out a modest gain, but I am not excited by the potential.

AFAIK, the "greedy/short-circuiting" decision point doesn't have a major impact on performance either. Or am I wrong there?

In my mind, given that performance is not worth more than maybe a tweak, this amplifies my first issue with the surface API.

I started out thinking that almost nobody is going to write a gatherer, so why worry? But I found myself writing a couple in the last few days. And I wonder whether the current API is at "peak complexity".

If I use the factory methods, I have to make a choice between of/ofGreedy and ofSequential/of.

And if I don't use the factory methods, I have to mess with a marker interface or a method yielding a magic default.

Is there some virtuous collapse?

First off, I think factory methods should be the favored approach. And "of" should be the safe choice. That's why I would rename ofSequential into of, and introduce ofParallel for optimization. Like with of/ofGreedy.

I have seen some gatherer implementations that don't use the factory methods, even though they could have. Is this flexibility useful? The details are fussy, with the marker interface and the magic default combiner. That's where I thought the characteristics approach is a better API. It has precedence, and it is unfussy.

I realize it's not a big deal, and I was going to let it slide. Until I heard Brian's Devoxx talk where he mentioned "peak complexity", and I felt, that's, in a small way, what is present here.

Cheers,

Cay

--

(Moving this to core-libs-dev)

Cay,

Regarding 1, Characteristics was a part of the Gatherers-contract for a very long time, alas it didn't end up worth its cost. There's a longer discussion on the topic here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/118138.html (and I'm sure that there were more, but that's the one which comes to mind)

Regarding 2, I did have a prototype which had a Downstream in the Combiner, but created a new dimension of complexity which made it even harder for people to move from sequential to parallelizable. The door isn't closed on it, but I remain unconvinced it's worth the surface area for performance reasons.

As a bit of a side-note, it's worth knowing that in the reference stream implementation, it is not unusual that parallel-capable stages are executed as "islands" which means that short-circuiting signals cannot travel across those islands. Since parallel-capable Gatherers can be fused to execute in the same "island" if we get to a place where "all" intermediate operations are parallel-capable Gatherers, there'd be a single end-to-end "island" and hence the ability to propagate the short-circuiting would be preserved in all modes of execution. Also worth knowing that a `gather(?)` immediately followed by a `collect(?)` can also be fused to run together.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: jdk-dev <jdk-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
Sent: Friday, 4 October 2024 19:58
To: jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: Re: New candidate JEP: 485: Stream Gatherers

Hi, I have some belated questions about the design choices in this API that I could not find addressed in the JEP.

1. Why aren't characteristics used to express "greediness/short-circuiting" or "sequentialness/parallelizability"?

I understand that for the former I use ofGreedy/of, or implement Gatherers.Integrator.Greedy/Gatherers.Integrator. And for the latter, I use ofSequential/of, or, if I implement the Gatherer interface, have the combiner return defaultCombiner() or not.

But it seems a bit complex and less familiar than the characteristics mechanism that exists for spliterators, streams, and collectors.

The original design document (https://cr.openjdk.org/~vklang/Gatherers.html) used characteristics, so I wonder what motivated the change.

2. Why wasn't the combiner() designed to allow pushing of elements to the end of the first range's sink? Then distinctBy could be parallelized without buffering the elements. More generally, with some state fiddling one can then handle the elements around range splits.

As it is, I don't see how to parallelize such computations other than to buffer all elements.

I looked at the project at https://github.com/jhspetersson/packrat that implements a number of gatherers. Only one uses a combiner, to join buffers until their contents can be pushed in the finisher.

Cheers,

Cay
--

Cay S. Horstmann | https://horstmann.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241015/b50bade2/attachment-0001.htm>

From liach at openjdk.org  Tue Oct 15 12:07:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 12:07:11 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: <v6I_RXtNgk7w1erb1jtCX62DN9ld_FN8ld6DSjC7f-0=.b131d0ac-fb1e-4344-82e0-185da8bcbec5@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. Can anyone review this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20200#issuecomment-2413727929

From dholmes at openjdk.org  Tue Oct 15 12:29:27 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 12:29:27 GMT
Subject: RFR: 8338596: Clarify handling of restricted and caller-sensitive
 methods [v8]
In-Reply-To: <0WeR12j3CDMiE5v6OT8XA0uiSok4bCtpN7NP26AQdc0=.15131fa1-930c-4c61-85d1-d9a999d4b64d@github.com>
References: <t_Mnmha2iaRWpUzRCutGc6cpqDw-aYwnYmFhLoFLp7I=.a0512c5d-b815-4a7b-bccc-0de2dc13e367@github.com>
 <0WeR12j3CDMiE5v6OT8XA0uiSok4bCtpN7NP26AQdc0=.15131fa1-930c-4c61-85d1-d9a999d4b64d@github.com>
Message-ID: <mnn9uPL6Wxr1JmYvrb9IOiCbkOMx5Pnd_6syaCqAdOE=.f8f385c9-ffde-49f6-af96-da110e7842de@github.com>

On Wed, 9 Oct 2024 11:24:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR moves the section on restricted methods from the the javadoc of `java.lang.foreign` package into a standalone static [javadoc page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>> 
>> This is because, after [JEP 472](https://openjdk.org/jeps/472), we now have restricted methods *outside* the foreign package, namely `System::loadLibrary`, `Runtime::loadLibrary` (and related methods). And, even before, we also had a restricted method in `ModuleLayer.Controller`.
>> 
>> The new static page contains some guidance of what happens when a restricted method is called when there's no Java frame on the stack (this can happen e.g. when upcalling into a restricted method from a native thread not known to the JVM) - that is, the call is treated as originating from an unnamed module.
>> 
>> The static page is linked from the restricted method banner in a restricted method javadoc. Here's an [example](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/Linker.html#downcallHandle(java.lang.foreign.MemorySegment,java.lang.foreign.FunctionDescriptor,java.lang.foreign.Linker.Option...)).
>
> Maurizio Cimadamore 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 'master' into restricted_better_javadoc
>  - Merge pull request #22 from hns/restricted_better_javadoc
>    
>    Only link restricted method doc-file if it is available
>  - Only link restricted method doc-file if it is available
>  - Fix paths to links
>  - Fix javadoc test failure
>  - Revert reference to caller stack
>  - Update src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Move restricted method page to `java.lang`
>    Update restricted method page
>  - Initial push

I think my earlier comment got lost. This PR makes no changes to CS methods so the JBS issue title should just have been "Clarify handling of restricted methods".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21067#issuecomment-2413775022

From rsunderbabu at openjdk.org  Tue Oct 15 12:31:52 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 15 Oct 2024 12:31:52 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
Message-ID: <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>

> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
> 
> Testing: The test was run for 100 times with -Xcomp option.

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  checking if time is monotonic

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21413/files
  - new: https://git.openjdk.org/jdk/pull/21413/files/c0998456..8a963110

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21413&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21413&range=01-02

  Stats: 15 lines in 1 file changed: 8 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21413.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21413/head:pull/21413

PR: https://git.openjdk.org/jdk/pull/21413

From mullan at openjdk.org  Tue Oct 15 13:03:33 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 13:03:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
Message-ID: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@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 familiar with.

-------------

Commit messages:
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge
 - fix setOpenURIHandler docs
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Fix whitespace
 - Merge
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove windows-specific policy file as it is no longer needed.
 - clientlibs: Updated Problemlist JBS ID for javax/swing/JPopupMenu/6694823/bug6694823.java
 - Merge
 - ... and 73 more: https://git.openjdk.org/jdk/compare/a601cd2e...d05122fb

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338411
  Stats: 63777 lines in 1825 files changed: 935 ins; 59236 del; 3606 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 Oct 15 13:03:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 13:03:33 GMT
Subject: RFR: 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: <UeySvh7AQqeSsG8yAZRYFmWTuf83RoFP5lMQgxVOLt4=.a8119b9a-13ad-4079-a67a-7d930aa271df@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...

@seanjmullan I think you can use many lines of command in one github comment, like

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2411850563

From erikj at openjdk.org  Tue Oct 15 13:08:13 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Oct 2024 13:08:13 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <btMPe3zI6BNHXOgftx7p6SfrSmaQ4FzHHk67OZhSZog=.7d072c29-5d9f-4859-9f9f-f53e018e2d74@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
 <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>
 <btMPe3zI6BNHXOgftx7p6SfrSmaQ4FzHHk67OZhSZog=.7d072c29-5d9f-4859-9f9f-f53e018e2d74@github.com>
Message-ID: <lIm3amlrBIt4EyI36GlXw5c94MlkUyZcp6kToQH1F28=.37de75aa-09df-4730-b524-847782a02ebd@github.com>

On Mon, 14 Oct 2024 23:26:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > I'm taking this fix for a spin over night in the environment where I noticed the problem.
> 
> I'll hold off integrating until that is over.

Test successful, thanks for fixing this!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2413865347

From dfuchs at openjdk.org  Tue Oct 15 13:12:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 13:12:11 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
Message-ID: <42h9p9pm2AG7UsM4pGWWj46sCbHzbeL7aQw9QgeRa4Y=.eecb7fa0-3141-40d0-b348-0f992907981c@github.com>

On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
>> 
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checking if time is monotonic

test/jdk/java/time/tck/java/time/TCKInstant.java line 196:

> 194:             instantMillis = Instant.now().toEpochMilli();
> 195:             afterMillis = Instant.now(Clock.systemUTC()).toEpochMilli();
> 196:             diff = instantMillis - beforeMillis;

Alternatively, you could set:

- `diff = afterMillis - beforeMillis;` (range should be < 100ms, instant is anyhwere inside)  or,
- `diff = Math.abs(afterMillis / 2 - instantMillis + beforeMillis / 2);` (distance from instant to midpoint should be < 100ms)

Not that it matters much I guess - but it would give more symmetry... Feel free to ignore :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1801136453

From rsunderbabu at openjdk.org  Tue Oct 15 13:34:15 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 15 Oct 2024 13:34:15 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <42h9p9pm2AG7UsM4pGWWj46sCbHzbeL7aQw9QgeRa4Y=.eecb7fa0-3141-40d0-b348-0f992907981c@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
 <42h9p9pm2AG7UsM4pGWWj46sCbHzbeL7aQw9QgeRa4Y=.eecb7fa0-3141-40d0-b348-0f992907981c@github.com>
Message-ID: <vp3qPpmjxQ_tXDGYSN8bxf-UlSwXvIGfo7rVgRHeJns=.16c250ed-68e8-4178-b54c-4ec8d2a13475@github.com>

On Tue, 15 Oct 2024 13:08:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   checking if time is monotonic
>
> test/jdk/java/time/tck/java/time/TCKInstant.java line 196:
> 
>> 194:             instantMillis = Instant.now().toEpochMilli();
>> 195:             afterMillis = Instant.now(Clock.systemUTC()).toEpochMilli();
>> 196:             diff = instantMillis - beforeMillis;
> 
> Alternatively, you could set:
> 
> - `diff = afterMillis - beforeMillis;` (range should be < 100ms, instant is anyhwere inside)  or,
> - `diff = Math.abs(afterMillis / 2 - instantMillis + beforeMillis / 2);` (distance from instant to midpoint should be < 100ms)
> 
> Not that it matters much I guess - but it would give more symmetry... Feel free to ignore :-)

AFAIU, the original intention of the test is to check if Instant.now and Instant.now(Clock.systemUTC()) returns almost same time since the underlying clock is same.
Given that premise,
suggestion 1: it does the job but doesn't show the intention in a better way.
suggestion 2: it is not same as what the test wanted to check.
If you are fine, I would like to retain the logic I have in my latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1801176742

From jlahoda at openjdk.org  Tue Oct 15 13:34:24 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 15 Oct 2024 13:34:24 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v16]
In-Reply-To: <ptKUj1eaw0YHXVsjJn4jyxXrBrOSuX2ajp-IU-wBL9I=.3e1c3665-4a87-49f9-b07e-d34e3fb5cf38@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <ptKUj1eaw0YHXVsjJn4jyxXrBrOSuX2ajp-IU-wBL9I=.3e1c3665-4a87-49f9-b07e-d34e3fb5cf38@github.com>
Message-ID: <P2LPHuY9JFppzoidSSycIOwi9ZpzZ1xtpCHR0Qk7mjo=.72631e9c-d203-4efa-980e-fa6d9e74953e@github.com>

On Wed, 2 Oct 2024 14:03:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - extra check to make sure we're excluding sub-packages too
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - exclude list is now module specific
>  - remove empty if statement, debugging showed the condition is never true
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/d6820d13...47ba2a1c

Still looks good to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18934#pullrequestreview-2369361040

From mdoerr at openjdk.org  Tue Oct 15 13:36:16 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 15 Oct 2024 13:36:16 GMT
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <tbcIBJ-GWYdoj0_r3lYliMRkqZUAQnq5gMKNJCQoMFs=.29677ff6-e6de-4a5b-9f2e-5a7926bfc06b@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
 <LFNK4V03VSlMWMQteoDySahr8dbMHWJp3mHlS3mSU_E=.94af9f64-6a1c-47a7-bbaf-a38df13bf2d6@github.com>
 <tbcIBJ-GWYdoj0_r3lYliMRkqZUAQnq5gMKNJCQoMFs=.29677ff6-e6de-4a5b-9f2e-5a7926bfc06b@github.com>
Message-ID: <70FV3F8MeF_KocRmdISVDySY0VitB-gDDIDaNR_iT88=.8a30ced1-19f6-4f74-abb3-488b0dfcc756@github.com>

On Tue, 15 Oct 2024 07:57:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Are you able to run the `SegmentBulkMismatch` benchmark on the various BE platforms?

Thanks for the hint. I've run it with the old implementation before [JDK-8339531](https://bugs.openjdk.org/browse/JDK-8339531) but with the new micro benchmark and the current implementation with your fix on Power8 Big Endian. Some benchmarks are faster now, some a little slower, but I couldn't see any significant regression. So, I guess we can live with it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21258#issuecomment-2413932956

From pminborg at openjdk.org  Tue Oct 15 14:02:14 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 15 Oct 2024 14:02:14 GMT
Subject: RFR: 8340189: 8339531 incorrect for Big Endian platforms
In-Reply-To: <70FV3F8MeF_KocRmdISVDySY0VitB-gDDIDaNR_iT88=.8a30ced1-19f6-4f74-abb3-488b0dfcc756@github.com>
References: <8BvsT6bVnJ3l-vv5ksOnN3juDfbmh3PqkthXE9a0Dp0=.8dbb55c7-df21-44d7-8f37-4914cfae6596@github.com>
 <LFNK4V03VSlMWMQteoDySahr8dbMHWJp3mHlS3mSU_E=.94af9f64-6a1c-47a7-bbaf-a38df13bf2d6@github.com>
 <tbcIBJ-GWYdoj0_r3lYliMRkqZUAQnq5gMKNJCQoMFs=.29677ff6-e6de-4a5b-9f2e-5a7926bfc06b@github.com>
 <70FV3F8MeF_KocRmdISVDySY0VitB-gDDIDaNR_iT88=.8a30ced1-19f6-4f74-abb3-488b0dfcc756@github.com>
Message-ID: <3Wq1ZVNjx17rh9fbOvnvKcXAvP6acd52Y5QE_6OmqLI=.2edaf871-4d23-4fab-9643-b1ecd337ba79@github.com>

On Tue, 15 Oct 2024 13:33:16 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> This version uses little endian accesses on big endian machines. This may defeat the purpose of [JDK-8339531](https://bugs.openjdk.org/browse/JDK-8339531) for those platforms. Accesses are typically slower when using them with endianness mismatch. But it looks at least correct. Thanks for providing a fix.
>> 
>> Are you able to run the `SegmentBulkMismatch` benchmark on the various BE platforms? This will provide us with clear figures if there is an improvement or not.  (The benchmark runs both the old and new code path)
>> 
>> When we have the figures, we could (if necessary) open up a new issue targeting improved performance for BE platforms. I could help in such an effort but I can't drive it because I don't have access to a BE platform.
>
>> Are you able to run the `SegmentBulkMismatch` benchmark on the various BE platforms?
> 
> Thanks for the hint. I've run it with the old implementation before [JDK-8339531](https://bugs.openjdk.org/browse/JDK-8339531) but with the new micro benchmark and the current implementation with your fix on Power8 Big Endian. Some benchmarks are faster now, some a little slower, but I couldn't see any significant regression. So, I guess we can live with it.

Thanks, @TheRealMDoerr and @offamitkumar for helping me out with this one!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21258#issuecomment-2414003523

From cay.horstmann at gmail.com  Tue Oct 15 14:07:50 2024
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Tue, 15 Oct 2024 16:07:50 +0200
Subject: Fw: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <MW4PR10MB577400AB29878DB7401D3400FF452@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <07710471-f249-48dc-bac8-40e00960febe@gmail.com>
 <MW4PR10MB577400AB29878DB7401D3400FF452@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <dcb3a05c-f193-46b2-ba2c-6023c0a5c155@gmail.com>

Hi Viktor, thanks again for sharing your design decisions. I agree this is a minor matter because not many programmers will implement gatherers. Let me try to explain my confusion.

On 15/10/2024 13:46, Viktor Klang wrote:

> Making of() the short-name is because it is more capable than ofGreedy() (which does not support short-circuiting). So using it signals a choice of less capability.

I don't understand why a short-circuiting integrator is "more capable" than a greedy one. And why the "less capable" one would then be the subclass.

What is the capability? To never short-circuit? To signal short-circuiting?

> The reason for ofSequential/of instead of ofParallel/of is that a parallel-capable Gatherer covers more scenarios than a sequential-only versison, so giving the shorter name to the less-capable version would not stand out in the same way when reviewing, and Collector.of is parallel-capable, which seemed more consistent to make Gatherer.of parallel-capable as well.

Again, what is "less capable"?

When you write "not stand out in the reviewing", I interpret that as follows: "of" means the mechanism providing maximum efficiency, that we want implementors to use. And "ofXXX" means they didn't go all the way, either because of the nature of the processing or because they didn't take the trouble to do all the work.

With of/ofSequential, I can see that point of view. "ofSequential" is a warning that, when used with a parallel stream, there is the potential for disappointment.

But what about implementing a gatherer that never short-circuits, like all three gatherers in the JEP? Here, "ofGreedy" is an indication that an optimization can be made (pushing vs. pulling), right? And that's what we want the implementor to choose.

That's where my struggle comes in. How can I phrase my advice in a symmetric way? Right now, my advice is "if the integrator doesn't short-circuit, advertise that benefit by using ofGreedy" and "if the gatherer can't combine results, advertise that drawback by using ofSequential".

Or maybe I misunderstand greedy?

> 
>  >First off, I think factory methods should be the favored approach.
> 
> Is there something which could be made clearer around that, because that's how I already view it.

Put the factory method first in the JEP :-)

>  >The details are fussy, with the marker interface and the magic default combiner.
> 
> I think this is worth expanding a bit on, in what way are they fussy?
> 

Maybe fussy is not a good term. Baroque? This is what went through my head when I studied the design.

1. The way to tell whether a gatherer is sequential is very unusual. To provide a sequential gatherer I must fail to override a default method. I don't recall seeing anything like this in the Java API.

2. The way to tell whether an integrator is greedy is through a subinterface. That's fine, except it's a marker interface with no new methods. And then why not use a subinterface for parallelizable gatherers, where one could make combiner a subinterface method? Too OO for 2024?

3. Here we have two different mechanisms for what streams and collectors address with a simple and unified approach: flags.

I don't strongly care about this, just answering your question.

Cheers,

Cay

-- 

Cay S. Horstmann | https://horstmann.com


From viktor.klang at oracle.com  Tue Oct 15 14:48:00 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 15 Oct 2024 14:48:00 +0000
Subject: [External] : Re: Fw: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <dcb3a05c-f193-46b2-ba2c-6023c0a5c155@gmail.com>
References: <07710471-f249-48dc-bac8-40e00960febe@gmail.com>
 <MW4PR10MB577400AB29878DB7401D3400FF452@MW4PR10MB5774.namprd10.prod.outlook.com>
 <dcb3a05c-f193-46b2-ba2c-6023c0a5c155@gmail.com>
Message-ID: <MW4PR10MB57748D537C5EDDE29D7D8837FF452@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Cay,

No problems at all! ? Sharing the background is interesting because people rarely can see "what didn't work" or "what led to this".

>I don't understand why a short-circuiting integrator is "more capable" than a greedy one. And why the "less capable" one would then be the subclass.

Being able to consume Set(0..N) elements is a much larger set than Set(N), or in other terms, being able to (but not necessarily having to) terminate before consuming an entire stream makes the operation able to execute on top of "infinite" streams, greedy operations wouldn't terminate in such cases.

So if a "short-circuiting" operation can consume potentially any number of elements, and a "greedy" operation only can consume all elements, and all-elements is a length subset of "any prefix"?so it is "less capable".

>But what about implementing a gatherer that never short-circuits, like all three gatherers in the JEP? Here, "ofGreedy" is an indication that an optimization can be made (pushing vs. pulling), right? And that's what we want the implementor to choose.

Not necessarily push-vs-pull (Java Streams are by nature push-streams) but rather the cost of having to track/inspect short-circuiting across N stages of processing turns out to be a non-negligible cost so if you don't want to pay for it, you can opt out. For short-circuiting operations it's a cost you're willing to pay in order to be able to only consume a prefix of the stream.

>That's where my struggle comes in. How can I phrase my advice in a symmetric way? Right now, my advice is "if the integrator doesn't short-circuit, advertise that benefit by using ofGreedy" and "if the gatherer can't combine results, advertise that drawback by using ofSequential".

Ah, I see what you're thinking there. I tend to try to want to frame things like that from multiple vantage points, so to me it would look something like this:

Implementor: "use ofGreedy to signal that this operation does not itself initiate short-circuiting"
Reviewer: "when you see ofGreedy verify that this operation does not itself initiate short-circuiting"
Debugger: "when the expectation was that the stream should be short-circuiting and isn't, one thing to look for is ofGreedy"

Implementor: "use ofSequential to signal that this operation is intended to always be executed sequentially"
Reviewer: "when you see ofSequential, understand why the operation can't/shouldn't be parallelized for parallel streams"
Debugger: "if the parallel stream is not performing as well as expected, one thing to look for is ofSequential!

Many times, it's the same person in the different roles at different times, so understanding what the signal indicates to each role is good.

>Put the factory method first in the JEP :-)

I'd expect most Java developers to encounter this via the Javadoc and I put the factory as the main example: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/stream/Gatherer.html


>1. The way to tell whether a gatherer is sequential is very unusual. To provide a sequential gatherer I must fail to override a default method. I don't recall seeing anything like this in the Java API.

To be fair, the "interface with only methods returning functional interfaces" is a pretty rare sight as well? Using sentinel values turned out to be the low-energy state solution:

By default a Gatherer is stateless, if you need state, you need to provide a Supplier which creates it.
By default a Gatherer is sequential, if you need parallelization, you need to provide a BinaryOperator which provides it.
By default a Gatherer does nothing on end-of-stream, if you need to do something then, you need to provide a BiFunction which does it.

>2. The way to tell whether an integrator is greedy is through a subinterface. That's fine, except it's a marker interface with no new methods. And then why not use a subinterface for parallelizable gatherers, where one could make combiner a subinterface method? Too OO for 2024?

What about stateless Gatherers? Is that a marker interface too? I've been down this rabbit hole a couple of times and have the scars to prove it. ?

>3. Here we have two different mechanisms for what streams and collectors address with a simple and unified approach: flags.

I guess it bears repeating: Please see the discussion around why Characteristics didn't make it. ?

>I don't strongly care about this, just answering your question.

Fair enough!

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Cay Horstmann <cay.horstmann at gmail.com>
Sent: Tuesday, 15 October 2024 16:07
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: Fw: New candidate JEP: 485: Stream Gatherers

Hi Viktor, thanks again for sharing your design decisions. I agree this is a minor matter because not many programmers will implement gatherers. Let me try to explain my confusion.

On 15/10/2024 13:46, Viktor Klang wrote:

> Making of() the short-name is because it is more capable than ofGreedy() (which does not support short-circuiting). So using it signals a choice of less capability.

I don't understand why a short-circuiting integrator is "more capable" than a greedy one. And why the "less capable" one would then be the subclass.

What is the capability? To never short-circuit? To signal short-circuiting?

> The reason for ofSequential/of instead of ofParallel/of is that a parallel-capable Gatherer covers more scenarios than a sequential-only versison, so giving the shorter name to the less-capable version would not stand out in the same way when reviewing, and Collector.of is parallel-capable, which seemed more consistent to make Gatherer.of parallel-capable as well.

Again, what is "less capable"?

When you write "not stand out in the reviewing", I interpret that as follows: "of" means the mechanism providing maximum efficiency, that we want implementors to use. And "ofXXX" means they didn't go all the way, either because of the nature of the processing or because they didn't take the trouble to do all the work.

With of/ofSequential, I can see that point of view. "ofSequential" is a warning that, when used with a parallel stream, there is the potential for disappointment.

But what about implementing a gatherer that never short-circuits, like all three gatherers in the JEP? Here, "ofGreedy" is an indication that an optimization can be made (pushing vs. pulling), right? And that's what we want the implementor to choose.

That's where my struggle comes in. How can I phrase my advice in a symmetric way? Right now, my advice is "if the integrator doesn't short-circuit, advertise that benefit by using ofGreedy" and "if the gatherer can't combine results, advertise that drawback by using ofSequential".

Or maybe I misunderstand greedy?

>
>  >First off, I think factory methods should be the favored approach.
>
> Is there something which could be made clearer around that, because that's how I already view it.

Put the factory method first in the JEP :-)

>  >The details are fussy, with the marker interface and the magic default combiner.
>
> I think this is worth expanding a bit on, in what way are they fussy?
>

Maybe fussy is not a good term. Baroque? This is what went through my head when I studied the design.

1. The way to tell whether a gatherer is sequential is very unusual. To provide a sequential gatherer I must fail to override a default method. I don't recall seeing anything like this in the Java API.

2. The way to tell whether an integrator is greedy is through a subinterface. That's fine, except it's a marker interface with no new methods. And then why not use a subinterface for parallelizable gatherers, where one could make combiner a subinterface method? Too OO for 2024?

3. Here we have two different mechanisms for what streams and collectors address with a simple and unified approach: flags.

I don't strongly care about this, just answering your question.

Cheers,

Cay

--

Cay S. Horstmann | https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!NoHCnee1zi29L19LosVsyGdjFa1TJ9Ioszv2U02jMGnoWjQbyoGMCq4d8tv7O--v6s6gLgqOGfNr1RwC2sOUl5MfHQ$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241015/62c99821/attachment-0001.htm>

From acobbs at openjdk.org  Tue Oct 15 15:06:10 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 15 Oct 2024 15:06:10 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <dMquznkKKgYB9eSut-Dg9EoOVxieqKwZ-D7Pf7LwrbM=.d1111f50-9adc-453e-a5fd-e57379f84ed4@github.com>

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Albeit with my very basic understanding of these internals, it seems wrong that the `FileChannel` created to represent a special ends up also being a `SeekableFileChannel`. This seems like the true root of the problem - that is, the fact that these files are being labeled as seekable but they're not actually seekable is what leads to the bug.

The approach also this leads to the requirement for "fixups" like these, which are brittle and kindof a red flag that something is not quite right:

if (!(ch instanceof SeekableByteChannel sbc) ||
     (ch instanceof FileChannelImpl fci && isOther()))


In other words, we already have an interface for representing exactly this situation, so why not use it? What is the rationale for not doing so? I'm not saying there isn't one, just seeking to better understand the trade-offs...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2414194787

From dfuchs at openjdk.org  Tue Oct 15 15:19:23 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:19:23 GMT
Subject: RFR: 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: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@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...

Impressive work. I had a look at everything source in `net`, `logging`, `jmx` and `httpclient`.

Mostly good, but I was surprised to see an explicit new `throw new SecurityException()` in `java.util.logging`; Also JMX still supports authentication and coarse authorisation, which means that `SecurityException` can still be thrown by the `JMXAuthenticator` / `MBeanServerAccessController` on the server side and thrown on the client side. I have made some suggestions.

src/java.base/share/classes/java/net/URLClassLoader.java line 667:

> 665:      * @param codesource the codesource
> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
> 667:      * @return the permissions for the codesource

Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?

src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:

> 2428:     @Deprecated(since="17", forRemoval=true)
> 2429:     public void checkAccess() {
> 2430:         throw new SecurityException();

Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 159:

> 157:      * is specified for the MBean.
> 158:      * @throws SecurityException if the client does not have permission
> 159:      * to perform this operation.

Maybe we should revert those changes, or word them differently. AFAIU, is is still possible for a JMXConnectorServer to implement coarse grained authorization by setting up an `MBeanServerAccessController`, and in fact, the default JMX Agent does that. The JDK has a built-in implementation of `MBeanServerAccessController`,  `MBeanServerFileAccessController`, which will throw `SecurityException` if access is denied by the `MBeanServerFileAccessController`. I believe this will result in the `RMIConnection` throwing `SecurityException` if the operation is denied by the `MBeanServerAccessController`.

So I believe - in all methods here and in `RMIConnectionImpl`, we should leave the door open for `SecurityException` to get thrown.

An alternative could be to cover that use case with a blanket statement, here, in `RMIConnectionImpl`, in `MBeanServer`, and in `MBeanServerConnection`.

src/java.management/share/classes/javax/management/remote/JMXAuthenticator.java line 67:

> 65:      *
> 66:      * @exception SecurityException if the server cannot authenticate the user
> 67:      * with the provided credentials.

Should this be reverted? Authentication has not been removed.

src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:

> 223:      *
> 224:      * @exception SecurityException if the connection cannot be made
> 225:      * for security reasons.

I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.

-------------

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369425602
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801215698
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801291195
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801341618
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801357691
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801362306

From alanb at openjdk.org  Tue Oct 15 15:21:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 15:21:11 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <dMquznkKKgYB9eSut-Dg9EoOVxieqKwZ-D7Pf7LwrbM=.d1111f50-9adc-453e-a5fd-e57379f84ed4@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <dMquznkKKgYB9eSut-Dg9EoOVxieqKwZ-D7Pf7LwrbM=.d1111f50-9adc-453e-a5fd-e57379f84ed4@github.com>
Message-ID: <szJZdX8wdDFBWxJswLZKuB3WonmSVILQ-R85Hv5c2x0=.29442db5-8255-4a8b-a4da-7542f662f751@github.com>

On Tue, 15 Oct 2024 15:03:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Albeit with my very basic understanding of these internals, it seems wrong that the `FileChannel` created to represent a special ends up also being a `SeekableFileChannel`. This seems like the true root of the problem - that is, the fact that these files are being labeled as seekable but they're not actually seekable is what leads to the bug.

FileChannel implements SeekableByteChannel. You'll see exactly the same thing if you use FileChannel.open to open a special file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2414238334

From acobbs at openjdk.org  Tue Oct 15 15:21:11 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 15 Oct 2024 15:21:11 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <szJZdX8wdDFBWxJswLZKuB3WonmSVILQ-R85Hv5c2x0=.29442db5-8255-4a8b-a4da-7542f662f751@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <dMquznkKKgYB9eSut-Dg9EoOVxieqKwZ-D7Pf7LwrbM=.d1111f50-9adc-453e-a5fd-e57379f84ed4@github.com>
 <szJZdX8wdDFBWxJswLZKuB3WonmSVILQ-R85Hv5c2x0=.29442db5-8255-4a8b-a4da-7542f662f751@github.com>
Message-ID: <FG-s0FN_V_lzEGjPOAgXZY2s6ESFLr9JU6TCPaEizNQ=.996f34d2-fad8-473f-bcb5-8ec93e4e6e88@github.com>

On Tue, 15 Oct 2024 15:13:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> FileChannel implements SeekableByteChannel. You'll see exactly the same thing if you use FileChannel.open to open a special file.

Ah... thanks. Also (for example) `FileInputStream.getChannel()` returns a `FileChannel`, so we're stuck with it.

OK so this is an "original sin" situation which we can't fix here. Thanks for the clarification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2414264717

From bpb at openjdk.org  Tue Oct 15 15:21:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 15:21:13 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <ZZzZB-lArNX3FJ83V0nCkgOBCVBYdNp6Y_eY37UFR88=.37cdcb77-b3dc-4657-88c2-0b2ea427f78a@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <ZZzZB-lArNX3FJ83V0nCkgOBCVBYdNp6Y_eY37UFR88=.37cdcb77-b3dc-4657-88c2-0b2ea427f78a@github.com>
Message-ID: <dFJ1MWY7xVOmsqShAcmkSyeNkN1fD12oLP86OxOiqGw=.3ef7b215-6aba-4b26-b6bf-3c173ceddf55@github.com>

On Tue, 15 Oct 2024 05:15:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> src/java.base/windows/native/libjava/io_util_md.h line 44:
> 
>> 42: WCHAR* currentDir(int di);
>> 43: int currentDirLength(const WCHAR* path, int pathlen);
>> 44: JNIEXPORT int handleAvailable(FD fd, jlong *pbytes);
> 
> This should not be exported.

Okay.

> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 402:
> 
>> 400:     HANDLE handle = (HANDLE)(handleval(env, fdo));
>> 401:     jlong available;
>> 402:     if (handleAvailable((jlong)handle, &available)) {
> 
> Ugh, we shouldn't be using handleAvailable here. This native method needs to stand on its own.

Yeah, I was not sure about that. I had a standalone version before this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1801398538
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1801397285

From alanb at openjdk.org  Tue Oct 15 15:21:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 15:21:14 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <dFJ1MWY7xVOmsqShAcmkSyeNkN1fD12oLP86OxOiqGw=.3ef7b215-6aba-4b26-b6bf-3c173ceddf55@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <ZZzZB-lArNX3FJ83V0nCkgOBCVBYdNp6Y_eY37UFR88=.37cdcb77-b3dc-4657-88c2-0b2ea427f78a@github.com>
 <dFJ1MWY7xVOmsqShAcmkSyeNkN1fD12oLP86OxOiqGw=.3ef7b215-6aba-4b26-b6bf-3c173ceddf55@github.com>
Message-ID: <STP7eY1VWq8BJPtXinHdC-0UOll-IcFMOvwSdne1kzU=.fcc7bade-6af1-42cc-9b8d-9a94731b0056@github.com>

On Tue, 15 Oct 2024 15:15:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 402:
>> 
>>> 400:     HANDLE handle = (HANDLE)(handleval(env, fdo));
>>> 401:     jlong available;
>>> 402:     if (handleAvailable((jlong)handle, &available)) {
>> 
>> Ugh, we shouldn't be using handleAvailable here. This native method needs to stand on its own.
>
> Yeah, I was not sure about that. I had a standalone version before this.

When/if we get to the point that FIS/FOS/RAF is implemented on FileChannel then it will become clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1801401151

From alanb at openjdk.org  Tue Oct 15 15:24:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 15:24:25 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>

On Tue, 15 Oct 2024 14:27:13 GMT, Daniel Fuchs <dfuchs 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, ...
>
> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
> 
>> 2428:     @Deprecated(since="17", forRemoval=true)
>> 2429:     public void checkAccess() {
>> 2430:         throw new SecurityException();
> 
> Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?

This is forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801415455

From dfuchs at openjdk.org  Tue Oct 15 15:32:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:32:10 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <vp3qPpmjxQ_tXDGYSN8bxf-UlSwXvIGfo7rVgRHeJns=.16c250ed-68e8-4178-b54c-4ec8d2a13475@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
 <42h9p9pm2AG7UsM4pGWWj46sCbHzbeL7aQw9QgeRa4Y=.eecb7fa0-3141-40d0-b348-0f992907981c@github.com>
 <vp3qPpmjxQ_tXDGYSN8bxf-UlSwXvIGfo7rVgRHeJns=.16c250ed-68e8-4178-b54c-4ec8d2a13475@github.com>
Message-ID: <wbaui-B7MzjV9wcT1pYNk8CMCu9T1tChy1AccsuzuYo=.f24f9efd-ff09-4d2b-bfed-29725c830e59@github.com>

On Tue, 15 Oct 2024 13:31:37 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> test/jdk/java/time/tck/java/time/TCKInstant.java line 196:
>> 
>>> 194:             instantMillis = Instant.now().toEpochMilli();
>>> 195:             afterMillis = Instant.now(Clock.systemUTC()).toEpochMilli();
>>> 196:             diff = instantMillis - beforeMillis;
>> 
>> Alternatively, you could set:
>> 
>> - `diff = afterMillis - beforeMillis;` (range should be < 100ms, instant is anyhwere inside)  or,
>> - `diff = Math.abs(afterMillis / 2 - instantMillis + beforeMillis / 2);` (distance from instant to midpoint should be < 100ms)
>> 
>> Not that it matters much I guess - but it would give more symmetry... Feel free to ignore :-)
>
> AFAIU, the original intention of the test is to check if Instant.now and Instant.now(Clock.systemUTC()) returns almost same time since the underlying clock is same.
> Given that premise,
> suggestion 1: it does the job but doesn't show the intention in a better way.
> suggestion 2: it is not same as what the test wanted to check.
> If you are fine, I would like to retain the logic I have in my latest commit.

I am fine with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1801437236

From dfuchs at openjdk.org  Tue Oct 15 15:36:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:36:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
Message-ID: <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>

On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>> 
>>> 2428:     @Deprecated(since="17", forRemoval=true)
>>> 2429:     public void checkAccess() {
>>> 2430:         throw new SecurityException();
>> 
>> Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?
>
> This is forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.

OK

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801445724

From ihse at openjdk.org  Tue Oct 15 15:42:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 15:42:17 GMT
Subject: RFR: 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: <V_CgYKM3b79sS7MTegDSIISOX92kZVccIePJlJ4hFzk=.b9cabb49-8f94-4d8b-80a5-c8cd66a2821d@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...

Build changes look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369826643

From duke at openjdk.org  Tue Oct 15 15:55:17 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 15 Oct 2024 15:55:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
Message-ID: <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>

On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a bit of forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.
>
> OK

While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:


if (System.getSecurityManager() != null) {
    foo.checkAccess();
}


I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.

But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801484176

From psandoz at openjdk.org  Tue Oct 15 16:06:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 16:06:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
 <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>
Message-ID: <KwhtqYMZBBM1679bPfCjqPraxUCe_1XKqRDmSL6iDmY=.42f7e0b6-e2bb-42a8-a1c2-27c27603653e@github.com>

On Tue, 15 Oct 2024 09:35:23 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> I gave it a quick scan, and I have no further comments. LGTM.

Thank you, i will kick off an internal test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2414431367

From redestad at openjdk.org  Tue Oct 15 16:11:12 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 15 Oct 2024 16:11:12 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
Message-ID: <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>

On Tue, 15 Oct 2024 08:05:44 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Yep, looks good. And I agree with Claes' evaluation that we should not complicate this construction further, especially that the result is quickly garbage collected when we compile into the string to int array map.
>
> We could also just use `Map<String, int[]>`. This would allow us to skip the whole `Set<Integer>` to `int[]`  transition step, and the temporary `HashMap` is no longer needed.
> 
> Deduplication could occur during registration:
> 
> 
> metaVersions.merge(name, new int[] {version}, (current, val) -> {
>     // Check duplicates
>     for (int v : current) {
>         if (v == version) {
>             return current;
>         }
>     }
>     // Add version
>     int[] merged = Arrays.copyOf(current, current.length + 1);
>     merged[merged.length - 1] = version;
>     return merged;
> });
> 
> 
> while the postprocessing step would simply sort each array:
> 
> 
> for (int[] versions : metaVersions.values()) {
>     // JarFile::getVersionedEntry expects sorted versions
>     Arrays.sort(versions);
> }
> 
> 
> This performs ~10% better on a version-heavy `ZipFileOpen`, and I think the code is reasonably simple compared to the current state of the PR. Thoughts?

I guess performance leans on there being only one or a small number of versions per entry. Which I think is a fair assumption. Still would be good to have a stress test with many entries having many versions and make sure we don't regress such cases too much, no?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1801509202

From rsunderbabu at openjdk.org  Tue Oct 15 16:13:13 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 15 Oct 2024 16:13:13 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <wbaui-B7MzjV9wcT1pYNk8CMCu9T1tChy1AccsuzuYo=.f24f9efd-ff09-4d2b-bfed-29725c830e59@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
 <42h9p9pm2AG7UsM4pGWWj46sCbHzbeL7aQw9QgeRa4Y=.eecb7fa0-3141-40d0-b348-0f992907981c@github.com>
 <vp3qPpmjxQ_tXDGYSN8bxf-UlSwXvIGfo7rVgRHeJns=.16c250ed-68e8-4178-b54c-4ec8d2a13475@github.com>
 <wbaui-B7MzjV9wcT1pYNk8CMCu9T1tChy1AccsuzuYo=.f24f9efd-ff09-4d2b-bfed-29725c830e59@github.com>
Message-ID: <Mvc7F4GZqgaqUVCulQMiQXm2N1S_XbsVgdsL4Yuij-w=.1198a3a4-140d-434b-bf08-ef145213eeb5@github.com>

On Tue, 15 Oct 2024 15:29:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> AFAIU, the original intention of the test is to check if Instant.now and Instant.now(Clock.systemUTC()) returns almost same time since the underlying clock is same.
>> Given that premise,
>> suggestion 1: it does the job but doesn't show the intention in a better way.
>> suggestion 2: it is not same as what the test wanted to check.
>> If you are fine, I would like to retain the logic I have in my latest commit.
>
> I am fine with it.

Thanks @dfuch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1801511176

From mullan at openjdk.org  Tue Oct 15 16:17:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 16:17:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
Message-ID: <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>

On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OK
>
> While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:
> 
> 
> if (System.getSecurityManager() != null) {
>     foo.checkAccess();
> }
> 
> 
> I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.
> 
> But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally
permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801518838

From nbenalla at openjdk.org  Tue Oct 15 16:18:17 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 15 Oct 2024 16:18:17 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v16]
In-Reply-To: <ptKUj1eaw0YHXVsjJn4jyxXrBrOSuX2ajp-IU-wBL9I=.3e1c3665-4a87-49f9-b07e-d34e3fb5cf38@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <ptKUj1eaw0YHXVsjJn4jyxXrBrOSuX2ajp-IU-wBL9I=.3e1c3665-4a87-49f9-b07e-d34e3fb5cf38@github.com>
Message-ID: <AVx5ktHycknxaN4QZyN6bW55fCulOeoMDzWwQSMFS7w=.a78e8547-2d5e-42af-be92-3f070ad7a76c@github.com>

On Wed, 2 Oct 2024 14:03:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - extra check to make sure we're excluding sub-packages too
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - exclude list is now module specific
>  - remove empty if statement, debugging showed the condition is never true
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/d6820d13...47ba2a1c

Can we maybe set the reviewer count to 1? This needs an additional review and the last change was small.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2414458945

From epeter at openjdk.org  Tue Oct 15 16:32:15 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 15 Oct 2024 16:32:15 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
Message-ID: <qs41c2Vqu77-mu5jnDSdHoTxwgYjAWABrhFeesVjHHk=.ae084b95-cee2-41d3-a52e-f8e650bf67a4@github.com>

On Sun, 6 Oct 2024 08:32:20 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> 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

src/hotspot/cpu/x86/x86.ad line 2172:

> 2170: 
> 2171: // Return true if Vector::rearrange needs preparation of the shuffle argument
> 2172: bool Matcher::vector_needs_load_shuffle(BasicType elem_bt, int vlen) {

I think the name needs to be more expressive. If I read it alone, then I would think that it is about all kinds of vectors ... and it is confusing because what is a "load shuffle"? Are we shuffling loads or loading shuffles?

src/hotspot/share/opto/vectornode.hpp line 1618:

> 1616:  public:
> 1617:   VectorLoadShuffleNode(Node* in, const TypeVect* vt)
> 1618:     : VectorNode(in, vt) {}

Can you add a comment above "class VectorLoadShuffleNode" to say what its semantics are?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1801531980
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1801536233

From qamai at openjdk.org  Tue Oct 15 16:33:20 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 15 Oct 2024 16:33:20 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
Message-ID: <RCQLW6m6W945UEPzQiTUCrzbPD5Qwlv1IVfZ97ixyPs=.e55a292d-b92c-4cd1-85e8-bae37a114918@github.com>

On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2414491182

From rriggs at openjdk.org  Tue Oct 15 16:35:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Oct 2024 16:35:12 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
Message-ID: <UKZevczSl2-5-hBjgjp8LN9ud62uEvyUdgsliXA4IIw=.40407083-90e7-4f8c-841f-b504e5d2feea@github.com>

On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
>> 
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checking if time is monotonic

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21413#pullrequestreview-2369962087

From sgehwolf at openjdk.org  Tue Oct 15 16:37:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 16:37:21 GMT
Subject: RFR: 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: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@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...

Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:


        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
        ...
        }


Intentional?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369966554

From duke at openjdk.org  Tue Oct 15 16:37:22 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 15 Oct 2024 16:37:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
Message-ID: <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>

On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.

It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.

These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).

Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801549133

From psandoz at openjdk.org  Tue Oct 15 16:42:18 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 16:42:18 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v23]
In-Reply-To: <cnD4QSr1n6ntVhACh9F9j3OF7_VB8wi7EFD-ZrSwYjE=.fc684c7f-b72c-4738-a5a8-7dda07910f57@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>
 <cnD4QSr1n6ntVhACh9F9j3OF7_VB8wi7EFD-ZrSwYjE=.fc684c7f-b72c-4738-a5a8-7dda07910f57@github.com>
Message-ID: <jmWdAoq1BA3K6a_aoM8VLfW7SMyEzxtzUGWGFEJlvhE=.e83433ed-bfcb-40b1-b019-ddb36431b9a6@github.com>

On Thu, 10 Oct 2024 16:24:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi @vnkozlov , Can you kindly run this through your test infrastructure. We have two review approvals for Java and x86 backend code.

I have kicked off some internal tests (FYI @vnkozlov)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2414510216

From dfuchs at openjdk.org  Tue Oct 15 16:44:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 16:44:16 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
Message-ID: <00frHPVuBzy1HhWEnmBtfSS4CeXN3uOVVilYbvntplY=.40626317-3ede-4a7f-b906-a8fa7829a418@github.com>

On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf <sgehwolf 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, ...
>
> Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:
> 
> 
>         SecurityManager sm = System.getSecurityManager();
>         if (sm != null) {
>         ...
>         }
> 
> 
> Intentional?

@jerboaa  Yes - this is intentional:
> 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).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2414512674

From dfuchs at openjdk.org  Tue Oct 15 16:48:11 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 16:48:11 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
Message-ID: <WQNy4jLSjZC0A87Y-5vRAHrzEmBQ95ZAwh8o8qajyHI=.41674cb0-64d1-4a38-9ca4-09a12b346b55@github.com>

On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
>> 
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checking if time is monotonic

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21413#pullrequestreview-2369993856

From sgehwolf at openjdk.org  Tue Oct 15 16:57:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 16:57:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
Message-ID: <kht8vPv-muz8n2rWPcwE6tr_AIfxSHjqRdW85e7qxQA=.3f1ea0f1-51d8-4b31-ace9-74e00b0f0152@github.com>

On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf <sgehwolf 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, ...
>
> Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:
> 
> 
>         SecurityManager sm = System.getSecurityManager();
>         if (sm != null) {
>         ...
>         }
> 
> 
> Intentional?

> @jerboaa Yes - this is intentional:
> 
> > 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).

OK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2414541204

From jkarthikeyan at openjdk.org  Tue Oct 15 17:03:15 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Tue, 15 Oct 2024 17:03:15 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
Message-ID: <Zu93PI-ZSrlkhthhBjZoqlZZ8oKd0-G_aclNTxOJurE=.ba563dba-6eeb-4eaf-a312-3d4b8c9b02fe@github.com>

On Wed, 9 Oct 2024 09:59:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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 :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2414553899

From mullan at openjdk.org  Tue Oct 15 17:04:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 17:04:25 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
 <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
Message-ID: <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>

On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
>
>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
> 
> It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.
> 
> These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).
> 
> Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.

I see your point now. We have strived to preserve compatibility with libraries that follow well known code patterns as described in the JEP, so I will discuss this with others who are more familiar with the compatibility risk of making this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801595566

From ihse at openjdk.org  Tue Oct 15 17:11:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 17:11:13 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher
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: <uoYKyyDsw2tlQmw7rFO41EnOTtmFBw-eKCTPSJaQbJA=.eed6143e-b09c-45b5-8b38-0491a875c114@github.com>

On Tue, 3 Sep 2024 12:50:01 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).

Bot, keep it alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2414569170

From qamai at openjdk.org  Tue Oct 15 17:29:12 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 15 Oct 2024 17:29:12 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <Zu93PI-ZSrlkhthhBjZoqlZZ8oKd0-G_aclNTxOJurE=.ba563dba-6eeb-4eaf-a312-3d4b8c9b02fe@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <Zu93PI-ZSrlkhthhBjZoqlZZ8oKd0-G_aclNTxOJurE=.ba563dba-6eeb-4eaf-a312-3d4b8c9b02fe@github.com>
Message-ID: <HvR4CCPeXXjDit9Tz6g71KbKIoPkXtJo0h5d4iQLD44=.efe1b43f-b3f4-4e8b-8d43-4c2c941b19a1@github.com>

On Tue, 15 Oct 2024 17:00:26 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction
>
> 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 ihse at openjdk.org  Tue Oct 15 17:32:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 17:32:02 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v2]
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: <96UITN520SU42GFjufedN6uOlfIrduNQYGHJeMId5G0=.abccf54c-2a62-4466-8ff5-563d67a8a4f2@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 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 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:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/43f57b80..0717600c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=00-01

  Stats: 239454 lines in 2229 files changed: 213080 ins; 14335 del; 12039 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  Tue Oct 15 17:37:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 17:37:57 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v3]
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: <hYc_xPXje4v8-iykzOcLLHFlCcPGNa_SH9wM7fiJxT4=.701818af-cc38-49c2-9ad3-c509d0c488e7@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 superfluous SRC.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/0717600c..fc42982f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 2 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 liach at openjdk.org  Tue Oct 15 17:39:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 17:39:40 GMT
Subject: RFR: 8342206: Convenience method to check if a ClassEntry matches a
 ClassDesc
Message-ID: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>

Currently, to efficiently check if a `ClassEntry`, such as one from an `InvokeInstruction`, is of a particular class, we use such a pattern (as seen in JEP 486 [Appendix](https://openjdk.org/jeps/486#Appendix)):

inst.owner().name().equalsString("java/lang/System")

This pattern has a few issues:

1. This is not straightforward. Users may be tempted to write

inst.owner().asSymbol().equals(CD_System)

unaware of the degraded performance from extra conversions.

2. We aim to reduce the use of "internal names" with encapsulation. Direct use of `"java/lang/System"` goes against this, and we have no constants offered to reduce such error-prone use of internal name.

Thus, I propose a new API in `ClassEntry`:

boolean equalsSymbol(ClassDesc)

that can be used conveniently to check the identity of a class entry with a clean syntax and better performance.

-------------

Commit messages:
 - 8342206: Convenience method to check if a ClassEntry matches a ClassDesc

Changes: https://git.openjdk.org/jdk/pull/21526/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342206
  Stats: 75 lines in 3 files changed: 74 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21526/head:pull/21526

PR: https://git.openjdk.org/jdk/pull/21526

From bpb at openjdk.org  Tue Oct 15 17:47:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 17:47:23 GMT
Subject: RFR: 8341997: Tests create files in src tree instead of scratch
 dir [v2]
In-Reply-To: <lIm3amlrBIt4EyI36GlXw5c94MlkUyZcp6kToQH1F28=.37de75aa-09df-4730-b524-847782a02ebd@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
 <dXh9hScf3FVRniD_VulcSIP5cPJ_PfXt0V1KtOw_dFM=.20a86edb-0aab-4d3b-96d1-1b7680c22bcb@github.com>
 <7BxOJ_7RxJwUSgKteQZDaScU7So75aipJ3IdrVuZxds=.e9a9dd34-6bce-4bb9-b1e5-341d24aa2141@github.com>
 <btMPe3zI6BNHXOgftx7p6SfrSmaQ4FzHHk67OZhSZog=.7d072c29-5d9f-4859-9f9f-f53e018e2d74@github.com>
 <lIm3amlrBIt4EyI36GlXw5c94MlkUyZcp6kToQH1F28=.37de75aa-09df-4730-b524-847782a02ebd@github.com>
Message-ID: <fS7qv7c2m-WS46UF8d2REiPRttIalWGn2tsPC8NHfwE=.bedf9e92-6839-43bd-8f9a-01e300f7e9e4@github.com>

On Tue, 15 Oct 2024 13:06:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Test successful, thanks for fixing this!

Thanks @erikj79 and @jaikiran for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21503#issuecomment-2414642523

From bpb at openjdk.org  Tue Oct 15 17:47:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 17:47:24 GMT
Subject: Integrated: 8341997: Tests create files in src tree instead of scratch
 dir
In-Reply-To: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
References: <VMJb6354-J8MqpThbgPCybuqjKZcqjO55IYa4Y0yGvg=.7dbc47bc-2b1c-4000-9b76-98c71b6e54af@github.com>
Message-ID: <Yl1H5tkHQpGLrppjCYIU-vJFFznCRXjYJiM7rNpPCAs=.18de92fc-e27a-4ef2-bc6a-eb2f45c9bfd9@github.com>

On Mon, 14 Oct 2024 17:37:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change property `test.src` to `test.dir`.

This pull request has now been integrated.

Changeset: b9cabbec
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9cabbecdac27ae8b93df88660a4a0f3f60e6828
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8341997: Tests create files in src tree instead of scratch dir

Reviewed-by: erikj, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/21503

From erikj at openjdk.org  Tue Oct 15 17:52:22 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Oct 2024 17:52:22 GMT
Subject: RFR: 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: <8aC3jj6-F-URh3DOk-64i-0FSHKwpUX7gPAvP70FUnI=.b8b29107-9a65-403f-8292-1613a401a3d3@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...

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370152926

From cjplummer at openjdk.org  Tue Oct 15 17:52:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Oct 2024 17:52:22 GMT
Subject: RFR: 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: <kAgds4PDaZp8jva1ib1vtT7Tcj2kOOf3SbiOkHnYIZE=.2c46f0ff-0a3d-43a7-900e-482ab38f03ce@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...

jdk.jdi and jdk.attach changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370157272

From ihse at openjdk.org  Tue Oct 15 18:15:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:15:29 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v4]
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: <D3K3Urn2nt1Kyz2HbRNRa_Xx0aZqxalBcZ7HJhDyWdc=.cb71273f-7f11-42cd-830f-31587b3ec5b4@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:

  Add lookup asserts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/fc42982f..7fb1b409

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=02-03

  Stats: 8 lines in 1 file changed: 8 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 cay.horstmann at gmail.com  Tue Oct 15 18:19:46 2024
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Tue, 15 Oct 2024 20:19:46 +0200
Subject: [External] : Re: Fw: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <MW4PR10MB57748D537C5EDDE29D7D8837FF452@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <07710471-f249-48dc-bac8-40e00960febe@gmail.com>
 <MW4PR10MB577400AB29878DB7401D3400FF452@MW4PR10MB5774.namprd10.prod.outlook.com>
 <dcb3a05c-f193-46b2-ba2c-6023c0a5c155@gmail.com>
 <MW4PR10MB57748D537C5EDDE29D7D8837FF452@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <60c73cda-183d-4bf3-8e8b-ea6536573ca9@gmail.com>

Thanks Viktor, I like your concept of multiple vantage points a lot.

> Implementor: "use ofGreedy to signal that this operation does not itself initiate short-circuiting"
> Reviewer: "when you see ofGreedy verify that this operation does not itself initiate short-circuiting"
> Debugger: "when the expectation was that the stream should be short-circuiting and isn't, one thing to look for is ofGreedy"
> 
> Implementor: "use ofSequential to signal that this operation is intended to always be executed sequentially"
> Reviewer: "when you see ofSequential, understand why the operation can't/shouldn't be parallelized for parallel streams"
> Debugger: "if the parallel stream is not performing as well as expected, one thing to look for is ofSequential!

I just don't see how these scenarios are parallel. To me, the following  would be parallel.

Scenario I: Brag about better performance

As implementor, I can always go the easy route with of/of: sequential, non-greedy. It'll work, but performance may suffer. Or I can assert that I have done the extra care: ofParallel/ofGreedy.

As reviewer, I see the deluxe ofParallel/ofGreedy, and I verify that the operation enables parallel execution/doesn't short circuit.

As debugger, I see slow performance, and I am not surprised if it's the lame of/of.

Scenario II: Warn of worse performance

As implementor, I aim to produce the most performant way with of/of: parallelizable, greedy. Nice names for the good stuff. If I can't, I'll alert with ofSerial/ofShortCircuit.

As reviewer, I see the coveted of/of, and I verify that the operation enables parallel execution/doesn't short circuit.

As debugger, I see slow performance, and I am not surprised if it is ofSerial/ofShortCircuit. They had it coming.

Either naming pair (ofParallel/ofGreedy or ofSerial/ofShortCircuit) feels consistent to me. But I find of/ofGreedy and ofSerial/of awkward to explain.

Maybe just a mental block on my side. If other programmers worked with the API and found it consistent, don't mind me. I just thought to bring it up in case this has not received a lot of scrutiny. It is a pretty specialized aspect, after all.

Cheers,

Cay

PS. I also think it would be helpful to be more explicit in the javadoc about the value of exploiting greediness. What is the sweet spot? Recognizing that nothing in the pipeline is short-circuiting and then pushing elements through without checking? Or more aggressive parallelization?

I looked at the source code of Gatherer/Gatherers/GathererOp, and it is not obvious to me how one can see a significant performance win with greediness. Can you recommend a benchmark for me to study?

-- 

Cay S. Horstmann | https://horstmann.com


From ihse at openjdk.org  Tue Oct 15 18:42:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:42:28 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
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: <WOVoDcj-l7xzbL3Pj7r6eTtboY3htPzKv119r6TU45M=.9891a72b-fe0a-44c5-aa92-d9233d69e147@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:

  Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/7fb1b409..7286bff4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 4 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  Tue Oct 15 18:42:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:42:28 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <WfweadNY7uFR6FfVedxH7wIXrPZvwgtIo9evDUkfwZc=.39943e16-32d8-43a1-b55a-f1f7eca540c6@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <WfweadNY7uFR6FfVedxH7wIXrPZvwgtIo9evDUkfwZc=.39943e16-32d8-43a1-b55a-f1f7eca540c6@github.com>
Message-ID: <7M4W1dnpgzpFBoFp6r6dTyvHBHVCQl79hfmiYyTPMJE=.40923564-7d2b-406c-b12b-810fa630698e@github.com>

On Thu, 5 Sep 2024 00:15:35 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>
> src/java.base/unix/native/libjli/java_md.c line 509:
> 
>> 507: 
>> 508:     if (GetApplicationHome(path, pathsize)) {
>> 509:         if (JLI_IsStaticallyLinked()) {
> 
> `GetJREPath()` does not need to be called for the static case. Any reason why this path is executed for static mode?

I guess this is parts of my initial attempt to get the static launcher to work on macOS. I agree that it should not be needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801727521

From ihse at openjdk.org  Tue Oct 15 18:42:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:42:28 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <1XTLQONTqkE6n6BTX2KzIngNeewtx5F-cHqvHw7Bk4U=.ded8a4e8-e3e4-414a-afc1-9c694bcb9182@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <1XTLQONTqkE6n6BTX2KzIngNeewtx5F-cHqvHw7Bk4U=.ded8a4e8-e3e4-414a-afc1-9c694bcb9182@github.com>
Message-ID: <romgauTwbdM86X19_lNqJml8YpKPsmkt4qxaYz8NuhE=.d780e443-ad16-4770-b270-e6b1f4d83cfe@github.com>

On Thu, 5 Sep 2024 10:17:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>
> src/java.base/unix/native/libjli/java_md.c line 509:
> 
>> 507: 
>> 508:     if (GetApplicationHome(path, pathsize)) {
>> 509:         if (JLI_IsStaticallyLinked()) {
> 
> In passing, GetJREPath's function description includes "or registry settings" which is confusing to see now.

I updated the description.

Also, the name "JRE" is severly outdated, but cleaning out technical debt in the JLI library will have to wait for another day.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801728335

From coleenp at openjdk.org  Tue Oct 15 18:51:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Oct 2024 18:51:28 GMT
Subject: RFR: 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: <fedkR8waMXM0YzqN0-EynQLWQ03lqgpylDzmPbAXOP0=.a774e759-073e-4e77-85de-49c69acf4904@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...

HotSpot changes look great.  Will clean out the rest in [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370289526

From naoto at openjdk.org  Tue Oct 15 18:51:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Oct 2024 18:51:29 GMT
Subject: RFR: 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: <4WtQzf1WGGjNSzOuxPNvYOub8uuVyYhaad13b4RfMDI=.d7e704b1-68af-4ddd-b221-77b76c179f98@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 is a great work! I looked through the following areas that relate to i18n/charset/console/javatime, and they all look good to me.

src/java.base/share/classes/java/util/Locale.java
src/java.base/share/classes/java/util/ResourceBundle.java
src/java.base/share/classes/java/util/TimeZone.java
src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java

test/jdk/java/io/Console/
test/jdk/java/nio/charset/spi/
test/jdk/java/time/nontestng/java/time/chrono/
test/jdk/java/util/PluggableLocale/
test/jdk/java/util/ResourceBundle/
test/jdk/java/util/TimeZone/
test/jdk/java/util/spi/ResourceBundleControlProvider/
test/jdk/sun/nio/cs/
test/jdk/sun/util/locale/provider/

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370292817

From ihse at openjdk.org  Tue Oct 15 18:53:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 18:53:15 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <d1amVzHP2IX0PFufkHNm7W4_vRy6U_JSBJg6yXOAp5g=.49e079ba-42d2-4d8a-b3b9-224996db2ef0@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>
Message-ID: <OYtzjDOsfGW4aH2apZYeRIodfhVOygYCJG2f8yqwLG8=.904c30ae-5778-4f51-a249-c5e81f6e7316@github.com>

On Thu, 5 Sep 2024 20:41:35 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> You are right, this is dead code. Thanks for spotting this. 
>> 
>> During my experimentation, I tried passing along LDFLAGS from the individual libraries as well, but it turned out not to be a good idea -- the way we have used them were to modify some special properties on a single dynamic library, which did not apply to the static library as a whole.
>> 
>> However, there is a risk that we in the future need to add LDFLAGS to a library that also needs to be carried over to the static launcher. If this happens, I guess we need to separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING.
>
> +1 on "separate between LDFLAGS_ONLY_FOR_THIS_DLL and LDFLAGS_ALSO_FOR_STATIC_LINKING"
> 
> I think we need to get the linker flags sorted out correctly in this initial PR and make sure the needed flags (most importantly the ones used in $JVM_LDFLAGS).

After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801756571

From jiangli at openjdk.org  Tue Oct 15 19:02:11 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 15 Oct 2024 19:02:11 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v5]
In-Reply-To: <OYtzjDOsfGW4aH2apZYeRIodfhVOygYCJG2f8yqwLG8=.904c30ae-5778-4f51-a249-c5e81f6e7316@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>
Message-ID: <vMfVw435X4Ib8xTY7T938WIiBKPMCSa6k7n0-H7KpzU=.6c96e323-f40b-4791-932e-31645e2149a4@github.com>

On Tue, 15 Oct 2024 18:50:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.

@magicus, just to make it clear, do you plan to explicitly define the set of LDFLAGS for static linking as part of this PR? We need to make sure the JVM_LDFLAGS is properly included initially.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801767849

From heidinga at openjdk.org  Tue Oct 15 19:11:14 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 15 Oct 2024 19:11:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
Message-ID: <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>

On Sun, 13 Oct 2024 21:07:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes

src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 235:

> 233: }
> 234: 
> 235: // TODO -- is this really correct? Do we need a special ClassLoaderData for each hidden class?

There are multiple kinds of hidden classes: 
* default ones which can be unloaded immediately when no longer referenced
* MHs.Lookup.ClassOption::STRONG which are associated with their defining loader and can only be unloaded when that loader is unloaded.

I think we need special ClassLoaderData for the non-strong (default) hidden classes

src/hotspot/share/cds/archiveUtils.cpp line 377:

> 375:   if (SystemDictionaryShared::is_excluded_class(src_ik)) {
> 376:     return false;
> 377:   }

Do we want an assert here that `ArchiveBuilder::current()->get_buffered_addr(src_ik)->has_aot_initialized_mirror() == false`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1799752753
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1799755064

From heidinga at openjdk.org  Tue Oct 15 19:11:19 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 15 Oct 2024 19:11:19 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
Message-ID: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>

On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>  - Limit the use of AOTHolder
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

src/hotspot/share/cds/heapShared.cpp line 457:

> 455:   if (HeapShared::is_archivable_hidden_klass(ik)) {
> 456:     // We can't rerun the <clinit> method of hidden classes as we don't save
> 457:     // the classData, so we must archive its mirror in initialized state.

Is this comment still accurate?  It looks like we do save the class_data on line 506

src/hotspot/share/cds/heapShared.cpp line 1140:

> 1138:       return false;
> 1139:     }
> 1140:   }

This is conservatively correct in that it checks all implemented interfaces.  We could be less conservative and only check interfaces that have a "non-abstract non-static" (aka default) method as those are the interfaces that will be initialized along with the class as per JVMS 5.5

src/hotspot/share/cds/metaspaceShared.cpp line 873:

> 871:       Symbol* method_sig = vmSymbols::void_method_signature();
> 872:       JavaCalls::call_static(&result, vmClasses::Class_klass(),
> 873:                              method_name, method_sig, CHECK);

Is this a good candidate for a `runtimeResolve` helper method?  Can we roll it into the same mechanism as the other `runtimeResolve` classes use?

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 599:

> 597: 
> 598:     /** Number of CPUS, to place bounds on some sizings */
> 599:     static @Stable int NCPU;

I would prefer to not mark this `@Stable` at this time as it would have different assembly and runtime values and instead add a followup RFE to investigate adding it in later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801391257
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801410321
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801597570
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801777860

From ihse at openjdk.org  Tue Oct 15 19:31:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 19:31:48 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v6]
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: <saXCPxxQ35xy2XiF3jMgKaF_akmhTOnTm3B2Oynj4DI=.458fbf88-f0d9-4046-b524-7e281c60a46e@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:

  Setup LDFLAGS_STATIC_JDK

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/7286bff4..53ae4779

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=04-05

  Stats: 16 lines in 5 files changed: 13 ins; 0 del; 3 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  Tue Oct 15 19:34:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 19:34:14 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v6]
In-Reply-To: <vMfVw435X4Ib8xTY7T938WIiBKPMCSa6k7n0-H7KpzU=.6c96e323-f40b-4791-932e-31645e2149a4@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>
Message-ID: <2PNXRviwavdaWvhjoHUOC8iwQzeF7zub2JoHjfj9wiI=.f502c575-ffc7-4570-891e-4c61b89c1cf4@github.com>

On Tue, 15 Oct 2024 18:59:32 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.
>
>> After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.
> 
> @magicus, just to make it clear, do you plan to explicitly define the set of LDFLAGS for static linking as part of this PR? We need to make sure the JVM_LDFLAGS is properly included initially.

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1801804046

From iklam at openjdk.org  Tue Oct 15 19:35:16 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 19:35:16 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
Message-ID: <pgNVGyhN6uSCgipzMJeUoJd0BMJnb9qa-7Hpn6EWz6M=.8d294031-08a7-4450-a7af-1f46bb159436@github.com>

On Tue, 15 Oct 2024 19:08:20 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 599:
> 
>> 597: 
>> 598:     /** Number of CPUS, to place bounds on some sizings */
>> 599:     static @Stable int NCPU;
> 
> I would prefer to not mark this `@Stable` at this time as it would have different assembly and runtime values and instead add a followup RFE to investigate adding it in later.

We have been archiving `ConcurrentHashMap` objects for many JDK releases (to support archiving of modules) and `NCPU` would change between CDS archive dump time and program run time. We have not seen any problems, so I think it's safe to use the `@Stable` annotation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801804442

From mchung at openjdk.org  Tue Oct 15 19:36:24 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 15 Oct 2024 19:36:24 GMT
Subject: RFR: 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: <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@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...

Source changes in `java.base/java/lang/**`, `java.management`, and `jdk.management` module look good.  Also hotspot change.

src/java.base/share/classes/java/lang/SecurityManager.java line 72:

> 70:     private static class StackWalkerHolder {
> 71:         static final StackWalker STACK_WALKER =
> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);

Suggestion:

            StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));


Method info is not needed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370337536
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801781277

From psandoz at openjdk.org  Tue Oct 15 19:43:24 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 19:43:24 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
Message-ID: <E_NmeXkYvphAUlV9ab5g0NGuFkkW0FyyYRIgV-X8zuo=.e729a2bf-e5c9-4cec-92b7-539125e2eb67@github.com>

On Sun, 13 Oct 2024 09:57:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update adlc changes.

The compiler test `test/hotspot/jtreg/compiler/vectorapi/VectorCompareWithZeroTest.java` fails to compile and needs to update to use the renamed constants (`UNSIGNED_GT` -> `UGT` and `UNSIGNED_GE` -> `UGE`). This test is only compiled and run on aarch64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2414859793

From liach at openjdk.org  Tue Oct 15 19:45:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 19:45:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
Message-ID: <XVzsnY9pNVOn-p6DILd10hZz5_kA0kGfyMJRGD-k6qQ=.087aba1f-6291-422c-ae1c-84da9d90495e@github.com>

On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>  - Limit the use of AOTHolder
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

I recommend adding javadoc or block comments indicating that `runtimeSetup`, `resetArchivedStates`, etc. are called by VM CDS code so people don't accidentally rename this and have unintended impact.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2414863856

From stefank at openjdk.org  Tue Oct 15 19:45:15 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 15 Oct 2024 19:45:15 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
Message-ID: <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>

On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>  - Limit the use of AOTHolder
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

src/hotspot/share/memory/iterator.inline.hpp line 53:

> 51:     // class has not yet been loaded by CDS.
> 52:     cld->oops_do(this, _claim);
> 53:   }

Could you show the stack trace for this? I want to understand better why we are iterating over objects that don't have a loaded class.

src/hotspot/share/oops/cpCache.cpp line 52:

> 50: #include "oops/objArrayOop.inline.hpp"
> 51: #include "oops/oop.inline.hpp"
> 52: #include "oops/method.inline.hpp"

Could you go over the entire patch and fix sort order of added includes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801811576
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801813265

From liach at openjdk.org  Tue Oct 15 19:54:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 19:54:15 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
Message-ID: <OtkZfudYN1NRi5p6PHHj53UcVz247butMciqvzKEjko=.09bace39-def8-4d56-9955-9ab97f81b4ce@github.com>

On Tue, 15 Oct 2024 05:21:53 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>  - Limit the use of AOTHolder
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4

src/java.base/share/classes/java/lang/invoke/MethodType.java line 404:

> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
> 403:         if (archivedMethodTypes != null) {
> 404:             MethodType mt = archivedMethodTypes.get(primordialMT);

The use of `HashMap` naturally feels alarming given this method is invoked in a concurrent context. I just want to make sure that:

1. `HashMap` will never have structural modifications when read access is performed (some data structures like treap do). Don't know if we have a test to verify such an intended usage, as we would hurt badly if this implied property suddenly no longer exist.
2. The `archivedMethodTypes` must be properly published so we won't read a partial `HashMap`. I've heard of talks about concurrent VM bootstraping so I need some help to understand how this is ensured in bootstrap.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1801825750

From ihse at openjdk.org  Tue Oct 15 20:22:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 20:22:52 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
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: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@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:

  Don't hardcode server variant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/53ae4779..03cd9171

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 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 simonis at openjdk.org  Tue Oct 15 20:32:14 2024
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 15 Oct 2024 20:32:14 GMT
Subject: RFR: 8341944: The zlib library no longer requires dummy byte for
 raw inflate [v2]
In-Reply-To: <QoTT4a34dBIlopSlvARhtQPscwqM9Jp1TJO2X13Ri0Q=.d0fcdf31-852c-4c62-ba75-7ea4bf6b1a77@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
 <QoTT4a34dBIlopSlvARhtQPscwqM9Jp1TJO2X13Ri0Q=.d0fcdf31-852c-4c62-ba75-7ea4bf6b1a77@github.com>
Message-ID: <ChRHcQ27OPqb07AP3_cwOgN9j78YQMZD-_jTbE8IjTs=.e0cfc119-47f6-40cc-b517-9ee81c0cf3ed@github.com>

On Fri, 11 Oct 2024 15:16:50 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
>> 
>> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
>> 
>> 
>> // Override fill() method to provide an extra "dummy" byte
>> // at the end of the input stream. This is required when
>> // using the "nowrap" Inflater option.
>> protected void fill() throws IOException {
>> 
>> However, zlib has not required such an extra dummy byte since 2003. 
>> 
>> 
>> Changes in 1.2.0 (9 March 2003)
>> - New and improved inflate code
>>     - Raw inflate no longer needs an extra dummy byte at end
>> ``` 
>> 
>> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
>> 
>> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
>> 
>> Testing: ZIP and ZIPFS tests run green locally. GHA also green. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Inflater and Deflater constructors taking 'nowrap' options to explain more clearly what this option does

>From the zlib-based libraries I've used ([zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib), [zlib-cloudflare](https://github.com/cloudflare/zlib.git), [zlib-jkukunas](https://github.com/jtkukunas/zlib), and [zlib-ng](https://github.com/zlib-ng/zlib-ng.git)), none of them is based on a version earlier than 1.2.0 of [zlib-madler](https://github.com/madler/zlib.git). [zlib-cloudflare](https://github.com/cloudflare/zlib.git) is based on 1.2.8 and [zlib-ng](https://github.com/zlib-ng/zlib-ng.git) was forked from the original zlib 1.2.11, all others are based (or have integrated) at least 1.2.12

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21467#issuecomment-2414951312

From duke at openjdk.org  Tue Oct 15 20:35:57 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 15 Oct 2024 20:35:57 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v47]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <ZIxihyAJ48XZSYwgrWq07HjGN1kiaGn8vBA9VIAuDCo=.9ba813be-9457-41a4-b4b8-bd0de3bf3c16@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refining the loop invariant for more clear proof

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/e91ebe83..929d0abe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=45-46

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From liach at openjdk.org  Tue Oct 15 20:42:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 20:42:12 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v8]
In-Reply-To: <ew24DuvX35iwH5D8e9NkB8EHjP9X6syl7sIci23CW6g=.26a35da7-3476-4167-82c5-8446229aa757@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <ew24DuvX35iwH5D8e9NkB8EHjP9X6syl7sIci23CW6g=.26a35da7-3476-4167-82c5-8446229aa757@github.com>
Message-ID: <nSHXDcgI9ih2diLKlY2gFxDQRaPD9gM__wZn55WrlKM=.e00cca8d-63b6-4a66-8ed7-889a90895334@github.com>

On Tue, 15 Oct 2024 05:16:58 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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:
> 
>  - reviews from @iwanowww and @rose00 -- move USE_SOFT_CACHE to MethodHandleNatives as a @Stable field; use system prop for init
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/f800b2f5...e46b910a

The updated version using MH natives flag looks good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21049#pullrequestreview-2370565001

From psandoz at openjdk.org  Tue Oct 15 21:00:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 21:00:17 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <KwhtqYMZBBM1679bPfCjqPraxUCe_1XKqRDmSL6iDmY=.42f7e0b6-e2bb-42a8-a1c2-27c27603653e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
 <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>
 <KwhtqYMZBBM1679bPfCjqPraxUCe_1XKqRDmSL6iDmY=.42f7e0b6-e2bb-42a8-a1c2-27c27603653e@github.com>
Message-ID: <PeHpp7eJFyoOLEJuDfHPoZMJ3IsTtoAYvBrkAjHcnT4=.18a889e2-4bbf-4773-bda8-9027471ab79e@github.com>

On Tue, 15 Oct 2024 16:03:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > I gave it a quick scan, and I have no further comments. LGTM.
> 
> Thank you, i will kick off an internal test.

Tier 1 to 3 tests pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2415121395

From psandoz at openjdk.org  Tue Oct 15 21:00:25 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 21:00:25 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v23]
In-Reply-To: <jmWdAoq1BA3K6a_aoM8VLfW7SMyEzxtzUGWGFEJlvhE=.e83433ed-bfcb-40b1-b019-ddb36431b9a6@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <0LkBvvNPq5jmWfOdjItIXGedRDtpiivJM06BAx7vP0I=.c5417544-edef-4623-beaa-08cd7c565361@github.com>
 <cnD4QSr1n6ntVhACh9F9j3OF7_VB8wi7EFD-ZrSwYjE=.fc684c7f-b72c-4738-a5a8-7dda07910f57@github.com>
 <jmWdAoq1BA3K6a_aoM8VLfW7SMyEzxtzUGWGFEJlvhE=.e83433ed-bfcb-40b1-b019-ddb36431b9a6@github.com>
Message-ID: <K7F0Rz8uY0YSYOJZW07k5Of9i6Ghqn3BfiYDtgWa2B0=.62b3a26e-2c71-4c60-a84d-2d5d03b643d3@github.com>

On Tue, 15 Oct 2024 16:39:57 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > Hi @vnkozlov , Can you kindly run this through your test infrastructure. We have two review approvals for Java and x86 backend code.
> 
> I have kicked off some internal tests (FYI @vnkozlov)

Tier 1 to 3 test past, except for the trivial source compilation error previously mentioned.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2415124207

From amenkov at openjdk.org  Tue Oct 15 21:24:12 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Oct 2024 21:24:12 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

src/hotspot/share/prims/jvmtiEnvBase.cpp line 692:

> 690:   if (jt->is_in_VTMS_transition()) {
> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
> 692:   } else if (is_virtual) { // filter out pure continuations

Not sure I follow the logic here.
As far as I understand yield/yield need to be filtered out only for unmounted virtual threads. But `is_virtual` here means we have mounted VT?
Looks like almost all callers call this method only if `jt->is_in_JTMS_transilition()` is true
Exception is a call from `get_vthread_jvf()` when vthread is mounted.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 703:

> 701:   if (java_lang_VirtualThread::is_instance(vthread)) { // paranoid check for safety
> 702:     if (java_lang_Thread::is_in_VTMS_transition(vthread)) {
> 703:       jvf = check_and_skip_hidden_frames(java_lang_Thread::is_in_VTMS_transition(vthread), jvf);

it's just checked that `java_lang_Thread::is_in_VTMS_transition(vthread)` is true
Suggestion:

      jvf = check_and_skip_hidden_frames(true, jvf);

src/hotspot/share/prims/jvmtiEnvBase.cpp line 2025:

> 2023:   // - it is a good invariant when a thread's handshake can't be impacted by a VTMS transition
> 2024:   // - there is no mechanism to disable transitions of a specific carrier thread yet
> 2025:   JvmtiVTMSTransitionDisabler disabler(is_virtual ? target : nullptr); // nullptr is to disable all

We have a number of places with the same issue - `JvmtiVTMSTransitionDisabler disabler(target)` when target thread can be virtual or platform.
I think they need to be fixed all together (and most likely as a separate issue).
Maybe it would be better to fix disabler itself (check if the thread provided is platform and disable transitions for all threads in the case). Then there is no need to update all this places when (if) disabling for single platform thread is implemented

src/hotspot/share/prims/jvmtiExport.cpp line 1814:

> 1812:   }
> 1813:   // pure continuations have no VTMS transitions but they use methods annotated with JvmtiMountTransition
> 1814:   if ((mh->jvmti_mount_transition() && state->is_virtual()) || thread->is_in_any_VTMS_transition()) {

Could you please explain the change (and other similar changes in jvmtiExport.cpp)
Before events were not posted for any `@JvmtiMountTransition` methods, and now only for virtual threads? I.e. events for `@JvmtiMountTransition` methods of carrier threads are posted?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1801933054
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1801953309
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1801992736
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802034030

From amenkov at openjdk.org  Tue Oct 15 21:31:11 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Oct 2024 21:31:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

src/hotspot/share/prims/jvmtiEnvBase.cpp line 588:

> 586:   // There should not be any VTMS transition here. This is for safety.
> 587:   if (java_thread->is_in_VTMS_transition()) {
> 588:     jvf = JvmtiEnvBase::check_and_skip_hidden_frames(java_thread, jvf);

The code now checks `java_thread->is_in_VTMS_transition()`, so it may be simplified to
Suggestion:

    jvf = JvmtiEnvBase::check_and_skip_hidden_frames(true, jvf);

src/hotspot/share/prims/jvmtiEnvBase.cpp line 691:

> 689: 
> 690:   if (jt->is_in_VTMS_transition()) {
> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);

Suggestion:

    jvf = check_and_skip_hidden_frames(true, jvf);

src/hotspot/share/prims/jvmtiEnvBase.cpp line 753:

> 751:     // Skip hidden frames only for carrier threads
> 752:     // which are in non-temporary VTMS transition.
> 753:     jvf = check_and_skip_hidden_frames(jt, jvf);

Can be
Suggestion:

    jvf = check_and_skip_hidden_frames(true, jvf);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802038615
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802039013
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802039786

From prr at openjdk.org  Tue Oct 15 21:39:19 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Oct 2024 21:39:19 GMT
Subject: RFR: 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: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@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...

I have looked at the source code changes in java.desktop
They are mostly OK.
I have noted text that was removed in two places in java.awt.Robot where the removal should be reverted.
I have also "grepped" the sandbox repo to identify any errors of omission - pertaining to the SE API specification, not internals - and found none.

I also noted a couple of Permission classes we should deprecate - and filed bugs on them.

I have not yet examined any of the test updates. That looks like a big job.

src/java.desktop/share/classes/java/awt/AWTPermission.java line 39:

> 37:  * @apiNote
> 38:  * This permission cannot be used for controlling access to resources anymore
> 39:  * as the Security Manager is no longer supported.

After this JEP is integrated, I expect to deprecate AWTPermission, probably for removal

src/java.desktop/share/classes/java/awt/Robot.java line 433:

> 431:      * then a {@code SecurityException} may be thrown,
> 432:      * or the content of the returned {@code Color} is undefined.
> 433:      * </p>

This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

src/java.desktop/share/classes/java/awt/Robot.java line 460:

> 458:      * then a {@code SecurityException} may be thrown,
> 459:      * or the contents of the returned {@code BufferedImage} are undefined.
> 460:      * </p>

This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java line 36:

> 34:  * actions list; you either have the named permission or you don't.
> 35:  * <p>
> 36:  * The target name is the name of the audio permission.

AudioPermission is another class we should deprecate

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370309133
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801765010
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802031119
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802031524
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802042388

From psandoz at openjdk.org  Tue Oct 15 21:40:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 15 Oct 2024 21:40:20 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
 <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
Message-ID: <NOT5_LOX5SjoqP9LDMBfBRP3WAYKXaDekzBG88wJ0L4=.75dcd6ec-20e5-4fc3-bd80-cb9c4430d470@github.com>

On Tue, 15 Oct 2024 10:19:46 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Are there any IR rules that verify that the correct C2 nodes are used? Is that a thing you generally do with the VectorAPI, just to make sure things get correctly intrinsified?

Not systematically. We have some IR testing for more complex areas, located under `test/hotspot/jtreg/compiler/vectorapi/`. When we started out testing there was no IR testing framework so we relied on classic unit tests running a test N times for C2 to kick in. That is still the case for the majority of tests. It would be nice to have a better balance, and a way to systematically generate IR tests for the various vector operations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2415212261

From sspitsyn at openjdk.org  Tue Oct 15 21:51:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 21:51:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
Message-ID: <KaZBUUtqWTjaGcvFnXyEuJO85tCBvV8DSLh7URWia-M=.98488481-7bf7-41fd-80f1-5ca91cbb092d@github.com>

On Tue, 15 Oct 2024 20:45:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 703:
> 
>> 701:   if (java_lang_VirtualThread::is_instance(vthread)) { // paranoid check for safety
>> 702:     if (java_lang_Thread::is_in_VTMS_transition(vthread)) {
>> 703:       jvf = check_and_skip_hidden_frames(java_lang_Thread::is_in_VTMS_transition(vthread), jvf);
> 
> it's just checked that `java_lang_Thread::is_in_VTMS_transition(vthread)` is true
> Suggestion:
> 
>       jvf = check_and_skip_hidden_frames(true, jvf);

Good catch, thanks. Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802057401

From sspitsyn at openjdk.org  Tue Oct 15 22:02:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 22:02:12 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
Message-ID: <ZRUxgwPVnJGTEpvUCRz_sR-b6-LcnJeK5cl_bo9037M=.84eca85d-a9a3-4a2d-ba95-8c8bfa56a241@github.com>

On Tue, 15 Oct 2024 20:40:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 692:
> 
>> 690:   if (jt->is_in_VTMS_transition()) {
>> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
>> 692:   } else if (is_virtual) { // filter out pure continuations
> 
> Not sure I follow the logic here.
> As far as I understand yield/yield need to be filtered out only for unmounted virtual threads. But `is_virtual` here means we have mounted VT?
> Looks like almost all callers call this method only if `jt->is_in_JTMS_transilition()` is true
> Exception is a call from `get_vthread_jvf()` when vthread is mounted.

This seems to be a good catch. The call to `skip_top_jvmti_annotated_frames()` should not be needed.
It does not harm either, so I've added it for safety.
Will remove it and rerun mach5 tiers to make sure there is nothing unexpected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802065755

From mullan at openjdk.org  Tue Oct 15 22:12:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:12:26 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>

On Tue, 15 Oct 2024 13:51:18 GMT, Daniel Fuchs <dfuchs 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, ...
>
> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
> 
>> 665:      * @param codesource the codesource
>> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
>> 667:      * @return the permissions for the codesource
> 
> Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?

Yes, I think that is a good suggestion. Let me think about whether it should be done as part of this JEP or if we can do it later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802073264

From sspitsyn at openjdk.org  Tue Oct 15 22:13:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 22:13:12 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
Message-ID: <lvHsBr-2GC7hWJgD3YnI5ItnFb0B6uBoPTiUuzefdPU=.258d189f-fe73-4150-874e-2bc2f026b530@github.com>

On Tue, 15 Oct 2024 20:55:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2025:
> 
>> 2023:   // - it is a good invariant when a thread's handshake can't be impacted by a VTMS transition
>> 2024:   // - there is no mechanism to disable transitions of a specific carrier thread yet
>> 2025:   JvmtiVTMSTransitionDisabler disabler(is_virtual ? target : nullptr); // nullptr is to disable all
> 
> We have a number of places with the same issue - `JvmtiVTMSTransitionDisabler disabler(target)` when target thread can be virtual or platform.
> I think they need to be fixed all together (and most likely as a separate issue).
> Maybe it would be better to fix disabler itself (check if the thread provided is platform and disable transitions for all threads in the case). Then there is no need to update all this places when (if) disabling for single platform thread is implemented

Good suggestion, thanks.
Though, I'd prefer to fix it here, so will prepare a fix in the `JvmtiVTMSTransitionDisabler` constructor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802073959

From mullan at openjdk.org  Tue Oct 15 22:19:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
Message-ID: <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>

On Tue, 15 Oct 2024 19:11:24 GMT, Mandy Chung <mchung 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, ...
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
> 
>> 70:     private static class StackWalkerHolder {
>> 71:         static final StackWalker STACK_WALKER =
>> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> 
> Suggestion:
> 
>             StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));
> 
> 
> Method info is not needed.

Thanks, will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802077370

From mullan at openjdk.org  Tue Oct 15 22:19:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
Message-ID: <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>

On Tue, 15 Oct 2024 21:17:37 GMT, Phil Race <prr 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, ...
>
> src/java.desktop/share/classes/java/awt/Robot.java line 433:
> 
>> 431:      * then a {@code SecurityException} may be thrown,
>> 432:      * or the content of the returned {@code Color} is undefined.
>> 433:      * </p>
> 
> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

Ok, I will revert it.

> src/java.desktop/share/classes/java/awt/Robot.java line 460:
> 
>> 458:      * then a {@code SecurityException} may be thrown,
>> 459:      * or the contents of the returned {@code BufferedImage} are undefined.
>> 460:      * </p>
> 
> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

Ok, I will revert it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802077916
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802078111

From mullan at openjdk.org  Tue Oct 15 22:19:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>

On Tue, 15 Oct 2024 15:01:00 GMT, Daniel Fuchs <dfuchs 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, ...
>
> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:
> 
>> 223:      *
>> 224:      * @exception SecurityException if the connection cannot be made
>> 225:      * for security reasons.
> 
> I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.

Yes, good catches, I will revert some of these JMX methods that can also throw SecurityExceptions for non-SM reasons.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802076052

From bpb at openjdk.org  Tue Oct 15 22:37:26 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Oct 2024 22:37:26 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 8233451: Remove use of handleAvailable() (Windows)
 - 8233451: Remove use of handleAvailable() (UNIX)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/235182fb..51df5d81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=00-01

  Stats: 53 lines in 5 files changed: 41 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

PR: https://git.openjdk.org/jdk/pull/21508

From iklam at openjdk.org  Wed Oct 16 00:00:19 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 00:00:19 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v7]
In-Reply-To: <yvJd3RW9yaLG_JKkwISGAIk7IrN67Ah-JgSnxjdQJE4=.4ed0e67a-0e63-48d1-94bc-bc8f0747aa23@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <reXfHAV2mvKsC13Nn9xBJ89q-L70sIXDIQL3XVbeFAc=.04d935f8-048a-4219-849e-d88a79381926@github.com>
 <yvJd3RW9yaLG_JKkwISGAIk7IrN67Ah-JgSnxjdQJE4=.4ed0e67a-0e63-48d1-94bc-bc8f0747aa23@github.com>
Message-ID: <bfo6HtA9KqyAwA9KWOushoTkpUFUWYK2sZWyLaqnPEo=.2e8c4fe3-832a-479a-b5b1-d18ad9d68f72@github.com>

On Wed, 2 Oct 2024 23:08:52 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Ioi Lam 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 branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - @liach and @cl4es comments
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - @dholmes-ora review comments
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - Do not use system property to limit usage to only CDS static dumps
>>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/222ada2d...1b067b7b
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java line 92:
> 
>> 90:         CUSTOMIZE_THRESHOLD = Integer.parseInt(
>> 91:                 props.getProperty("java.lang.invoke.MethodHandle.CUSTOMIZE_THRESHOLD", "127"));
>> 92:         NO_SOFT_CACHE = CDS.disableMethodHandleSoftCache();
> 
> I suggest to use `CDS.disableMethodHandleSoftCache()` as the default and allow to override the mode through a property.
> 
> 
> NO_SOFT_CACHE = Boolean.parseBoolean( 
>         props.getProperty("java.lang.invoke.MethodHandle.NO_SOFT_CACHE", 
>                                         Boolean.toString(CDS.disableMethodHandleSoftCache()));

After further offline discussion with @iwanowww, I have reverted back to the system property as suggested.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1802141804

From iklam at openjdk.org  Wed Oct 16 00:03:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 00:03:25 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v9]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <qJE1LA6Oe5e7nsAnMmNVdB7uI3_O8x1znkkCsUxjvGc=.971ca044-0168-4163-ba9a-b767104ae8f3@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 16 additional commits since the last revision:

 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - reviews from @iwanowww and @rose00 -- move USE_SOFT_CACHE to MethodHandleNatives as a @Stable field; use system prop for init
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @liach and @cl4es comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @dholmes-ora review comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - ... and 6 more: https://git.openjdk.org/jdk/compare/8224abfb...11391c39

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/e46b910a..11391c39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From duke at openjdk.org  Wed Oct 16 00:33:11 2024
From: duke at openjdk.org (duke)
Date: Wed, 16 Oct 2024 00:33:11 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
Message-ID: <e2gchFatbW9X_U_2vm9YNNEuZnfNTiM1mvQQtwbq1u8=.32823d67-a697-4341-8b94-aa09e7abfa81@github.com>

On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
>> 
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checking if time is monotonic

@rsunderbabu 
Your change (at version 8a96311072409441f4c289c6798f65ab6fc2534f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21413#issuecomment-2415394872

From tprinzing at openjdk.org  Wed Oct 16 01:24:53 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 16 Oct 2024 01:24:53 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
Message-ID: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>

Adds a JFR event for socket connect operations.

Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

-------------

Commit messages:
 - fix default settings
 - fix merge
 - Merge branch 'master' into JDK-8310996
 - added tests and support for sockets.
 - 8310996: Add JFR event for connect operations

Changes: https://git.openjdk.org/jdk/pull/21528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310996
  Stats: 247 lines in 12 files changed: 236 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

PR: https://git.openjdk.org/jdk/pull/21528

From iklam at openjdk.org  Wed Oct 16 01:26:45 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 01:26:45 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v6]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <XrqQBGf40sQ0Ytxj2TLd_2Jf1YyTFvF4qiIJTnmyoSs=.9862390d-cb74-4bb6-a961-d3e799606206@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - @DanHeidinga comments -- added comments and asserts related to ClassLoaderData used by archived hidden classes
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
 - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
 - @adinn comments
 - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
 - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - ... and 21 more: https://git.openjdk.org/jdk/compare/11391c39...a6ad908f

-------------

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=05
  Stats: 2216 lines in 64 files changed: 1972 ins; 103 del; 141 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Wed Oct 16 01:29:12 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 01:29:12 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
Message-ID: <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>

On Mon, 14 Oct 2024 15:52:07 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 JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>
> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 235:
> 
>> 233: }
>> 234: 
>> 235: // TODO -- is this really correct? Do we need a special ClassLoaderData for each hidden class?
> 
> There are multiple kinds of hidden classes: 
> * default ones which can be unloaded immediately when no longer referenced
> * MHs.Lookup.ClassOption::STRONG which are associated with their defining loader and can only be unloaded when that loader is unloaded.
> 
> I think we need special ClassLoaderData for the non-strong (default) hidden classes

We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've added a comment and tightened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1802208841

From dholmes at openjdk.org  Wed Oct 16 01:33:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 01:33:17 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
Message-ID: <jHZYMj_1R_mRAV_TAft1VW_x71KMn1GRJJDBOIb_OUk=.6cee3aa6-1646-4891-ad05-4466ec3e290a@github.com>

On Thu, 10 Oct 2024 17:54:51 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` launcher, 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 launcher 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:
>> 
>> $ java
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [options...] <what to execute> [arguments to main method...]
>> 
>> Where <what to execute> is one of:
>>   <MainClass>                to execute the main method of a compiled class
>>   -jar <jar-file.jar>        to execute the main class in a JAR archive
>>   -m <module>[/<MainClass>]  to execute the main class of a module
>>   <SourceFile.java>          to compile and execute a single-file program
>> 
>> Where key options include:
>>   --class-path <class path>
>>       a : separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a : separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help based on review suggestions.

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 241:

> 239: \  -jar <jar-file.jar>        to execute the main class in 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 single-file program\n\n\

Suggestion:

\  <SourceFile>.java          to compile and execute a single-file program\n\n\

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1802210431

From dholmes at openjdk.org  Wed Oct 16 01:33:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 01:33:17 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <jHZYMj_1R_mRAV_TAft1VW_x71KMn1GRJJDBOIb_OUk=.6cee3aa6-1646-4891-ad05-4466ec3e290a@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
 <jHZYMj_1R_mRAV_TAft1VW_x71KMn1GRJJDBOIb_OUk=.6cee3aa6-1646-4891-ad05-4466ec3e290a@github.com>
Message-ID: <KYb-F60WzkX0gcRK3h7hOe_K0sAWssE4tMj7yu7ILhs=.a643ebe7-7c94-4009-bfe1-b4e6a996c71d@github.com>

On Wed, 16 Oct 2024 01:29:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusting the concise help based on review suggestions.
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 241:
> 
>> 239: \  -jar <jar-file.jar>        to execute the main class in 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 single-file program\n\n\
> 
> Suggestion:
> 
> \  <SourceFile>.java          to compile and execute a single-file program\n\n\

Or even `<MainClass>.java` to pair with `<MainClass>`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1802210920

From jbhateja at openjdk.org  Wed Oct 16 01:59:18 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 01:59:18 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <PeHpp7eJFyoOLEJuDfHPoZMJ3IsTtoAYvBrkAjHcnT4=.18a889e2-4bbf-4773-bda8-9027471ab79e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
 <odQkIhshSfvocuFgGJt46mm_76HCnQB5zHf0efZYr5o=.11d65cbc-e4c8-47b0-a7d4-33980b9d2790@github.com>
 <KwhtqYMZBBM1679bPfCjqPraxUCe_1XKqRDmSL6iDmY=.42f7e0b6-e2bb-42a8-a1c2-27c27603653e@github.com>
 <PeHpp7eJFyoOLEJuDfHPoZMJ3IsTtoAYvBrkAjHcnT4=.18a889e2-4bbf-4773-bda8-9027471ab79e@github.com>
Message-ID: <ApQGwv8Y0spGjlOYX8tVAsELt-mln6n-cAU3E3koPnw=.52f1f93a-f2c2-4dea-9beb-789ff4707c75@github.com>

On Tue, 15 Oct 2024 20:57:05 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> I gave it a quick scan, and I have no further comments. LGTM.
>> 
>> Thank you, i will kick off an internal test.
>
>> > I gave it a quick scan, and I have no further comments. LGTM.
>> 
>> Thank you, i will kick off an internal test.
> 
> Tier 1 to 3 tests pass.

Thanks @PaulSandoz , @sviswa7 and @eme64 for review suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2415566209

From dholmes at openjdk.org  Wed Oct 16 02:38:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 02:38:11 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v2]
In-Reply-To: <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <wsnaPq1zE2E93yT75PneDemOQzIkohI7GFoPmuXXggg=.847a15c0-acd8-434b-8680-f8c01f19ff56@github.com>
 <2LdVZdSSZi0waMjGwk1hS01IxNwfLjmgSYxLiwZAK-8=.6ab0713c-016b-4be7-91cf-08c0c40f4595@github.com>
Message-ID: <Qi9qqIwp79KMQ7puAEqJEUQQ380EzN0OvJdcx6Pprjc=.e031a9eb-78d5-4caf-b428-84e46863d169@github.com>

On Wed, 2 Oct 2024 20:29:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove ubsan changes from jni_md.h
>
> jni_util.h is used across all modules but it is located in `java.base/share/native/libjava` not `java.base/unix/native/libjava`. 
> 
> I think you could probably place ub.h along-side jni_util.h in that directory.

> @dholmes-ora are you fine with the latest version ?

Sorry just back from vacation. Noting further from me - header placement seems fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2415603481

From iklam at openjdk.org  Wed Oct 16 02:42:52 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 02:42:52 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed typo in last commit; fixed header inclusion order

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/a6ad908f..4be6a255

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=05-06

  Stats: 38 lines in 15 files changed: 17 ins; 20 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Wed Oct 16 02:42:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 02:42:54 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
Message-ID: <A7SLv__ysUzcQBnxEXOqCyqXz-3-6hXSoCi5706VnxA=.17365c73-7f14-4886-bb27-2503e97ec5c9@github.com>

On Tue, 15 Oct 2024 19:40:15 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/oops/cpCache.cpp line 52:
> 
>> 50: #include "oops/objArrayOop.inline.hpp"
>> 51: #include "oops/oop.inline.hpp"
>> 52: #include "oops/method.inline.hpp"
> 
> Could you go over the entire patch and fix sort order of added includes.

I fixed the include problems found by my script. I'll make sure to run the script again before the final push.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1802252522

From iklam at openjdk.org  Wed Oct 16 03:32:14 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 03:32:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
Message-ID: <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>

On Tue, 15 Oct 2024 19:38:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/memory/iterator.inline.hpp line 53:
> 
>> 51:     // class has not yet been loaded by CDS.
>> 52:     cld->oops_do(this, _claim);
>> 53:   }
> 
> Could you show the stack trace for this? I want to understand better why we are iterating over objects that don't have a loaded class.

Here's the call stack if I remove the "if" check on line 49. It can be reproduced with test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java from the PR repo.


10 javaSignalHandler (sig=11, info=0x7ffff428fdb0, context=0x7ffff428fc80)
12 Atomic::PlatformLoad::operator() (this=0x7ffff429097f, dest=0x28)
13 Atomic::LoadImpl, void>::operator() (this=0x7ffff42909af, dest=0x28)
14 Atomic::load (dest=0x28)
15 ClassLoaderData::try_claim (this=0x0, claim=4)
16 ClassLoaderData::oops_do (this=0x0, f=0x7fff6c014c88, claim_value=4, clear_mod_oops=false)
17 ClaimMetadataVisitingOopIterateClosure::do_cld (this=0x7fff6c014c88, cld=0x0)
18 ClaimMetadataVisitingOopIterateClosure::do_klass (this=0x7fff6c014c88, k=0x7fff763655d8)
19 call_do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
20 Devirtualizer::do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
21 InstanceKlass::oop_oop_iterate (closure=0x7fff6c014c88, obj=0xfffd72a0, this=0x7fff763655d8)
22 OopOopIterateDispatch::Table::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, k=0x7fff763655d8)
23 OopIteratorClosureDispatch::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, klass=0x7fff763655d8)
24 oopDesc::oop_iterate (this=0xfffd72a0, cl=0x7fff6c014c88)
25 G1FullGCMarker::follow_object (this=0x7fff6c014630, obj=0xfffd72a0)
26 G1FullGCMarker::publish_and_drain_oop_tasks (this=0x7fff6c014630)
27 G1FullGCMarker::follow_marking_stacks (this=0x7fff6c014630)
28 G1FullGCMarker::complete_marking (this=0x7fff6c014630, oop_stacks=0x7fffd445c6b8, array_stacks=0x7fffd445c6d0, terminator=0x7fffd445c190)
29 G1FullGCMarkTask::work (this=0x7fffd445c030, worker_id=0)
30 WorkerTaskDispatcher::worker_run_task (this=0x7ffff008b9b8)
31 WorkerThread::run (this=0x7ffff008bac0)


This is in a GC triggered by here (with -XX:VerifyArchivedFields=2).


void HeapShared::init_archived_fields_for(Klass* k, 
     const ArchivedKlassSubGraphInfoRecord* record) {
  verify_the_heap(k, "before");


At frame 18:


#18 0x00007ffff58505d1 in ClaimMetadataVisitingOopIterateClosure::do_klass 
    (this=0x7fff6c014c88, k=0x7fff763655d8)
    at src/hotspot/share/memory/iterator.inline.hpp:58
58	  ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
(gdb) psym k->_name
$1 = 0x7fff765430be "BulkLoaderTestApp$$Lambda+0x800000013"
(gdb) p k->_class_loader_data
$2 = (ClassLoaderData *) 0x0
(gdb) p SystemDictionary::_java_system_loader 
$3 = {_obj = 0x0}


At frame 21:


#21 0x00007ffff6132f6f in InstanceKlass::oop_oop_iterate<narrowOop, G1MarkAndPushClosure> 
    (closure=0x7fff6c014c88, obj=0xfffd72a0, this=0x7fff763655d8)
    at src/hotspot/share/oops/instanceKlass.inline.hpp:164
164	    Devirtualizer::do_klass(closure, this);
(gdb) call pp(obj)
"Executing pp"
BulkLoaderTestApp$$Lambda/0x800000013 
{0x00000000fffd72a0} - klass: 'BulkLoaderTestApp$$Lambda+0x800000013' - flags: is_hidden_class 


The root cause is:

- A lambda has been aot-resolved for a class loaded by the app loader
- There is an instance (`0xfffd72a0`) of the lambda proxy class (`BulkLoaderTestApp$$Lambda+0x800000013`) that represents this call site 
- At the point of failure, all archived heap objects, including `0xfffd72a0`, are reachable (through `HeapShared::_root_segments`).
- However, we are still early in VM bootstrap. The `_java_system_loader` isn't available yet, so we are not yet able to load the lambda proxy class.

Before JEP 483, all archived objects are from java.base, and the `VerifyArchivedFields` code was careful to not trigger a GC until `is_init_completed()` becomes true.

However, with JEP 483, it's possible to have an archived object from the app class loader, and it's legally possible for a GC to happen before the app loader is available. Thus we come into this situation.

(Ping @fisk @coleenp in case you're curious)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1802291536

From jpai at openjdk.org  Wed Oct 16 03:59:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 03:59:14 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <romgauTwbdM86X19_lNqJml8YpKPsmkt4qxaYz8NuhE=.d780e443-ad16-4770-b270-e6b1f4d83cfe@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <1XTLQONTqkE6n6BTX2KzIngNeewtx5F-cHqvHw7Bk4U=.ded8a4e8-e3e4-414a-afc1-9c694bcb9182@github.com>
 <romgauTwbdM86X19_lNqJml8YpKPsmkt4qxaYz8NuhE=.d780e443-ad16-4770-b270-e6b1f4d83cfe@github.com>
Message-ID: <AGiQVfr2GLhFDHwfvhfCgDhye46Kk6BDTzZ6wwFdQM8=.deddaa24-e3b6-4523-af3e-6d7802f53a64@github.com>

On Tue, 15 Oct 2024 18:39:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/unix/native/libjli/java_md.c line 509:
>> 
>>> 507: 
>>> 508:     if (GetApplicationHome(path, pathsize)) {
>>> 509:         if (JLI_IsStaticallyLinked()) {
>> 
>> In passing, GetJREPath's function description includes "or registry settings" which is confusing to see now.
>
> I updated the description.
> 
> Also, the name "JRE" is severly outdated, but cleaning out technical debt in the JLI library will have to wait for another day.

Hello Magnus,

> Also, the name "JRE" is severly outdated, but cleaning out technical debt in the JLI library will have to wait for another day.

I have some changes in this launcher area (for clean up) that will show up as PRs in the coming days.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1802309882

From liach at openjdk.org  Wed Oct 16 05:16:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 05:16:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v6]
In-Reply-To: <XrqQBGf40sQ0Ytxj2TLd_2Jf1YyTFvF4qiIJTnmyoSs=.9862390d-cb74-4bb6-a961-d3e799606206@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <XrqQBGf40sQ0Ytxj2TLd_2Jf1YyTFvF4qiIJTnmyoSs=.9862390d-cb74-4bb6-a961-d3e799606206@github.com>
Message-ID: <DB_AbfZbFKp1UoN9RQE0mQzKc6VufflWanWJSqO2v8I=.4b41450e-79af-44f1-9bc6-4e50d927b17c@github.com>

On Wed, 16 Oct 2024 01:26:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - @DanHeidinga comments -- added comments and asserts related to ClassLoaderData used by archived hidden classes
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>  - @adinn comments
>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/11391c39...a6ad908f

src/hotspot/share/cds/heapShared.cpp line 447:

> 445: 
> 446: bool HeapShared::is_string_concat_klass(InstanceKlass* ik) {
> 447:   return ik->is_hidden() && ik->name()->starts_with("java/lang/String$$StringConcat");

Can you add a comment in `StringConcatFactory`'s place where this name is defined, so others who change the generated class name will remember to update references here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1802362899

From jbhateja at openjdk.org  Wed Oct 16 05:36:19 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 05:36:19 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
 <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
Message-ID: <FD2LLtVOCY6Qdeanv6WCxoXYx0EOlOxRE5NFgdu-hUw=.0d770cab-f0fe-49e9-8202-9fcbffd7922c@github.com>

On Tue, 15 Oct 2024 10:17:40 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update adlc changes.
>
> src/hotspot/share/opto/vectornode.hpp line 161:
> 
>> 159:   // Needed for proper cloning.
>> 160:   virtual uint size_of() const { return sizeof(*this); }
>> 161:   bool is_unsigned() { return _is_unsigned; }
> 
> Can you put this in the `print_spec`, so the IR dump shows if it is unsigned?

Hi @eme64 , I see print_spec is mainly used for dumping information about VTransformVectorNode,  please note newly added situating operations are not being auto-vectorized and are are emitted through VectorAPI based explicit vectorization flow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1802382779

From duke at openjdk.org  Wed Oct 16 05:54:10 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 16 Oct 2024 05:54:10 GMT
Subject: RFR: 8342206: Convenience method to check if a ClassEntry matches
 a ClassDesc
In-Reply-To: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
References: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
Message-ID: <8rga5-st0QxAX6qfogf1CCbo_gr9uds7mR9_LEleslI=.a68fdb8c-ce11-485b-b83c-9c11e29c5917@github.com>

On Tue, 15 Oct 2024 17:34:53 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, to efficiently check if a `ClassEntry`, such as one from an `InvokeInstruction`, is of a particular class, we use such a pattern (as seen in JEP 486 [Appendix](https://openjdk.org/jeps/486#Appendix)):
> 
> inst.owner().name().equalsString("java/lang/System")
> 
> This pattern has a few issues:
> 
> 1. This is not straightforward. Users may be tempted to write
> 
> inst.owner().asSymbol().equals(CD_System)
> 
> unaware of the degraded performance from extra conversions.
> 
> 2. We aim to reduce the use of "internal names" with encapsulation. Direct use of `"java/lang/System"` goes against this, and we have no constants offered to reduce such error-prone use of internal name.
> 
> Thus, I propose a new API in `ClassEntry`:
> 
> boolean equalsSymbol(ClassDesc)
> 
> that can be used conveniently to check the identity of a class entry with a clean syntax and better performance.

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 609:

> 607:             var mySym = this.sym;
> 608:             if (mySym != null)
> 609:                 return mySym.equals(symbol);

Note?that `ClassEntry::asSymbol()` also?caches array?`ClassDesc`s in?`ref1.typeSym` so?that the?symbol?cache can?be?shared with?`FieldRefEntry` and?`ConstantDynamicEntry`.

--------------------------------------------------------------------------------

I suggest adding the following check:

if (ref1.typeSym instanceof ClassDesc ref1Sym && ref1Sym.isArray()) {
	return ref1Sym.equals(symbol);
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21526#discussion_r1802394895

From goetz at openjdk.org  Wed Oct 16 06:00:14 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Wed, 16 Oct 2024 06:00:14 GMT
Subject: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
In-Reply-To: <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
 <G1kGxAKd9iBIhPDS7wpRF0jLdA7jRmJvJPZ6XsB7iNg=.afd097d1-4d96-4891-b3f2-560e86063617@github.com>
Message-ID: <zIx2N0I0GMlY3mBaJfmHqr9gWa9zcWwaA_FyLwktAHM=.66749532-b2f6-40b8-aae2-aa57495308b9@github.com>

On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
>> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
>> 
>> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.
>
> Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8340801
>  - move ub.h to a better location
>  - remove ubsan changes from jni_md.h
>  - JDK-8340801

LGTM

-------------

Marked as reviewed by goetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21184#pullrequestreview-2371275207

From dholmes at openjdk.org  Wed Oct 16 06:23:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 06:23:12 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v3]
In-Reply-To: <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>
Message-ID: <_Lz4FqcQaQ7_HhbNu6zM6tVkxlEW2Jy3-69VdGi7KLo=.d04c2358-54ec-49a3-90ea-4fdf4af3c61a@github.com>

On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas 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 tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - Remove XCollectedHeap from HSDB
>  - Fix typo in TestZUncommitEvent.java
>  - Add missing problem-listing
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/5efb98a4...e58b4c5a

I skimmed everything and it seems okay to me.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2371314286

From alanb at openjdk.org  Wed Oct 16 06:31:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 06:31:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
Message-ID: <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>

On Tue, 15 Oct 2024 22:15:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
>> 
>>> 70:     private static class StackWalkerHolder {
>>> 71:         static final StackWalker STACK_WALKER =
>>> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>> 
>> Suggestion:
>> 
>>             StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));
>> 
>> 
>> Method info is not needed.
>
> Thanks, will fix.

SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have not in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802437558

From duke at openjdk.org  Wed Oct 16 06:32:16 2024
From: duke at openjdk.org (duke)
Date: Wed, 16 Oct 2024 06:32:16 GMT
Subject: RFR: 8339637: (tz) Update Timezone Data to 2024b [v4]
In-Reply-To: <Y0scCRnE7CerLHOA2D7r1P7gWD7Tjzhix3wPEiGzidw=.a0b98380-4308-404c-82f7-d798e5ea4522@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
 <Y0scCRnE7CerLHOA2D7r1P7gWD7Tjzhix3wPEiGzidw=.a0b98380-4308-404c-82f7-d798e5ea4522@github.com>
Message-ID: <iRUVVZ_UURlQpUiP579NWoW6emJUfaYWFi_hzwGpeJs=.c04abc71-3a4b-4e17-a8ba-a3e61b16d176@github.com>

On Mon, 14 Oct 2024 04:13:46 GMT, Johny Jose <duke at openjdk.org> wrote:

>> Timezone data 2024b changes
>
> Johny Jose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review changes

@johnyjose30 
Your change (at version a6aac06faab78b7b6296faedce2c7302f5a4e717) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21265#issuecomment-2415842627

From alanb at openjdk.org  Wed Oct 16 06:43:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 06:43:12 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <a8xRcn4tvBOT00c8_rigs1mMhOIqwnuiDOkZ2Kfsuyo=.b22600ec-a923-4701-877c-355f3e7adfbc@github.com>

On Wed, 16 Oct 2024 01:19:15 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.

src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 624:

> 622:                 SocketConnectEvent.commit(start, duration, isa.getHostString(), address.getHostAddress(), port, connected);
> 623:             }
> 624:         }

Would it be possible to update the JBS or PR description to indicate if the intent is to record an event when the connection cannot be established? I'm asking the change will only record an event when a connection is successfully established ("connected" is always true here).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1802451480

From alanb at openjdk.org  Wed Oct 16 06:49:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 06:49:16 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <DwZiHEl8KUqlDc4EX2W4ZqPRGF9oJ0iDLNhiRgD1dgI=.191ff669-c0e9-4b67-a38c-101d5d92be27@github.com>

On Wed, 16 Oct 2024 01:19:15 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.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1006:

> 1004:         boolean connected = implConnect(sa);
> 1005:         SocketConnectEvent.offer(start, connected, sa);
> 1006:         return connected;

It would be useful if the JBS or PR could say what the intent it for SocketChannels that are configured non-blocking. I assume that implConnect will execute in <20ms (the threshold in the JFR config) so no event will be ever be recorded when configured non-blocking. It would be possible to save the timestamp when connecting, and then use in finishConnect but that does depend on timely usage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1802458279

From jpai at openjdk.org  Wed Oct 16 06:51:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 06:51:58 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v15]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <SuHtP5h78fEQlin6Vvr0CufbI7H3yRuwx8cfO2KRumM=.c8d67072-df0b-49f8-8b11-c6251622000f@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  update man page after Roger's review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/2752/files
  - new: https://git.openjdk.org/jdk/pull/2752/files/d4bce414..bb63acba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=13-14

  Stats: 10 lines in 1 file changed: 6 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

PR: https://git.openjdk.org/jdk/pull/2752

From jpai at openjdk.org  Wed Oct 16 06:56:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 06:56:15 GMT
Subject: RFR: 8324672: Update jdk/java/time/tck/java/time/TCKInstant.java
 now() to be more robust [v3]
In-Reply-To: <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
 <9D9mNDdm_FuaqdcAoSqc35zlQkFXlGfUFOnR3zD7kjU=.78a02151-7a20-43c1-86eb-32ffc85155c9@github.com>
Message-ID: <SNOeoln5h6tgII9XDmNFD40rINW7GgkSWkt6KcTd5_I=.e599054b-28c4-40b5-9e77-02377e561d2d@github.com>

On Tue, 15 Oct 2024 12:31:52 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
>> 
>> Testing: The test was run for 100 times with -Xcomp option.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   checking if time is monotonic

Roger and Daniel have reviewed this PR, I'll go ahead and sponsor this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21413#issuecomment-2415885717

From rsunderbabu at openjdk.org  Wed Oct 16 06:56:16 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 16 Oct 2024 06:56:16 GMT
Subject: Integrated: 8324672: Update
 jdk/java/time/tck/java/time/TCKInstant.java now() to be more robust
In-Reply-To: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
References: <eIhxdOgKkNooJ6xE0p9EqmX1QcIIRIszMkbqCd7bsi8=.ee21fe31-3428-4d3d-be5e-b2cbbdf98539@github.com>
Message-ID: <a78KlD53JPRVSpUoaB_Pcyz82KbEGTun7eyFbKvAons=.33aab83a-7fd0-4a58-9cec-2b26790125fe@github.com>

On Tue, 8 Oct 2024 17:10:43 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> The time difference check might fail for scenarios such as batch compilation. It is safer to give a bigger allowance of 10 seconds instead of 0.1 sec.
> 
> Testing: The test was run for 100 times with -Xcomp option.

This pull request has now been integrated.

Changeset: e94e3bba
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e94e3bba3932f3d92c0a135d333d1ccd6e72b964
Stats:     16 lines in 1 file changed: 11 ins; 0 del; 5 mod

8324672: Update jdk/java/time/tck/java/time/TCKInstant.java now() to be more robust

Reviewed-by: rriggs, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/21413

From alanb at openjdk.org  Wed Oct 16 07:01:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 07:01:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
Message-ID: <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>

On Tue, 15 Oct 2024 22:16:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Robot.java line 433:
>> 
>>> 431:      * then a {@code SecurityException} may be thrown,
>>> 432:      * or the content of the returned {@code Color} is undefined.
>>> 433:      * </p>
>> 
>> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.
>
> Ok, I will revert it.

The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802471843

From dholmes at openjdk.org  Wed Oct 16 07:06:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 07:06:25 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v9]
In-Reply-To: <qJE1LA6Oe5e7nsAnMmNVdB7uI3_O8x1znkkCsUxjvGc=.971ca044-0168-4163-ba9a-b767104ae8f3@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <qJE1LA6Oe5e7nsAnMmNVdB7uI3_O8x1znkkCsUxjvGc=.971ca044-0168-4163-ba9a-b767104ae8f3@github.com>
Message-ID: <WZSWmJFs3TiFkZJgB4814bhf89uiv4umt1QBBWq7f5U=.65e0bbb4-84c8-45f2-85be-31d34611d426@github.com>

On Wed, 16 Oct 2024 00:03:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 16 additional commits since the last revision:
> 
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - reviews from @iwanowww and @rose00 -- move USE_SOFT_CACHE to MethodHandleNatives as a @Stable field; use system prop for init
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/77fc7644...11391c39

Still LGTM.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21049#pullrequestreview-2371389561

From mbaesken at openjdk.org  Wed Oct 16 07:31:18 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Oct 2024 07:31:18 GMT
Subject: Integrated: 8340801: Disable ubsan checks in some awt/2d coding
In-Reply-To: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
References: <Qh8rfa--rq3Z3kMQwy6idjPacOT3PBd7U_JfG4maHNI=.c9002df4-e829-46f6-962b-952a026bd4a1@github.com>
Message-ID: <TYbZpVELrESe0OCujbpy-kqpNKET3krRNbzF9Wv2ZLQ=.fd06cc5a-46db-48b6-a8b9-aebf8a35a45c@github.com>

On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is some old awt/2d coding where warnings occur when running with ubsan enabled binaries.
> However at most of these locations the coding should work (at least on our supported platform set) so the warnings can be disabled at least for now.
> 
> The change adds a macro ATTRIBUTE_NO_UBSAN  similar to what we already use in Hotspot coding.

This pull request has now been integrated.

Changeset: e7cf25ce
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7cf25ce0efdf568fc8eaff249d49e46d5a6eda1
Stats:     45 lines in 2 files changed: 45 ins; 0 del; 0 mod

8340801: Disable ubsan checks in some awt/2d coding

Reviewed-by: ihse, lucy, goetz, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/21184

From duke at openjdk.org  Wed Oct 16 07:39:18 2024
From: duke at openjdk.org (Johny Jose)
Date: Wed, 16 Oct 2024 07:39:18 GMT
Subject: Integrated: 8339637: (tz) Update Timezone Data to 2024b
In-Reply-To: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
References: <KeDCdB1sAqeeuQ5qY1ANaiq2goahVNAMR6U8P7CI-oM=.68771faa-f0e3-4baf-a499-15c7f72ebd98@github.com>
Message-ID: <f2vG4KexLhHhhXrjxeY0ZaLSNQ4wt6zxgt94Fd4D5S0=.627d4223-ef82-42c6-ba84-d07b8f220698@github.com>

On Mon, 30 Sep 2024 14:03:15 GMT, Johny Jose <duke at openjdk.org> wrote:

> Timezone data 2024b changes

This pull request has now been integrated.

Changeset: ebc17c7c
Author:    Johny Jose <johny.jose at oracle.com>
URL:       https://git.openjdk.org/jdk/commit/ebc17c7c8d6febd5a887309d1b7a466bcd2cc0a9
Stats:     1340 lines in 23 files changed: 377 ins; 82 del; 881 mod

8339637: (tz) Update Timezone Data to 2024b

Reviewed-by: naoto, coffeys, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/21265

From ihse at openjdk.org  Wed Oct 16 07:42:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Oct 2024 07:42:17 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <2PNXRviwavdaWvhjoHUOC8iwQzeF7zub2JoHjfj9wiI=.f502c575-ffc7-4570-891e-4c61b89c1cf4@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>
Message-ID: <2EQObSBYG9ZtB0qDRKvYjERfxkYKTlGAlQ9JVEj9zYg=.61c7c77a-746a-4c30-9c58-dfb564ecf24d@github.com>

On Tue, 15 Oct 2024 19:31:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> After thinking a bit more on this, I concluded that we cannot automatically extract a proper set of ld flags from what's being passed to the individual libraries. The LDFLAGS needed by the monolithic static library needs to be explicitly defined. Unfortunately, most of it will be a copy of what is already duplicated across JVM_LDFLAGS, LDFLAGS_JDKLIB and LDFLAGS_JDKEXE. :-( But cleaning that mess upp requires a separate PR.
>> 
>> @magicus, just to make it clear, do you plan to explicitly define the set of LDFLAGS for static linking as part of this PR? We need to make sure the JVM_LDFLAGS is properly included initially.
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1802525755

From ihse at openjdk.org  Wed Oct 16 07:49:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Oct 2024 07:49:17 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <KYb-F60WzkX0gcRK3h7hOe_K0sAWssE4tMj7yu7ILhs=.a643ebe7-7c94-4009-bfe1-b4e6a996c71d@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
 <jHZYMj_1R_mRAV_TAft1VW_x71KMn1GRJJDBOIb_OUk=.6cee3aa6-1646-4891-ad05-4466ec3e290a@github.com>
 <KYb-F60WzkX0gcRK3h7hOe_K0sAWssE4tMj7yu7ILhs=.a643ebe7-7c94-4009-bfe1-b4e6a996c71d@github.com>
Message-ID: <GYE7tuE7nvC4FbdQ57mQQroNVK-CrEaxDTad353Mfts=.3f72d076-11d6-4556-b5cb-fcfea3fe11a5@github.com>

On Wed, 16 Oct 2024 01:30:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 241:
>> 
>>> 239: \  -jar <jar-file.jar>        to execute the main class in 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 single-file program\n\n\
>> 
>> Suggestion:
>> 
>> \  <SourceFile>.java          to compile and execute a single-file program\n\n\
>
> Or even `<MainClass>.java` to pair with `<MainClass>`

That might not be the case in the future, if the file uses an "unnamed class" (https://openjdk.org/projects/amber/design-notes/on-ramp).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1802534965

From ihse at openjdk.org  Wed Oct 16 07:49:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 16 Oct 2024 07:49:17 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <GYE7tuE7nvC4FbdQ57mQQroNVK-CrEaxDTad353Mfts=.3f72d076-11d6-4556-b5cb-fcfea3fe11a5@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
 <jHZYMj_1R_mRAV_TAft1VW_x71KMn1GRJJDBOIb_OUk=.6cee3aa6-1646-4891-ad05-4466ec3e290a@github.com>
 <KYb-F60WzkX0gcRK3h7hOe_K0sAWssE4tMj7yu7ILhs=.a643ebe7-7c94-4009-bfe1-b4e6a996c71d@github.com>
 <GYE7tuE7nvC4FbdQ57mQQroNVK-CrEaxDTad353Mfts=.3f72d076-11d6-4556-b5cb-fcfea3fe11a5@github.com>
Message-ID: <bXnkPwfXFU9jwTmQSdoJ3pTAcJNRFxwWbYs_PWDH5aI=.a157c5fc-10ec-4c0e-a902-fbe7e483d063@github.com>

On Wed, 16 Oct 2024 07:45:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Or even `<MainClass>.java` to pair with `<MainClass>`
>
> That might not be the case in the future, if the file uses an "unnamed class" (https://openjdk.org/projects/amber/design-notes/on-ramp).

Also, if you change `<SourceFile.java>` to `<SourceFile>.java` (I guess it is a good idea), then you should also change ` <jar-file.jar>` to `<jar-file>.jar`, or maybe even `<JarFile>.jar` to better align with the style of the other variables.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1802537440

From alanb at openjdk.org  Wed Oct 16 08:03:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 08:03:17 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

src/java.base/share/classes/java/lang/VirtualThread.java line 221:

> 219:                     vthread.notifyJvmtiStart();
> 220: 
> 221:                     vthread.run(task);

This doesn't look right, it needs to use try-finally.

src/java.base/share/classes/java/lang/VirtualThread.java line 423:

> 421:                 }
> 422: 
> 423:             } finally {

This means an empty finally block, I assume you'll remove the try-finally here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802558723
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802559933

From alanb at openjdk.org  Wed Oct 16 08:08:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 08:08:16 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

src/java.base/share/classes/java/lang/VirtualThread.java line 219:

> 217:                 public void run() {
> 218:                     // notify JVMTI
> 219:                     vthread.notifyJvmtiStart();

The notifyJvmtiMount and notifyJvmtiUnmount (native) methods already have the annotations. Is it really required on the caller too?  I'm wondering if the comment on JvmtiMountTransition needs to be expanded to explain this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802569291

From rcastanedalo at openjdk.org  Wed Oct 16 08:10:15 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 16 Oct 2024 08:10:15 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v9]
In-Reply-To: <MX2iRPfi5jOwWg7t9Nrg204dQ3QBVGgIXjJ_bYhm9Zk=.ef3f8b90-1717-4f00-8128-b12567b5df4d@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <eRhqJeYgVG2MTv0vP7GA-Lxyr9OCc1bsT-OE8dUxJb0=.9166657f-9229-4d01-8f86-8ccd1ffce614@github.com>
 <3YCl5AAk6GEqSTEHET6IloTiEkiGPUjvJnHA--F8ctU=.bfdb7898-7ece-41dc-9c04-971234a74d0f@github.com>
 <MX2iRPfi5jOwWg7t9Nrg204dQ3QBVGgIXjJ_bYhm9Zk=.ef3f8b90-1717-4f00-8128-b12567b5df4d@github.com>
Message-ID: <2OSj9HzqKzyTa1yy2Mg07zva9QEefe0fppmi-0CnLIk=.cc1ac084-a63f-4924-b7bd-35d1c2cae6ed@github.com>

On Tue, 15 Oct 2024 09:24:30 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> I will run some internal CI testing and report back in one or two days.

The test results look good. I tested the changes (up to commit 9f7ad7ab) on top of jdk-24+19 running tier1-tier5 on all Oracle-supported platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2416038769

From alanb at openjdk.org  Wed Oct 16 08:37:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 08:37:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
Message-ID: <eDT17ezlw65yxabhUuwqn337hsf_yb9aZyjc7Cs2TTw=.60e28c95-d6e4-4d23-a9b6-bc0b1e0cdd55@github.com>

On Tue, 15 Oct 2024 18:57:11 GMT, Phil Race <prr 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, ...
>
> src/java.desktop/share/classes/java/awt/AWTPermission.java line 39:
> 
>> 37:  * @apiNote
>> 38:  * This permission cannot be used for controlling access to resources anymore
>> 39:  * as the Security Manager is no longer supported.
> 
> After this JEP is integrated, I expect to deprecate AWTPermission, probably for removal

JEP 486 lists deprecating the permission classes as future work. It would be very disruptive to do this now, but will be a lot easier once the JEP is integrated and the post-JEP tasks to remove the hundreds of usages in the JDK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802617206

From rcastanedalo at openjdk.org  Wed Oct 16 08:52:18 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 16 Oct 2024 08:52:18 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v10]
In-Reply-To: <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>
Message-ID: <G5co3PXZt5oFfLLIIQUpBa92YFqb9jxE2ytEoNmwdbI=.b14e9b01-5c81-49b0-8d01-0486d0e43d88@github.com>

On Tue, 15 Oct 2024 11:07:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Export in JVMCI too

Marked as reviewed by rcastanedalo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20139#pullrequestreview-2371670897

From sspitsyn at openjdk.org  Wed Oct 16 09:56:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 09:56:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>
Message-ID: <mlBy4p_sc9CwuykIxB9ToxKMFLar9G02VMpOlLd1vaY=.457b0b07-732e-40be-8493-84bcd3930767@github.com>

On Tue, 15 Oct 2024 21:26:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 691:
> 
>> 689: 
>> 690:   if (jt->is_in_VTMS_transition()) {
>> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
> 
> Suggestion:
> 
>     jvf = check_and_skip_hidden_frames(true, jvf);

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802772384

From sspitsyn at openjdk.org  Wed Oct 16 10:10:15 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 10:10:15 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
Message-ID: <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>

On Wed, 16 Oct 2024 08:05:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 219:
> 
>> 217:                 public void run() {
>> 218:                     // notify JVMTI
>> 219:                     vthread.notifyJvmtiStart();
> 
> The notifyJvmtiMount and notifyJvmtiUnmount (native) methods already have the annotations. Is it really required on the caller too?  I'm wondering if the comment on JvmtiMountTransition needs to be expanded to explain this.

The method `java/lang/VirtualThread$VThreadContinuation$1.run()` is starting and finishing in a VTMS transition.
The issue is with the JVMTI `NotifyFramePop`. We need a way to disallow adding `FramePop` event requests to its frame. I'm trying to move the `notifyJvmtiStart/notifyJvmtiEnd` calls to earlier frame to reduce a little bit the scope of VTMS transition. What is the best place to explain it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802793692

From sspitsyn at openjdk.org  Wed Oct 16 10:13:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 10:13:13 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
Message-ID: <NsgSgLhaiapaU1V95cAeyu0G8Tw1nHr2LN4kductRGk=.827476cf-272f-4e73-9410-f63c0e510b06@github.com>

On Wed, 16 Oct 2024 08:00:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 423:
> 
>> 421:                 }
>> 422: 
>> 423:             } finally {
> 
> This means an empty finally block, I assume you'll remove the try-finally here.

Thank you for the comment. I can move the try-finally to the method `java/lang/VirtualThread$VThreadContinuation$1.run()` if you prefer. But it will play the same role functionally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802799611

From nbenalla at openjdk.org  Wed Oct 16 10:20:21 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 16 Oct 2024 10:20:21 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v16]
In-Reply-To: <ptKUj1eaw0YHXVsjJn4jyxXrBrOSuX2ajp-IU-wBL9I=.3e1c3665-4a87-49f9-b07e-d34e3fb5cf38@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <ptKUj1eaw0YHXVsjJn4jyxXrBrOSuX2ajp-IU-wBL9I=.3e1c3665-4a87-49f9-b07e-d34e3fb5cf38@github.com>
Message-ID: <cHvC9yKO3Z0xoU6s90HRwivLvuv-__cr2o51HlfrN3Q=.69dd9d1c-44fa-4c9f-8aa6-a8c56f59ef7a@github.com>

On Wed, 2 Oct 2024 14:03:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
>> 
>> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
>> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
>> - for constructors, the release in which the constructor with the given VM descriptor was introduced
>> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
>> 
>> Effective since value of an API element is computed as follows:
>> - if the given element has a `@since` tag in its javadoc, it is used
>> - in all other cases, return the effective since value of the enclosing element
>> 
>> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
>> 
>> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
>> 
>> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
>> 
>> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
>> 
>> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - extra check to make sure we're excluding sub-packages too
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - exclude list is now module specific
>  - remove empty if statement, debugging showed the condition is never true
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - Change "found" to "should be" in the error messages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - avoid using `continue`, fix mistake in last commit
>  - extend SinceChecker to now skip some packages
>  - Merge remote-tracking branch 'upstream/master' into source-based-since-checker
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/d6820d13...47ba2a1c

Thank you for the reviews; all. And the help to getting this work integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2416364730

From nbenalla at openjdk.org  Wed Oct 16 10:20:22 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 16 Oct 2024 10:20:22 GMT
Subject: Integrated: 8331051: Add an `@since` checker test for `java.base`
 module
In-Reply-To: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
Message-ID: <ygMRuX7JYmJ4QLx4dl0lllMV9udpV3uIKnk1KyjZNgw=.55b25414-5105-41fc-b4d2-8762b76cd8e0@github.com>

On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> This checker checks the values of the `@since` tag found in the documentation comment for an element against the release in which the element first appeared.
> 
> Real since value of an API element is computed as the oldest release in which the given API element was introduced. That is:
> - for modules, classes and interfaces, the release in which the element with the given qualified name was introduced
> - for constructors, the release in which the constructor with the given VM descriptor was introduced
> - for methods and fields, the release in which the given method or field with the given VM descriptor became a member of its enclosing class or interface, whether direct or inherited
> 
> Effective since value of an API element is computed as follows:
> - if the given element has a `@since` tag in its javadoc, it is used
> - in all other cases, return the effective since value of the enclosing element
> 
> The since checker verifies that for every API element, the real since value and the effective since value are the same, and reports an error if they are not.
> 
> Preview method are handled as per JEP 12, if `@PreviewFeature` is used consistently going forward then the checker doesn't need to be updated with every release. The checker has explicit knowledge of preview elements that came before `JDK 14` because they weren't marked in a machine understandable way and preview elements that came before `JDK 17` that didn't have `@PreviewFeature`.
> 
> Important note : We only check code written since `JDK 9` as the releases used to determine the expected value of `@since` tags are taken from the historical data built into `javac` which only goes back that far
> 
> The intial comment at the beginning of `SinceChecker.java` holds more information into the program.
> 
> I already have filed issues and fixed some wrong tags like in #18640, #18032, #18030, #18055, #18373, #18954, #18972.

This pull request has now been integrated.

Changeset: c81aa755
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c81aa7551c37cc025c9054db08472b8abb2cbcb5
Stats:     989 lines in 3 files changed: 987 ins; 0 del; 2 mod

8331051: Add an `@since` checker test for `java.base` module

Reviewed-by: jlahoda, jjg

-------------

PR: https://git.openjdk.org/jdk/pull/18934

From swen at openjdk.org  Wed Oct 16 10:32:49 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 16 Oct 2024 10:32:49 GMT
Subject: RFR: 8342336: Optimize ClassFile imports
Message-ID: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>

This is a code style improvement for imports in the java/lang/classfile and jdk/internal/classfile/impl directories, includes:
1. Import in alphabetical order
2. Add a blank line between java and jdk imports
3. Use import * for a large number of imports

-------------

Commit messages:
 - optimize imports
 - suggestion from @liach
 - suggestion from @liach
 - Merge remote-tracking branch 'upstream/master' into classfile_reimport_202410
 - suggestion from @liach
 - reimport

Changes: https://git.openjdk.org/jdk/pull/21482/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21482&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342336
  Stats: 1435 lines in 198 files changed: 430 ins; 910 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/21482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21482/head:pull/21482

PR: https://git.openjdk.org/jdk/pull/21482

From liach at openjdk.org  Wed Oct 16 10:32:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 10:32:51 GMT
Subject: RFR: 8342336: Optimize ClassFile imports
In-Reply-To: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
References: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
Message-ID: <E2_15bj7EDvqhXHRIIyYxY9i9BQuYoPavkeC_fpC2mc=.bafaeaa1-5ebc-4534-9593-fa495e2e52d2@github.com>

On Sun, 13 Oct 2024 01:42:38 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This is a code style improvement for imports in the java/lang/classfile and jdk/internal/classfile/impl directories, includes:
> 1. Import in alphabetical order
> 2. Add a blank line between java and jdk imports
> 3. Use import * for a large number of imports

src/java.base/share/classes/java/lang/classfile/AccessFlags.java line 29:

> 27: import java.lang.reflect.AccessFlag;
> 28: import java.util.Set;
> 29: import jdk.internal.classfile.impl.AccessFlagsImpl;

Missing blank line

src/java.base/share/classes/java/lang/classfile/ClassBuilder.java line 1:

> 1: /*

We should sort java.* imports so `lang.classfile` comes before `lang.constant`

src/java.base/share/classes/java/lang/classfile/ClassSignature.java line 28:

> 26: 
> 27: import java.util.List;
> 28: import jdk.internal.classfile.impl.SignaturesImpl;

Need a blank line before

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 43:

> 41: 
> 42: import jdk.internal.classfile.impl.*;
> 43: import jdk.internal.classfile.impl.TransformImpl;

Suggestion:

src/java.base/share/classes/java/lang/classfile/Instruction.java line 29:

> 27: 
> 28: import jdk.internal.classfile.impl.AbstractInstruction;
> 29: import java.lang.classfile.instruction.*;

Move this before `jdk.internal` and add blank line.

src/java.base/share/classes/java/lang/classfile/MethodElement.java line 28:

> 26: 
> 27: import java.lang.classfile.attribute.*;
> 28: import jdk.internal.javac.PreviewFeature;

Blank line

src/java.base/share/classes/java/lang/classfile/PseudoInstruction.java line 29:

> 27: import java.lang.classfile.attribute.CodeAttribute;
> 28: import java.lang.classfile.instruction.*;
> 29: import jdk.internal.classfile.impl.AbstractPseudoInstruction;

Blank line

src/java.base/share/classes/java/lang/classfile/constantpool/ModuleEntry.java line 28:

> 26: 
> 27: import java.lang.constant.ModuleDesc;
> 28: import jdk.internal.classfile.impl.AbstractPoolEntry;

Blank line

src/java.base/share/classes/java/lang/classfile/constantpool/PackageEntry.java line 28:

> 26: 
> 27: import java.lang.constant.PackageDesc;
> 28: import jdk.internal.classfile.impl.AbstractPoolEntry;

Blank line

src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java line 33:

> 31: 
> 32: import static java.lang.classfile.AnnotationValue.*;
> 33: import static java.lang.classfile.TypeAnnotation.TargetInfo.*;

Maybe move all static imports below regular imports...

src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 28:

> 26: package jdk.internal.classfile.impl;
> 27: 
> 28: import java.lang.constant.*;

constant comes after classfile

src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java line 34:

> 32: import java.util.Optional;
> 33: import java.util.function.Function;
> 34: import java.lang.classfile.*;

lang.* comes before util.*

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798683478
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798683789
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798684015
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798684167
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798684371
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798684466
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798684556
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798686077
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798686125
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798686757
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798690093
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1798692369

From jpai at openjdk.org  Wed Oct 16 10:35:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 10:35:15 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d
Message-ID: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>

This brings in CPU24_10 changes into master branch.

-------------

Commit messages:
 - 8335713: Enhance vectorization analysis
 - 8332644: Improve graph optimizations
 - 8331446: Improve deserialization support
 - 8307383: Enhance DTLS connections
 - 8311208: Improve CDS Support
 - 8328544: Improve handling of vectorization
 - 8328286: Enhance HTTP client
 - 8328726: Better Kerberos support
 - 8302111: Serialization considerations

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/21533/files
  Stats: 3690 lines in 79 files changed: 2781 ins; 346 del; 563 mod
  Patch: https://git.openjdk.org/jdk/pull/21533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21533/head:pull/21533

PR: https://git.openjdk.org/jdk/pull/21533

From alanb at openjdk.org  Wed Oct 16 11:24:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 11:24:09 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d
In-Reply-To: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
Message-ID: <qwOQuVYagvGmmYX1Zr_IQui-YZKkIo0GzicRDl8pP18=.52835a32-507d-4bd4-8500-12194ee23468@github.com>

On Wed, 16 Oct 2024 10:31:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in CPU24_10 changes into master branch.

Discussed with Jai to confirm testing. All good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21533#pullrequestreview-2372116298

From jpai at openjdk.org  Wed Oct 16 11:39:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 11:39:54 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d [v2]
In-Reply-To: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
Message-ID: <0HP5c8oQ1lFbLOjhg180ujsosHaV9REEAQMZ_O3bPx4=.ad6b6227-7ab8-4f9f-87e6-d13cea518c50@github.com>

> This brings in CPU24_10 changes into master branch.

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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21533/files
  - new: https://git.openjdk.org/jdk/pull/21533/files/490d099e..490d099e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21533&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21533&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21533.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21533/head:pull/21533

PR: https://git.openjdk.org/jdk/pull/21533

From dfuchs at openjdk.org  Wed Oct 16 11:39:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 16 Oct 2024 11:39:54 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d [v2]
In-Reply-To: <0HP5c8oQ1lFbLOjhg180ujsosHaV9REEAQMZ_O3bPx4=.ad6b6227-7ab8-4f9f-87e6-d13cea518c50@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
 <0HP5c8oQ1lFbLOjhg180ujsosHaV9REEAQMZ_O3bPx4=.ad6b6227-7ab8-4f9f-87e6-d13cea518c50@github.com>
Message-ID: <Iu4lF5Whdn1hc4VukFGDSkuIRBMicjMBQP_aSg5rTYs=.166b4d6b-c252-4b61-9362-a823a7475ecc@github.com>

On Wed, 16 Oct 2024 11:36:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This brings in CPU24_10 changes into master branch.
>
> 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.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21533#pullrequestreview-2372156477

From jpai at openjdk.org  Wed Oct 16 11:39:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 11:39:54 GMT
Subject: RFR: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d
In-Reply-To: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
Message-ID: <CxyqkRRZoAJPt_JPQpmGwuM8UUZ7A-jOqvN7BulGIwc=.305a6fb3-e030-4d99-abeb-647c15b3402e@github.com>

On Wed, 16 Oct 2024 10:31:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in CPU24_10 changes into master branch.

Thank you Alan and Daniel for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21533#issuecomment-2416550126

From jpai at openjdk.org  Wed Oct 16 11:39:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 11:39:56 GMT
Subject: Integrated: Merge 490d099e234f27adef7d691d3c5a08ebdb550c5d
In-Reply-To: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
References: <tCbiKNx1bwoUfLrgW2Y2lUaxW-U6-bXJn89s_7DNcd8=.341aaf20-bb44-470d-b8a7-ebc7ff0277d3@github.com>
Message-ID: <jN3QhL4Ba6UTfaf6im2ZPzCfVtL4l3EsD_pCuB3Ib_8=.82e5d718-d75e-435b-8cda-448b3d89376f@github.com>

On Wed, 16 Oct 2024 10:31:12 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This brings in CPU24_10 changes into master branch.

This pull request has now been integrated.

Changeset: cf5bb127
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf5bb12731b0eefe53b99281453e40493ddafbe4
Stats:     3690 lines in 79 files changed: 2781 ins; 346 del; 563 mod

Merge

Reviewed-by: alanb, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/21533

From viktor.klang at oracle.com  Wed Oct 16 11:42:14 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 16 Oct 2024 11:42:14 +0000
Subject: [External] : Re: Fw: New candidate JEP: 485: Stream Gatherers
In-Reply-To: <60c73cda-183d-4bf3-8e8b-ea6536573ca9@gmail.com>
References: <07710471-f249-48dc-bac8-40e00960febe@gmail.com>
 <MW4PR10MB577400AB29878DB7401D3400FF452@MW4PR10MB5774.namprd10.prod.outlook.com>
 <dcb3a05c-f193-46b2-ba2c-6023c0a5c155@gmail.com>
 <MW4PR10MB57748D537C5EDDE29D7D8837FF452@MW4PR10MB5774.namprd10.prod.outlook.com>
 <60c73cda-183d-4bf3-8e8b-ea6536573ca9@gmail.com>
Message-ID: <MW4PR10MB57744EB611FCEC8016BC918EFF462@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Cay,

>Maybe just a mental block on my side. If other programmers worked with the API and found it consistent, don't mind me. I just thought to bring it up in case this has not received a lot of scrutiny. It is a pretty specialized aspect, after all.

Perhaps the best thing here is to just let it sit for a while and see if some time is all that's needed.

>PS. I also think it would be helpful to be more explicit in the javadoc about the value of exploiting greediness. What is the sweet spot? Recognizing that nothing in the pipeline is short-circuiting and then pushing elements through without checking? Or more aggressive parallelization?

I guess it depends on "sweet spot from whom". From an implementor perspective if you don't intend to initiate a short-circuit signal, using ofGreedy is a good way to both remind yourself, and send that signal to Gatherer-evaluators. Omitting ofGreedy won't break anything. If you implement a Gatherer-evaluator, I think it is safe to presume that it completely depends on the use-case?and of course all optimization work should be based on sensible benchmarking.

>I looked at the source code of Gatherer/Gatherers/GathererOp, and it is not obvious to me how one can see a significant performance win with greediness. Can you recommend a benchmark for me to study?

I think it makes sense to look at the mentions of "greedy" in GathererOp and Gatherers (specifically the composition).

There are a fair number of benchmarks here (they all start with "Gather"): https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref
[https://opengraph.githubassets.com/004d92ce0313fcb0df04cee2d5ae62241a675b042bb73c5de9481333278bcfa2/openjdk/jdk]<https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref>
jdk/test/micro/org/openjdk/bench/java/util/stream/ops/ref at master ? openjdk/jdk<https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/util/stream/ops/ref>
JDK main-line development https://openjdk.org/projects/jdk - openjdk/jdk
github.com


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle

________________________________
From: Cay Horstmann <cay.horstmann at gmail.com>
Sent: Tuesday, 15 October 2024 20:19
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Fw: New candidate JEP: 485: Stream Gatherers

Thanks Viktor, I like your concept of multiple vantage points a lot.

> Implementor: "use ofGreedy to signal that this operation does not itself initiate short-circuiting"
> Reviewer: "when you see ofGreedy verify that this operation does not itself initiate short-circuiting"
> Debugger: "when the expectation was that the stream should be short-circuiting and isn't, one thing to look for is ofGreedy"
>
> Implementor: "use ofSequential to signal that this operation is intended to always be executed sequentially"
> Reviewer: "when you see ofSequential, understand why the operation can't/shouldn't be parallelized for parallel streams"
> Debugger: "if the parallel stream is not performing as well as expected, one thing to look for is ofSequential!

I just don't see how these scenarios are parallel. To me, the following  would be parallel.

Scenario I: Brag about better performance

As implementor, I can always go the easy route with of/of: sequential, non-greedy. It'll work, but performance may suffer. Or I can assert that I have done the extra care: ofParallel/ofGreedy.

As reviewer, I see the deluxe ofParallel/ofGreedy, and I verify that the operation enables parallel execution/doesn't short circuit.

As debugger, I see slow performance, and I am not surprised if it's the lame of/of.

Scenario II: Warn of worse performance

As implementor, I aim to produce the most performant way with of/of: parallelizable, greedy. Nice names for the good stuff. If I can't, I'll alert with ofSerial/ofShortCircuit.

As reviewer, I see the coveted of/of, and I verify that the operation enables parallel execution/doesn't short circuit.

As debugger, I see slow performance, and I am not surprised if it is ofSerial/ofShortCircuit. They had it coming.

Either naming pair (ofParallel/ofGreedy or ofSerial/ofShortCircuit) feels consistent to me. But I find of/ofGreedy and ofSerial/of awkward to explain.

Maybe just a mental block on my side. If other programmers worked with the API and found it consistent, don't mind me. I just thought to bring it up in case this has not received a lot of scrutiny. It is a pretty specialized aspect, after all.

Cheers,

Cay

PS. I also think it would be helpful to be more explicit in the javadoc about the value of exploiting greediness. What is the sweet spot? Recognizing that nothing in the pipeline is short-circuiting and then pushing elements through without checking? Or more aggressive parallelization?

I looked at the source code of Gatherer/Gatherers/GathererOp, and it is not obvious to me how one can see a significant performance win with greediness. Can you recommend a benchmark for me to study?

--

Cay S. Horstmann | https://urldefense.com/v3/__https://horstmann.com__;!!ACWV5N9M2RV99hQ!L7TUnjIXEj8etBmsbDi4Y0NIBR_DpdDkgJ_6QMR7JTEcftYTsVg6pinwac2lDODJd-lbUAcTYIMVWWLk0ej1qtAeqw$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241016/afe0effb/attachment-0001.htm>

From mullan at openjdk.org  Wed Oct 16 12:24:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 12:24:12 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <Ja98-AUnNpEHz68-j-pJqQCG2VXkgwShF-UPI6apN4w=.56399d6b-8bed-4fdb-9fc7-e5a5ea707b1f@github.com>

On Wed, 16 Oct 2024 01:19:15 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.

I think this change should have a release note.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2416674860

From liach at openjdk.org  Wed Oct 16 12:45:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 12:45:20 GMT
Subject: RFR: 8342336: Optimize ClassFile imports
In-Reply-To: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
References: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
Message-ID: <3iZDzRsdRSEWHmWjzv0gPXtLUPsjbx8ny-lotE1Bpbg=.404bc1b8-22c3-40bc-9d78-b634cb39255a@github.com>

On Sun, 13 Oct 2024 01:42:38 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This is a code style improvement for imports in the java/lang/classfile and jdk/internal/classfile/impl directories, includes:
> 1. Import in alphabetical order
> 2. Add a blank line between java and jdk imports
> 3. Use import * for a large number of imports

Changes requested by liach (Reviewer).

src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java line 40:

> 38: import jdk.internal.classfile.impl.verifier.VerificationWrapper.ConstantPoolWrapper;
> 39: 
> 40: import static jdk.internal.classfile.impl.RawBytecodeHelper.ILLEGAL;

Suggestion:

import static jdk.internal.classfile.impl.RawBytecodeHelper.*;


This is using raw opcode from `RawBytecodeHelper`

-------------

PR Review: https://git.openjdk.org/jdk/pull/21482#pullrequestreview-2372351160
PR Review Comment: https://git.openjdk.org/jdk/pull/21482#discussion_r1803032811

From weijun at openjdk.org  Wed Oct 16 13:32:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Oct 2024 13:32:24 GMT
Subject: RFR: 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: <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@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...

`java.security.jgss`, `jdk.security.auth`, and `jdk.security.jgss` look mostly fine except for [one question](https://github.com/openjdk/jdk/pull/21498#pullrequestreview-2372476763).

src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:

> 29: 
> 30: /**
> 31:  * This class is for GSS security context permissions.

Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2372479736
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803106645

From jpai at openjdk.org  Wed Oct 16 13:56:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Oct 2024 13:56:12 GMT
Subject: RFR: 8342083: Make a few fields in FileSystemPreferences final
In-Reply-To: <nmDjJHEue_WGeD-ipZtWp3aUfmjNonrOo0cfyl3Am6Q=.17200a50-48cd-4528-95d5-2a66c7476d52@github.com>
References: <nmDjJHEue_WGeD-ipZtWp3aUfmjNonrOo0cfyl3Am6Q=.17200a50-48cd-4528-95d5-2a66c7476d52@github.com>
Message-ID: <_zrXf8tWQofIK4NIxgevi36Kh-LIxIdfjtehGRGaAT4=.66cbb14a-b7fe-48d4-9258-676147d49f58@github.com>

On Mon, 23 Sep 2024 09:13:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 8342083: Make a few fields in FileSystemPreferences final

This looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21131#pullrequestreview-2372568195

From shade at openjdk.org  Wed Oct 16 14:11:22 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 14:11:22 GMT
Subject: Integrated: 8329597: C2: Intrinsify Reference.clear
In-Reply-To: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
Message-ID: <1qO6cEgGDaDehUQfowHFCdggggj3dz-5QU7YIU3RwNM=.3ed8aff2-01aa-4f8a-a29c-d1137d879e06@github.com>

On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
> 
> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: 7625b299
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7625b29920e95f9b754057fe0a2c4ab0afa5cb0c
Stats:     362 lines in 26 files changed: 341 ins; 0 del; 21 mod

8329597: C2: Intrinsify Reference.clear

Reviewed-by: rcastanedalo, eosterlund, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/20139

From shade at openjdk.org  Wed Oct 16 14:11:21 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 16 Oct 2024 14:11:21 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v10]
In-Reply-To: <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <6nY6w8PZWrnARnlcSL5nQ774mlqnGznnXYHBG_Mp92o=.dee83646-2b5e-43f7-b56e-3b9b93171028@github.com>
Message-ID: <F_z8HalzrPdL7PtTgb0yrxayF-6zww1jVkc2HfrhLIc=.66cd3444-de84-491b-b230-919621178c09@github.com>

On Tue, 15 Oct 2024 11:07:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Export in JVMCI too

Thank you for testing! Here goes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2416954569

From alanb at openjdk.org  Wed Oct 16 14:41:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 14:41:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <NsgSgLhaiapaU1V95cAeyu0G8Tw1nHr2LN4kductRGk=.827476cf-272f-4e73-9410-f63c0e510b06@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
 <NsgSgLhaiapaU1V95cAeyu0G8Tw1nHr2LN4kductRGk=.827476cf-272f-4e73-9410-f63c0e510b06@github.com>
Message-ID: <o14TpC8BDBHSu7XLm5HD1rT09n1_QOA4JiWdrAZaXQU=.40a2907b-4411-41cb-aa33-4bac68816551@github.com>

On Wed, 16 Oct 2024 10:10:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 423:
>> 
>>> 421:                 }
>>> 422: 
>>> 423:             } finally {
>> 
>> This means an empty finally block, I assume you'll remove the try-finally here.
>
> Thank you for the comment. I can move the try-finally to the method `java/lang/VirtualThread$VThreadContinuation$1.run()` if you prefer. But it will play the same role functionally.

Changing the run method to

vthread.notifyJvmtiStart();
try {
    vthread.run(task);
} finally {
    vthread.notifyJvmtiEnd();
}

is okay. I was initially puzzled because the run method is already`@Hidden` but I don't think this is used by JVMTI.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803248925

From alanb at openjdk.org  Wed Oct 16 14:53:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 14:53:15 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
 <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>
Message-ID: <Wht-tuuGDZt_XliGWoBzXmQRNiY5xe-nsYusevJtHoE=.e68c0c34-0007-4098-a631-99c640b7f989@github.com>

On Wed, 16 Oct 2024 10:07:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 219:
>> 
>>> 217:                 public void run() {
>>> 218:                     // notify JVMTI
>>> 219:                     vthread.notifyJvmtiStart();
>> 
>> The notifyJvmtiMount and notifyJvmtiUnmount (native) methods already have the annotations. Is it really required on the caller too?  I'm wondering if the comment on JvmtiMountTransition needs to be expanded to explain this.
>
> The method `java/lang/VirtualThread$VThreadContinuation$1.run()` is starting and finishing in a VTMS transition. The issue is with the JVMTI `NotifyFramePop`. We need a way to disallow adding `FramePop` event requests to its frame because such requests cause problems because they are not used to post a `FramePop` events nor they are properly cleared. The annotation `@JvmtiMountTransition` is needed to help with this. I'm trying to move the `notifyJvmtiStart()/notifyJvmtiEnd()` calls to earlier frame to reduce a little bit the scope of VTMS transition. What do you think is the best place to explain it? Would placed a comment before annotation `@JvmtiMountTransition` for method `java/lang/VirtualThread$VThreadContinuation$1.run()` good enough?

No issue from me on moving the notifications to the run method. My comment was more for the JvmtiMountTransition's class description as it's not easy to audit the use of this annotation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803270431

From jlahoda at openjdk.org  Wed Oct 16 14:55:34 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Oct 2024 14:55:34 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
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: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@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` launcher, 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 launcher 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:
> 
> $ java
> 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 single-file program
> 
> Where key java options include:
>   --class-path <class path>
>       a ":"-separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a ":"-separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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:

  Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21411/files
  - new: https://git.openjdk.org/jdk/pull/21411/files/0a6c17f4..1791840b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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  Wed Oct 16 14:55:34 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Oct 2024 14:55:34 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v2]
In-Reply-To: <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gu1CTiUC1zf8mUCA-807XF4UFaZwBssNhWxBFF-tNJs=.061d27ef-f89f-4a37-ae50-b9ae78f1f94b@github.com>
Message-ID: <44lW0DXK4r-LFJOjqDtfQ670fC4P4SVKeQxOTgTTr5g=.11e14f2e-abb8-4b00-98ad-5c11946ef078@github.com>

On Thu, 10 Oct 2024 17:54:51 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help based on review suggestions.

Thanks for the comments so far. I've updated the text based on them, and updated the output in the description of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2417070716

From yzheng at openjdk.org  Wed Oct 16 15:15:26 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 16 Oct 2024 15:15:26 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v13]
In-Reply-To: <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <CaCZjbRHBdfOdnlRWTqU_UXXYS9YTTzv05nHmKgmhrE=.0d0013b8-59b5-4930-844e-d3634c081fc5@github.com>
Message-ID: <zxi6t9MYavUM33xbiJjrTascpUcXWAg2ndDNtukJIbE=.779f0175-a304-4637-907f-6e462ff9f6f9@github.com>

On Mon, 23 Sep 2024 19:24:51 GMT, Srinivas Vamsi Parasa <sparasa at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change ifdef from x86 to AMD64

src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp line 74:

> 72: // Special cases:
> 73: //  tanh(NaN) = quiet NaN, and raise invalid exception
> 74: //  tanh(INF) = that INF

This should be

tanh(POSITIVE_INFINITY) = +1.0
tanh(NEGATIVE_INFINITY) = -1.0

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1803316120

From duke at openjdk.org  Wed Oct 16 15:34:24 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 16 Oct 2024 15:34:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
Message-ID: <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>

On Wed, 16 Oct 2024 06:28:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks, will fix.
>
> SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have currently in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.

**SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.

--------------------------------------------------------------------------------

See?also:
- https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803352590

From vromero at openjdk.org  Wed Oct 16 15:40:16 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 16 Oct 2024 15:40:16 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <LZJ1kn-yCJ66HlIfPxBubV1QN-dtiJS03SsDKOuX91Q=.14721970-2d75-4863-8960-a3508b2355a2@github.com>

On Mon, 14 Oct 2024 12:46:29 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 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

looks sensible to me

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2372901360

From alanb at openjdk.org  Wed Oct 16 15:56:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 15:56:26 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
Message-ID: <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>

On Wed, 16 Oct 2024 15:31:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have currently in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.
>
> **SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.
> 
> --------------------------------------------------------------------------------
> 
> See?also:
> - https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565

We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803388208

From iklam at openjdk.org  Wed Oct 16 16:01:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 16 Oct 2024 16:01:20 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
 <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>
Message-ID: <Lt-egmoFeE5x34ODYPIT288Y43gj6mehak4PUyvgsT8=.621acc0f-5a75-4e53-ae0b-805968469f99@github.com>

On Wed, 16 Oct 2024 03:29:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/memory/iterator.inline.hpp line 53:
>> 
>>> 51:     // class has not yet been loaded by CDS.
>>> 52:     cld->oops_do(this, _claim);
>>> 53:   }
>> 
>> Could you show the stack trace for this? I want to understand better why we are iterating over objects that don't have a loaded class.
>
> Here's the call stack if I remove the "if" check on line 49. It can be reproduced with test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java from the PR repo.
> 
> 
> 10 javaSignalHandler (sig=11, info=0x7ffff428fdb0, context=0x7ffff428fc80)
> 12 Atomic::PlatformLoad::operator() (this=0x7ffff429097f, dest=0x28)
> 13 Atomic::LoadImpl, void>::operator() (this=0x7ffff42909af, dest=0x28)
> 14 Atomic::load (dest=0x28)
> 15 ClassLoaderData::try_claim (this=0x0, claim=4)
> 16 ClassLoaderData::oops_do (this=0x0, f=0x7fff6c014c88, claim_value=4, clear_mod_oops=false)
> 17 ClaimMetadataVisitingOopIterateClosure::do_cld (this=0x7fff6c014c88, cld=0x0)
> 18 ClaimMetadataVisitingOopIterateClosure::do_klass (this=0x7fff6c014c88, k=0x7fff763655d8)
> 19 call_do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
> 20 Devirtualizer::do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
> 21 InstanceKlass::oop_oop_iterate (closure=0x7fff6c014c88, obj=0xfffd72a0, this=0x7fff763655d8)
> 22 OopOopIterateDispatch::Table::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, k=0x7fff763655d8)
> 23 OopIteratorClosureDispatch::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, klass=0x7fff763655d8)
> 24 oopDesc::oop_iterate (this=0xfffd72a0, cl=0x7fff6c014c88)
> 25 G1FullGCMarker::follow_object (this=0x7fff6c014630, obj=0xfffd72a0)
> 26 G1FullGCMarker::publish_and_drain_oop_tasks (this=0x7fff6c014630)
> 27 G1FullGCMarker::follow_marking_stacks (this=0x7fff6c014630)
> 28 G1FullGCMarker::complete_marking (this=0x7fff6c014630, oop_stacks=0x7fffd445c6b8, array_stacks=0x7fffd445c6d0, terminator=0x7fffd445c190)
> 29 G1FullGCMarkTask::work (this=0x7fffd445c030, worker_id=0)
> 30 WorkerTaskDispatcher::worker_run_task (this=0x7ffff008b9b8)
> 31 WorkerThread::run (this=0x7ffff008bac0)
> 
> 
> This is in a GC triggered by here (with -XX:VerifyArchivedFields=2).
> 
> 
> void HeapShared::init_archived_fields_for(Klass* k, 
>      const ArchivedKlassSubGraphInfoRecord* record) {
>   verify_the_heap(k, "before");
> 
> 
> At frame 18:
> 
> 
> #18 0x00007ffff58505d1 in ClaimMetadataVisitingOopIterateClosure::do_klass 
>     (this=0x7fff6c014c88, k=0x7fff763655d8)
>     at src/hotspot/share/memory/iterator.inline.hpp:58
> 58	  ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
> (gdb) psym k->_name
> $1 = 0x7fff765430be "BulkLoaderTestApp$$Lambda+0x800000013"
> (gdb) p k->_class_loader_data
> $2 = (ClassLoaderData *) 0x0
> (gdb) p SystemDictionary::_java_system_loader 
> $3 = {_obj = 0x0}
> 
> 
> At frame 21:
> 
> 
> #21 0x00007ffff6132f6f in InstanceKlass::oop_oop_iterate<narrowOop, G...

I filed [JDK-8342429](https://bugs.openjdk.org/browse/JDK-8342429) "Cache classes in loaded state" to address this properly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803396788

From jbhateja at openjdk.org  Wed Oct 16 16:11:26 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 16:11:26 GMT
Subject: Integrated: 8338023: Support two vector selectFrom API
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <AQXhq7FAv2OC5W6Ept1OJVR3Ijw2rm9hwvTPQMfbPbQ=.db35f716-65f6-492c-8c4f-99ef80833919@github.com>

On Thu, 8 Aug 2024 06:57:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

This pull request has now been integrated.

Changeset: 709914fc
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/709914fc92dd180c8f081ff70ef476554a04f4ce
Stats:     2805 lines in 89 files changed: 2786 ins; 18 del; 1 mod

8338023: Support two vector selectFrom API

Reviewed-by: psandoz, epeter, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/20508

From sviswanathan at openjdk.org  Wed Oct 16 16:07:38 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 16 Oct 2024 16:07:38 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
Message-ID: <SoNH5QFS4FBkfGbGmltCb4Nl1cYzfxjyy1EB2jsGuKk=.5516160f-092c-4a9d-b597-661cb0e74aae@github.com>

On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating tests to use floorMod

Changes look good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2372983898

From liach at openjdk.org  Wed Oct 16 16:20:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 16:20:29 GMT
Subject: RFR: 8342206: Convenience method to check if a ClassEntry matches
 a ClassDesc [v2]
In-Reply-To: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
References: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
Message-ID: <AbYdxCqk2qZOITyIST-rCAxnksyj54v1mXXb9Dl4RsM=.df4fc34c-d414-4540-b570-61369c90a957@github.com>

> Currently, to efficiently check if a `ClassEntry`, such as one from an `InvokeInstruction`, is of a particular class, we use such a pattern (as seen in JEP 486 [Appendix](https://openjdk.org/jeps/486#Appendix)):
> 
> inst.owner().name().equalsString("java/lang/System")
> 
> This pattern has a few issues:
> 
> 1. This is not straightforward. Users may be tempted to write
> 
> inst.owner().asSymbol().equals(CD_System)
> 
> unaware of the degraded performance from extra conversions.
> 
> 2. We aim to reduce the use of "internal names" with encapsulation. Direct use of `"java/lang/System"` goes against this, and we have no constants offered to reduce such error-prone use of internal name.
> 
> Thus, I propose a new API in `ClassEntry`:
> 
> boolean equalsSymbol(ClassDesc)
> 
> that can be used conveniently to check the identity of a class entry with a clean syntax and better performance.

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 three additional commits since the last revision:

 - Reuse cache for arrays, replace some use cases
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-equalssym
 - 8342206: Convenience method to check if a ClassEntry matches a ClassDesc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21526/files
  - new: https://git.openjdk.org/jdk/pull/21526/files/c6e40fd9..54139eae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21526&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21526&range=00-01

  Stats: 9095 lines in 179 files changed: 6849 ins; 690 del; 1556 mod
  Patch: https://git.openjdk.org/jdk/pull/21526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21526/head:pull/21526

PR: https://git.openjdk.org/jdk/pull/21526

From liach at openjdk.org  Wed Oct 16 16:24:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 16:24:12 GMT
Subject: RFR: 8342206: Convenience method to check if a ClassEntry matches
 a ClassDesc [v2]
In-Reply-To: <_th7WLNiPs2lU-v1b_FD938LiqijtnbZUHFsdZqgAYk=.0662df12-3628-4589-bd62-f90838485991@github.com>
References: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
 <8rga5-st0QxAX6qfogf1CCbo_gr9uds7mR9_LEleslI=.a68fdb8c-ce11-485b-b83c-9c11e29c5917@github.com>
 <_th7WLNiPs2lU-v1b_FD938LiqijtnbZUHFsdZqgAYk=.0662df12-3628-4589-bd62-f90838485991@github.com>
Message-ID: <Mb8tZcHUoPRuqB-XOew9xmyZHj9SovVvn8XFb0sl0Ko=.c962faa5-9592-43f1-9cf0-eadd84f6aa17@github.com>

On Wed, 16 Oct 2024 05:58:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 609:
>> 
>>> 607:             var mySym = this.sym;
>>> 608:             if (mySym != null)
>>> 609:                 return mySym.equals(symbol);
>> 
>> Note?that `ClassEntry::asSymbol()` also?caches array?`ClassDesc`s in?`ref1.typeSym` so?that the?symbol?cache can?be?shared with?`FieldRefEntry` and?`ConstantDynamicEntry`.
>> 
>> --------------------------------------------------------------------------------
>> 
>> I suggest adding the following check:
>> 
>> if (ref1.typeSym instanceof ClassDesc ref1Sym && ref1Sym.isArray()) {
>> 	return ref1Sym.equals(symbol);
>> }
>
> I think adding this on the sym present hot path might be too costly. A better way is to pull in the sym before `ref1.equalsString` and push the compatible symbol back to utf8 if we have `equals`.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21526#discussion_r1803436476

From swen at openjdk.org  Wed Oct 16 16:24:55 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 16 Oct 2024 16:24:55 GMT
Subject: RFR: 8342336: Optimize ClassFile imports [v2]
In-Reply-To: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
References: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
Message-ID: <sByYiVJmnNO2JcS1tPFP_2cPbl8EKazsW3z4Wu5kC-g=.61c92e7d-85ed-4026-9fce-b1abbae39dc9@github.com>

> This is a code style improvement for imports in the java/lang/classfile and jdk/internal/classfile/impl directories, includes:
> 1. Import in alphabetical order
> 2. Add a blank line between java and jdk imports
> 3. Use import * for a large number of imports

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21482/files
  - new: https://git.openjdk.org/jdk/pull/21482/files/71a23ed4..65c5ddae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21482&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21482&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21482/head:pull/21482

PR: https://git.openjdk.org/jdk/pull/21482

From nbenalla at openjdk.org  Wed Oct 16 16:31:58 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 16 Oct 2024 16:31:58 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
Message-ID: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@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

-------------

Commit messages:
 - Add since checker tests to other modules

Changes: https://git.openjdk.org/jdk/pull/21542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341399
  Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 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 vklang at openjdk.org  Wed Oct 16 16:37:15 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 16 Oct 2024 16:37:15 GMT
Subject: RFR: 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: <1weO1tM4iaGbFnxuDPEoICXG0Ri-5f1QQgtiZJ1CccI=.49d4f46d-ef9f-4b5a-9f47-61da21473a24@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),

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 305:

> 303:      *  * Slot k must be read with an acquiring read, which it must
> 304:      *    anyway to dereference and run the task if the (acquiring)
> 305:      *    CAS succeeds

Suggestion:

     *    CAS succeeds.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 854:

> 852:      * usages of ForkJoinTasks ignore interrupt status when executing
> 853:      * or awaiting completion.  Otherwise, reporting task results or
> 854:      * exceptions is preferred to throwing InterruptedExeptions,

Suggestion:

     * exceptions is preferred to throwing InterruptedExceptions,

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1287:

> 1285:             if (!internal)
> 1286:                 unlockPhase();
> 1287:             if ((room == 0 || U.getReference(a, pk) == null) && pool != null)

We used to look at `- 2` but now we look at `- 1`, perhaps that could account for stalls?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1913:

> 1911:                 if (!all)
> 1912:                     break;
> 1913:             }

Stylistically, it might be cleaner to do this:

Suggestion:

        do {
            WorkQueue[] qs; WorkQueue v; int sp, i;
            if ((sp = (int)c) == 0 || (qs = queues) == null ||
                qs.length <= (i = sp & SMASK) || (v = qs[i]) == null)
                break;
            if (c == (c = compareAndExchangeCtl(
                          c, ((UMASK & (c + RC_UNIT)) | (c & TC_MASK) |
                              (v.stackPred & LMASK))))) {
                v.phase = sp;
                if (v.parking != 0)
                    U.unpark(v.owner);
            } while(all);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1803453194
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1803452635
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1803455326
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1803451989

From vklang at openjdk.org  Wed Oct 16 16:41:15 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 16 Oct 2024 16:41:15 GMT
Subject: RFR: 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: <c1Y1dp7t9hdgBh0fg5DNTiFqR3hjtjwRRbNL6HHH42U=.4593b749-0db5-4e5d-ab78-9010386768e0@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),

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1969:

> 1967:             int phase = w.phase, r = w.stackPred;     // seed from registerWorker
> 1968:             int cfg = w.config, nsteals = 0, src = -1;
> 1969:             for (;;) {

Could the non-labeled version introduce different GC safepoints which could have adverse impacts? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1803461156

From vklang at openjdk.org  Wed Oct 16 16:45:13 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 16 Oct 2024 16:45:13 GMT
Subject: RFR: 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: <nVVcXnmp1fOJdqSO6LQFCMrQR4Dsxpx_kwEbd65Gobk=.6dacd269-cc9b-4fc0-a590-0c52e4decba6@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),

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2279:

> 2277:                                 if (U.compareAndSetReference(a, k, t, null)) {
> 2278:                                     q.base = b + 1;
> 2279:                                     w.source = j;

Might be worth commenting the volatile-write piggybacking which allows to get away with not calling updateBase above? ?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2433:

> 2431:                             if (U.compareAndSetReference(a, k, t, null)) {
> 2432:                                 q.base = nb;
> 2433:                                 w.source = j;

Might be worth commenting the volatile-write piggybacking which allows to get away with not calling updateBase above? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1803467095
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1803468091

From bpb at openjdk.org  Wed Oct 16 17:01:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Oct 2024 17:01:24 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: <Wz092fmHIG8mrjUwkj8R-COzkfjTcNtfyxuC3Ms_0EM=.2d84f824-c158-49ac-b34d-6c36899b61c9@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.

If `PeekNamedPipe` fails with `ERROR_INVALID_FUNCTION`, then the number of bytes available is set to zero, the default. The test is updated to JUnit 5 and a sub-test is added for this case of reading form the `NUL` device.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21543#issuecomment-2417404363

From bpb at openjdk.org  Wed Oct 16 17:01:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Oct 2024 17:01:24 GMT
Subject: RFR: 8342086: FileInputStream.available() fails with
 "Incorrect function" for "nul" path (win)
Message-ID: <DSNlSoQ7EXxmctWrMZmLXsl302ZDwdjRNufp-G8S2Z4=.ecc1050c-7e10-4ae7-83fd-39624a6aa59f@github.com>

Modify the `handleAvailable` native code path to ignore an `ERROR_INVALID_FUNCTION` encountered by `PeekNamedPipe` and update an existing test to verify this change.

-------------

Commit messages:
 - 8342086: FileInputStream.available() fails with "Incorrect function" for "nul" path (win)

Changes: https://git.openjdk.org/jdk/pull/21543/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21543&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342086
  Stats: 34 lines in 2 files changed: 17 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21543.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21543/head:pull/21543

PR: https://git.openjdk.org/jdk/pull/21543

From sspitsyn at openjdk.org  Wed Oct 16 17:04:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 17:04:10 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Wht-tuuGDZt_XliGWoBzXmQRNiY5xe-nsYusevJtHoE=.e68c0c34-0007-4098-a631-99c640b7f989@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
 <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>
 <Wht-tuuGDZt_XliGWoBzXmQRNiY5xe-nsYusevJtHoE=.e68c0c34-0007-4098-a631-99c640b7f989@github.com>
Message-ID: <wdqAxZs9snttDKfZBWWy7M9Eu4MfTxG_Musdo7h6NIQ=.bcf31986-8690-4be2-9b1d-bb2aac5aade3@github.com>

On Wed, 16 Oct 2024 14:50:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The method `java/lang/VirtualThread$VThreadContinuation$1.run()` is starting and finishing in a VTMS transition. The issue is with the JVMTI `NotifyFramePop`. We need a way to disallow adding `FramePop` event requests to its frame because such requests cause problems because they are not used to post a `FramePop` events nor they are properly cleared. The annotation `@JvmtiMountTransition` is needed to help with this. I'm trying to move the `notifyJvmtiStart()/notifyJvmtiEnd()` calls to earlier frame to reduce a little bit the scope of VTMS transition. What do you think is the best place to explain it? Would placed a comment before annotation `@JvmtiMountTransition` for method `java/lang/VirtualThread$VThreadContinuation$1.run()` good enough?
>
> No issue from me on moving the notifications to the run method. My comment was more for the JvmtiMountTransition's class description as it's not easy to audit the use of this annotation.

Got it, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803494459

From bpb at openjdk.org  Wed Oct 16 17:09:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Oct 2024 17:09:10 GMT
Subject: RFR: 8342083: Make a few fields in FileSystemPreferences final
In-Reply-To: <nmDjJHEue_WGeD-ipZtWp3aUfmjNonrOo0cfyl3Am6Q=.17200a50-48cd-4528-95d5-2a66c7476d52@github.com>
References: <nmDjJHEue_WGeD-ipZtWp3aUfmjNonrOo0cfyl3Am6Q=.17200a50-48cd-4528-95d5-2a66c7476d52@github.com>
Message-ID: <PPzoWrcHKNK14k8JVcLtSGBTYKCNEPFWIe-T9L3lMoM=.3e24f0bf-852e-4ee8-bfa3-6a7a796b1208@github.com>

On Mon, 23 Sep 2024 09:13:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 8342083: Make a few fields in FileSystemPreferences final

Looks all right.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21131#pullrequestreview-2373154059

From sspitsyn at openjdk.org  Wed Oct 16 17:18:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 17:18:12 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
Message-ID: <GH6Lkdk_VrzpvduntPwY9UqIU0ToczM26x4N3Zo-_2o=.21352569-e25a-4b67-9969-d657888df1ba@github.com>

On Tue, 15 Oct 2024 21:21:07 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1814:
> 
>> 1812:   }
>> 1813:   // pure continuations have no VTMS transitions but they use methods annotated with JvmtiMountTransition
>> 1814:   if ((mh->jvmti_mount_transition() && state->is_virtual()) || thread->is_in_any_VTMS_transition()) {
> 
> Could you please explain the change (and other similar changes in jvmtiExport.cpp)
> Before events were not posted for any `@JvmtiMountTransition` methods, and now only for virtual threads? I.e. events for `@JvmtiMountTransition` methods of carrier threads are posted?

Good question. Some `jvmtiNotify*` notifications can be called in a context of carrier thread and exited in a context of virtual thread and vice versa. So, you are right we should not post these events for `@JvmtiMountTransition` methods, in a context of carrier threads.

So, we need to adjust these conditions even more with something like below:

-  if ((mh->jvmti_mount_transition() && state->is_virtual()) || thread->is_in_any_VTMS_transition()) {
+  if ((mh->jvmti_mount_transition() && (state->is_virtual() || thread->last_continuation() == nullptr)) ||
+    thread->is_in_any_VTMS_transition()) {
     return; // no events should be posted if thread is in any VTMS transition
   }

The check for `thread->last_continuation() == nullptr` will help to skip these events for carrier threads as well but won't skip them for pure continuations. In fact, I do not like the complexity of this check. :(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803512093

From jbhateja at openjdk.org  Wed Oct 16 17:29:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 17:29:04 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  New IR tests + additional IR transformations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/506ae299..c5650889

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=23-24

  Stats: 1010 lines in 7 files changed: 1007 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Wed Oct 16 17:29:05 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 17:29:05 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v24]
In-Reply-To: <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <lfASkEM4RP-PALK3Ok3HZHYjmHFXanlcnKy3mNBNcDk=.65baefcc-50fb-465a-a7d1-739817fc89ea@github.com>
 <704HcEgAdeR1380vEK4z0bG0KiJ1kjRVSBCa9EFrt0w=.bee85693-033c-4d85-9f89-3e186ca3c2fb@github.com>
Message-ID: <Rg-rMYpuDQfTSKxczEBiO_DHiTbwViV9kwHAKt2HI2Q=.3fd9f71f-a70c-4bb1-b0ae-713a1bb8239e@github.com>

On Tue, 15 Oct 2024 10:17:40 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update adlc changes.
>
> src/hotspot/share/opto/vectornode.hpp line 161:
> 
>> 159:   // Needed for proper cloning.
>> 160:   virtual uint size_of() const { return sizeof(*this); }
>> 161:   bool is_unsigned() { return _is_unsigned; }
> 
> Can you put this in the `print_spec`, so the IR dump shows if it is unsigned?

I think you meant Node::dump_spec. Its a good suggestions, addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1803527017

From eirbjo at openjdk.org  Wed Oct 16 17:34:22 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 16 Oct 2024 17:34:22 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
Message-ID: <LNGPAIR4G8JGbGW_EtrisR9f-p9Qed7msLq7c4chU_Y=.e12592b2-bbb0-4b30-8778-d2308a4ee2a5@github.com>

On Wed, 16 Oct 2024 14:55:34 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

I like this change a lot.

The PR /JBS title does not describe the actual change proposed here. Perhaps something like "Add concise usage message to the java launcher" would be more descriptive?

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 239:

> 237: \Where <application> is one of:\n\
> 238: \  <MainClass>                to execute the main method of a compiled class\n\
> 239: \  -jar <JarFile>.jar         to execute the main class of a JAR archive\n\

I know @magicus suggested `<JarFile>` for consistency with other options.

Perhaps bike shedding, but consider that JAR file names in the wild are predominately lower-case, not CamelCase. At least this is the convention the open source ecosystem.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21411#pullrequestreview-2373203062
PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1803530439

From eirbjo at openjdk.org  Wed Oct 16 17:41:14 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 16 Oct 2024 17:41:14 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
Message-ID: <UdmVa_Bz2ey3j8gGHM_nOgGRXI3cUJeIUVc3mOi4YgU=.ea8d70c7-589e-4e51-a8b3-e4bf0bd90465@github.com>

On Wed, 16 Oct 2024 14:55:34 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

The file separator is a secondary concern and could be moved to the end of the sentence:


Where key java options include:
  --class-path <class path>
      a list of directories and JAR archives to search for class files, separated by ":"
  --module-path <module path>
      a list of directories and JAR archives to search for modules, separated by ":"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2417488461

From lancea at openjdk.org  Wed Oct 16 17:45:52 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 16 Oct 2024 17:45:52 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account the
 size of a CEN header
Message-ID: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>

Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that

- ZipEntry(String)
- ZipEntry::setComment
- ZipEntry::setExtra

currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 

The CSR has been approved.
Mach5 tiers1-3 run clean as do the relevant JCK tests

-------------

Commit messages:
 - initial ZipEntry Max field size changes

Changes: https://git.openjdk.org/jdk/pull/21544/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340553
  Stats: 246 lines in 4 files changed: 201 ins; 21 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From liach at openjdk.org  Wed Oct 16 17:55:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 17:55:24 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v17]
In-Reply-To: <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <c79wtBWrtyaz-6eCWHdhPy88lTf6-T1hjqo_mIaY9LY=.0f87dadb-61b1-421c-80d8-8cd3fd60e0a8@github.com>
Message-ID: <JJspV-KE7HNaA2kjhdTWfoNvi3k67o8y3ld3GNcdBx4=.6ccab320-64a5-4812-b6b2-060508181d6f@github.com>

On Sun, 13 Oct 2024 11:18:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating tests to use floorMod

This patch failed on the lastest master. Another reason OpenJDK guide asks to merge master despite all these commit churns...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2417516748

From naoto at openjdk.org  Wed Oct 16 17:59:39 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Oct 2024 17:59:39 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST",
 and "HST" time zones
Message-ID: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>

Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.

-------------

Commit messages:
 - Merge branch 'master' into JDK-8340477-Remove-JDK11-compatible-behavior
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/21545/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21545&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340477
  Stats: 280 lines in 5 files changed: 1 ins; 266 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21545.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21545/head:pull/21545

PR: https://git.openjdk.org/jdk/pull/21545

From liach at openjdk.org  Wed Oct 16 17:59:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 17:59:44 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
Message-ID: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>

This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

-------------

Commit messages:
 - Revert "8338023: Support two vector selectFrom API"

Changes: https://git.openjdk.org/jdk/pull/21546/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21546&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342440
  Stats: 2805 lines in 89 files changed: 18 ins; 2786 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21546.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21546/head:pull/21546

PR: https://git.openjdk.org/jdk/pull/21546

From joehw at openjdk.org  Wed Oct 16 18:03:23 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 16 Oct 2024 18:03:23 GMT
Subject: RFR: 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: <8MHic1Yb7xtxtU0HM8yKLAjD2pYzTWs6Z6G-Adsqcvg=.e5ea6cd4-c3bd-44cb-9b9c-c87ed2f3d0b7@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...

Changes in source src/java.xml, JAXP tests under test/jaxp, look good. I double-checked my notes on the test changes, they were mostly about removing the runs with Security Manager.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2373273367

From rriggs at openjdk.org  Wed Oct 16 18:04:15 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Oct 2024 18:04:15 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
Message-ID: <wXJ6T4CGlgh73I5uOA82yLVrDzFmF27uZLKOItV4rT4=.3cabb4f1-4372-48bd-95aa-bba96676e0d0@github.com>

On Wed, 16 Oct 2024 14:55:34 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

src/java.base/share/native/libjli/java.c line 1924:

> 1922:  */
> 1923: static void
> 1924: PrintUsage(JNIEnv* env, jboolean doXUsage, jboolean conciseUsage)

This would be cleaner to replace the booleans with an enum (concise, X, full).
Since conciseUsage overrides doXusage, then it should preceed Xusage in the argument list.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1803573091

From kvn at openjdk.org  Wed Oct 16 18:06:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 16 Oct 2024 18:06:10 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <xpMxkk4rVHe-EYdkvgq-uO1vpiSga18esb7DlHeWRII=.839acb71-0bbd-424a-89df-45e90086663f@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21546#pullrequestreview-2373275510

From liach at openjdk.org  Wed Oct 16 18:06:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 18:06:10 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <cgijJg86n1G-4Uvxg_ynEgsgZ7eNWlwcrWU2jzZ2y5Y=.574fe06b-5678-4dc8-b6a1-8ea70f5ccd07@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

@jatin-bhateja The failure message is like:



/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp: In function 'Node* LowerSelectFromTwoVectorOperation(PhaseGVN&, Node*, Node*, Node*, const TypeVect*)':
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:2876:110: error: cannot convert 'const Type*' to 'BasicType'
 2876 |                                                                                    Type::get_const_basic_type(T_BYTE), false));
      |                                                                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      |                                                                                                              |
      |                                                                                                              const Type*
In file included from /home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:30:
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectornode.hpp:78:66: note:   initializing argument 3 of 'static VectorNode* VectorNode::scalar2vector(Node*, uint, BasicType, bool)'
   78 |   static VectorNode* scalar2vector(Node* s, uint vlen, BasicType bt, bool is_mask = false);
      |                                                        ~~~~~~~~~~^~
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:2887:101: error: cannot convert 'const Type*' to 'BasicType'
 2887 |                                                                           Type::get_const_basic_type(T_BYTE), false));
      |                                                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      |                                                                                                     |
      |                                                                                                     const Type*
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectornode.hpp:78:66: note:   initializing argument 3 of 'static VectorNode* VectorNode::scalar2vector(Node*, uint, BasicType, bool)'
   78 |   static VectorNode* scalar2vector(Node* s, uint vlen, BasicType bt, bool is_mask = false);
      |                                                        ~~~~~~~~~~^~
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp: In member function 'bool LibraryCallKit::inline_vector_select_from_two_vectors()':
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:3015:116: error: cannot convert 'const Type*' to 'BasicType'
 3015 |     Node* wrap_mask_vec = gvn().transform(VectorNode::scalar2vector(wrap_mask, num_elem, Type::get_const_basic_type(index_elem_bt), false));
      |                                                                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
      |                                                                                                                    |
      |                                                                                                                    const Type*
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectornode.hpp:78:66: note:   initializing argument 3 of 'static VectorNode* VectorNode::scalar2vector(Node*, uint, BasicType, bool)'
   78 |   static VectorNode* scalar2vector(Node* s, uint vlen, BasicType bt, bool is_mask = false);
      |                                                        ~~~~~~~~~~^~
lib/CompileJvm.gmk:168: recipe for target '/home/liach/java/jdk-5/build/linux-x64/hotspot/variant-server/libjvm/objs/vectorIntrinsics.o' failed
make[3]: *** [/home/liach/java/jdk-5/build/linux-x64/hotspot/variant-server/libjvm/objs/vectorIntrinsics.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [hotspot-server-libs] Error 2
make/Main.gmk:245: recipe for target 'hotspot-server-libs' failed
make[2]: *** Waiting for unfinished jobs....

ERROR: Build failed for target 'images' in configuration 'linux-x64' (exit code 2) 
Stopping javac server

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_vectorIntrinsics.o:
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp: In function 'Node* LowerSelectFromTwoVectorOperation(PhaseGVN&, Node*, Node*, Node*, const TypeVect*)':
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:2876:110: error: cannot convert 'const Type*' to 'BasicType'
 2876 |                                                                                    Type::get_const_basic_type(T_BYTE), false));
      |                                                                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      |                                                                                                              |
      |                                                                                                              const Type*
In file included from /home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:30:
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectornode.hpp:78:66: note:   initializing argument 3 of 'static VectorNode* VectorNode::scalar2vector(Node*, uint, BasicType, bool)'
   78 |   static VectorNode* scalar2vector(Node* s, uint vlen, BasicType bt, bool is_mask = false);
      |                                                        ~~~~~~~~~~^~
/home/liach/java/jdk-5/open/src/hotspot/share/opto/vectorIntrinsics.cpp:2887:101: error: cannot convert 'const Type*' to 'BasicType'
 2887 |                                                                           Type::get_const_basic_type(T_BYTE), false));
      |                                                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
      |                                                                                                     |
      |                                                                                                     const Type*
   ... (rest of output omitted)

* All command lines available in /home/liach/java/jdk-5/build/linux-x64/make-support/failure-logs.



If you can give a hotfix under the redo issue, we can merge that redo too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417540448

From jbhateja at openjdk.org  Wed Oct 16 18:06:10 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 18:06:10 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <7RIC5hbesOliqF966YUuT2h0E0I-VCFSkb45gkjxg3M=.b488c944-845f-473a-949a-d4c05bc19d3b@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

Let me fix it immediately if you can hold for few mins.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417541451

From liach at openjdk.org  Wed Oct 16 18:13:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 18:13:11 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <m-4AKc5MZBbASpEkFZvVLTIDdtfvhppZgvPVr6Wwcwg=.c79d162a-8b30-411f-b19d-33e97d819e86@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

Sure. Please reuse https://bugs.openjdk.org/browse/JDK-8342439 (feel free to edit the title and description to indicate this is a hotfix) for your hotfix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417562207

From jbhateja at openjdk.org  Wed Oct 16 18:13:11 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 18:13:11 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <m-4AKc5MZBbASpEkFZvVLTIDdtfvhppZgvPVr6Wwcwg=.c79d162a-8b30-411f-b19d-33e97d819e86@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
 <m-4AKc5MZBbASpEkFZvVLTIDdtfvhppZgvPVr6Wwcwg=.c79d162a-8b30-411f-b19d-33e97d819e86@github.com>
Message-ID: <PbpScMQTgaJwcVf0x9vHBAYLk349M6eI7SbFvG-7bXI=.94131d60-7213-41c8-9edc-bb33546ef69a@github.com>

On Wed, 16 Oct 2024 18:08:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Sure. Please reuse https://bugs.openjdk.org/browse/JDK-8342439 (feel free to edit the title and description to indicate this is a hotfix) for your hotfix.

Ok, fix is ready, I will update the title and fix as a build issue.  Thanks!!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417568437

From jbhateja at openjdk.org  Wed Oct 16 18:17:11 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 16 Oct 2024 18:17:11 GMT
Subject: RFR: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <9jBRhMABT7F6d5z9eSEQi9tTR351FaIlMaW29bJF6dw=.d8db4541-2600-464a-b159-cf71570e12ae@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

Please approve.

https://github.com/openjdk/jdk/pull/21547

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21546#issuecomment-2417577012

From liach at openjdk.org  Wed Oct 16 18:27:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 18:27:17 GMT
Subject: Withdrawn: 8342440: [BACKOUT] Support two vector selectFrom API
In-Reply-To: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
References: <UAi-vWY9POKwYNzPctAv-XTWLkzU1DlUqyq3Ye4BpzQ=.b5e85974-d56f-4e6e-abd7-bffbc0921d82@github.com>
Message-ID: <W5uX9uZCg940s0oL3j6alcsNIr0GIPtBPz8VAH8EHWw=.faa1e875-8611-4c05-b127-b7ac3ee96bde@github.com>

On Wed, 16 Oct 2024 17:49:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> This reverts commit 709914fc92dd180c8f081ff70ef476554a04f4ce, #20508. It was based against the master from a few months ago and caused build failures on all platforms upon integration. The reverted commit can build again on my personal machine.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21546

From bpb at openjdk.org  Wed Oct 16 18:45:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Oct 2024 18:45:11 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: <YLdkusUFdCpOgwx9Iftrmch5pWfBZ8QT0oujpawZICk=.f081bce2-7759-4c42-98e5-f35c7f5d9cab@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.

I verified that `PeekNamedPipe` also fails with `ERROR_INVALID_FUNCTION` when the supplied handle is `STD_INPUT_HANDLE`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21543#issuecomment-2417628951

From liach at openjdk.org  Wed Oct 16 18:48:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 16 Oct 2024 18:48:13 GMT
Subject: RFR: 8342336: Optimize ClassFile imports [v2]
In-Reply-To: <sByYiVJmnNO2JcS1tPFP_2cPbl8EKazsW3z4Wu5kC-g=.61c92e7d-85ed-4026-9fce-b1abbae39dc9@github.com>
References: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
 <sByYiVJmnNO2JcS1tPFP_2cPbl8EKazsW3z4Wu5kC-g=.61c92e7d-85ed-4026-9fce-b1abbae39dc9@github.com>
Message-ID: <F-CnOJZkPqCh5G9Xu1qKw_5bkTj5fsj0haxzdKoiKuE=.c47f2f32-47a8-4833-8a4e-e8bb2e04b2e5@github.com>

On Wed, 16 Oct 2024 16:24:55 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a code style improvement for imports in the java/lang/classfile and jdk/internal/classfile/impl directories, includes:
>> 1. Import in alphabetical order
>> 2. Add a blank line between java and jdk imports
>> 3. Use import * for a large number of imports
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Verified this matches the IDE formatting rule:

- java packages
- blank line
- other packages
- blank line
- static java packages
- static other packages

With an limit of 7 for using star for non-static imports.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21482#pullrequestreview-2373380060

From jlu at openjdk.org  Wed Oct 16 18:52:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 16 Oct 2024 18:52:10 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones
In-Reply-To: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
Message-ID: <SuLj3yxq7LozUjG6FAec-u8damRdSy4ZSq_H16Jvp2E=.d7fafe67-56b6-4741-9843-5a9c6faf8589@github.com>

On Wed, 16 Oct 2024 17:46:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 239:

> 237:                 case "EST" -> aliases.put("EST", "America/Panama");
> 238:                 case "MST" -> aliases.put("MST", "America/Phoenix");
> 239:                 default -> aliases.put(key, ZoneId.SHORT_IDS.get(key));

"EST" and "MST" case are no longer needed? ZoneId should already map them to "America/Panama" and "America/Phoenix". We no longer offer the old mapping, so we can safely follow ZoneId.SHORT_IDS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21545#discussion_r1803613511

From naoto at openjdk.org  Wed Oct 16 19:39:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Oct 2024 19:39:44 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v2]
In-Reply-To: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
Message-ID: <WPIYP7aNkeVdz3TfNnbRCMa9KyZwRRkCqzKcR2TQQWk=.1ff347c2-6f19-4658-a0e0-de178d3c3584@github.com>

> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21545/files
  - new: https://git.openjdk.org/jdk/pull/21545/files/459c6508..0cae3eba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21545&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21545&range=00-01

  Stats: 13 lines in 1 file changed: 2 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21545.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21545/head:pull/21545

PR: https://git.openjdk.org/jdk/pull/21545

From naoto at openjdk.org  Wed Oct 16 19:39:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Oct 2024 19:39:44 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v2]
In-Reply-To: <SuLj3yxq7LozUjG6FAec-u8damRdSy4ZSq_H16Jvp2E=.d7fafe67-56b6-4741-9843-5a9c6faf8589@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
 <SuLj3yxq7LozUjG6FAec-u8damRdSy4ZSq_H16Jvp2E=.d7fafe67-56b6-4741-9843-5a9c6faf8589@github.com>
Message-ID: <u2xBZSJgbOAEhiAtrGuk1PjKapsLGqYkPuSfDvWVO2Y=.966ccdad-ff73-4db0-a302-5fa217e9232c@github.com>

On Wed, 16 Oct 2024 18:33:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 239:
> 
>> 237:                 case "EST" -> aliases.put("EST", "America/Panama");
>> 238:                 case "MST" -> aliases.put("MST", "America/Phoenix");
>> 239:                 default -> aliases.put(key, ZoneId.SHORT_IDS.get(key));
> 
> "EST" and "MST" case are no longer needed? ZoneId should already map them to "America/Panama" and "America/Phoenix". If we no longer offer the old mapping, then we can safely follow ZoneId.SHORT_IDS.

Right. Removed them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21545#discussion_r1803689515

From psandoz at openjdk.org  Wed Oct 16 19:47:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 16 Oct 2024 19:47:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
Message-ID: <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>

On Wed, 16 Oct 2024 17:29:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New IR tests + additional IR transformations

Rather than adding more IR test functionality to this PR that requires additional review my recommendation would be to follow up in another PR or before hand rethink our approach.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2417790144

From naoto at openjdk.org  Wed Oct 16 19:59:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Oct 2024 19:59:44 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v3]
In-Reply-To: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
Message-ID: <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>

> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refined it more

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21545/files
  - new: https://git.openjdk.org/jdk/pull/21545/files/0cae3eba..d187e83f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21545&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21545&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21545.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21545/head:pull/21545

PR: https://git.openjdk.org/jdk/pull/21545

From mullan at openjdk.org  Wed Oct 16 20:17:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:17:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
Message-ID: <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>

On Wed, 16 Oct 2024 15:53:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> **SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.
>> 
>> --------------------------------------------------------------------------------
>> 
>> See?also:
>> - https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565
>
> We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.

Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803740577

From iris at openjdk.org  Wed Oct 16 20:36:11 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 16 Oct 2024 20:36:11 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v3]
In-Reply-To: <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
 <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
Message-ID: <Ft-Ww1-Hkz5km-RHL8p8hekP00moNzsTUiiLijGa-qw=.92c84364-4a68-411f-b566-f0c86a85ba4a@github.com>

On Wed, 16 Oct 2024 19:59:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined it more

Happy to see this 1.1-era behaviour support removed.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21545#pullrequestreview-2373620409

From mullan at openjdk.org  Wed Oct 16 20:45:38 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:45:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
 <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
Message-ID: <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>

On Wed, 16 Oct 2024 06:58:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ok, I will revert it.
>
> The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.

Phil, if you have better wording for the `@throws SecurityException` of these methods, let me know; otherwise I will restore the paragraph above and below and keep the current text for `SecurityException` the same as it is now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803774792

From mullan at openjdk.org  Wed Oct 16 20:54:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:54:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
Message-ID: <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>

On Wed, 16 Oct 2024 13:28:47 GMT, Weijun Wang <weijun 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, ...
>
> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * This class is for GSS security context permissions.
> 
> Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.

In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.

If there are other Permission classes you think should have their text modified or removed, let me know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803784698

From sspitsyn at openjdk.org  Wed Oct 16 21:35:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 21:35:13 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
Message-ID: <YPPZC3V_vOYyzZYGH1So3idNb0sljMR77lQjBbpDWlc=.5e0a9375-8b8c-462c-bd8b-eb6b45a7c237@github.com>

On Wed, 16 Oct 2024 08:00:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 221:
> 
>> 219:                     vthread.notifyJvmtiStart();
>> 220: 
>> 221:                     vthread.run(task);
> 
> This doesn't look right, it needs to use try-finally.

The discussion on this is on the next comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803823069

From sspitsyn at openjdk.org  Wed Oct 16 21:35:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 21:35:14 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <o14TpC8BDBHSu7XLm5HD1rT09n1_QOA4JiWdrAZaXQU=.40a2907b-4411-41cb-aa33-4bac68816551@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
 <NsgSgLhaiapaU1V95cAeyu0G8Tw1nHr2LN4kductRGk=.827476cf-272f-4e73-9410-f63c0e510b06@github.com>
 <o14TpC8BDBHSu7XLm5HD1rT09n1_QOA4JiWdrAZaXQU=.40a2907b-4411-41cb-aa33-4bac68816551@github.com>
Message-ID: <WMfl08hvl1oyOU095Gw6suO8h5BaM_FHwN8ZkgFmbLo=.2cd9f2cc-192c-4028-a4b7-c2497435b108@github.com>

On Wed, 16 Oct 2024 14:38:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank you for the comment. I can move the try-finally to the method `java/lang/VirtualThread$VThreadContinuation$1.run()` if you prefer. But it will play the same role functionally.
>
> Changing the run method to
> 
> vthread.notifyJvmtiStart();
> try {
>     vthread.run(task);
> } finally {
>     vthread.notifyJvmtiEnd();
> }
> 
> is okay. I was initially puzzled because the run method is already`@Hidden` but I don't think this is used by JVMTI.

Thanks. Yes, the annotation `@Hidden` is not used by the JVMTI. It would be tricky to use it consistently.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803823267

From jlu at openjdk.org  Wed Oct 16 22:21:12 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 16 Oct 2024 22:21:12 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v3]
In-Reply-To: <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
 <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
Message-ID: <zt1ayb697khnZZkAVhBc92Rwblx5GpOUEHACIYTv7f0=.10876cc5-c021-4ca2-a2b8-a5f2c9a23b79@github.com>

On Wed, 16 Oct 2024 19:59:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined it more

LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21545#pullrequestreview-2373781332

From sspitsyn at openjdk.org  Wed Oct 16 22:38:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 22:38:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <ZRUxgwPVnJGTEpvUCRz_sR-b6-LcnJeK5cl_bo9037M=.84eca85d-a9a3-4a2d-ba95-8c8bfa56a241@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
 <ZRUxgwPVnJGTEpvUCRz_sR-b6-LcnJeK5cl_bo9037M=.84eca85d-a9a3-4a2d-ba95-8c8bfa56a241@github.com>
Message-ID: <B2BCbltQWn5L4x0qVMQ75Dyl56j6ZakN2okM5Xt8hl4=.ad0bb373-dfa7-4f45-a469-f0eb944f0bc5@github.com>

On Tue, 15 Oct 2024 21:59:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 692:
>> 
>>> 690:   if (jt->is_in_VTMS_transition()) {
>>> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
>>> 692:   } else if (is_virtual) { // filter out pure continuations
>> 
>> Not sure I follow the logic here.
>> As far as I understand yield/yield need to be filtered out only for unmounted virtual threads. But `is_virtual` here means we have mounted VT?
>> Looks like almost all callers call this method only if `jt->is_in_JTMS_transilition()` is true
>> Exception is a call from `get_vthread_jvf()` when vthread is mounted.
>
> This seems to be a good catch. The call to `skip_top_jvmti_annotated_frames()` should not be needed.
> It does not harm either, so I've added it for safety.
> Will remove it and rerun mach5 tiers to make sure there is nothing unexpected.

Please, hold on. My last comment was not fully incorrect.
Not only `yield()/yield0()` need to be filtered out for virtual threads.
There are more cases for a `JavaThread` which is not in a VTMS transition executing a virtual thread. All the calls below represents inconsistency and must be hidden:

 - `notifyJvmtiStart()`: This function is called in a VTMS MOUNT transition which it ends. So its return happens with the thread identity `VIRTUAL`.
 - `notifyJvmtiEnd()`: This function is called with the thread identity `VIRTUAL`. It is starting a VTMS UNMOUNT transition, so its return happens in a VTMS transition.
 - `notifyJvmtiMount(false)`:  This call happens in a VTMS transition. It finishes the VTMS transition and its return happen with the thread identity 'VIRTUAL'.
 - `notifyJvmtiUnmount(true)`:  This call happens with the thread identity 'VIRTUAL'. It starts a VTMS UNMOUNT transition, so its return happens in a VTMS transition.

I've just discovered that we have two more cases to hide frames for carrier threads that are NOT in a VTMS transitions:
- `notifyJvmtiMount(true)`: This call happens with the thread identity `CARRIER`. It starts a VTMS MOUNT transition, so its return happens in a VTMS transition.
 - `notifyJvmtiUnmount(false)`:  This call happens in a VTMS UNMOUNT transition. It finishes transition, so its return happens with the thread identity `CARRIER`.

An update is needed for these two cases.
All the cases above can be potentially observed at a safepoint/handshake in a non-transitioned state.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803874831

From ccheung at openjdk.org  Wed Oct 16 22:51:21 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 16 Oct 2024 22:51:21 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option
Message-ID: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>

Summary of changes:

Before dumping info the archive, all the module names from `--add-modules` will be sorted and then concatenated into one string with comma as the separator between module names.

During runtime, same function will be used to obtain the string in the same format with sorted module names. The string will be compared with the one from the archive to determine if the same module names were specified during dump time.

ModuleBootstrap.java
        The `addModulesFromRuntimeImage` method is added to check if the modules in `addModules` are from the runtime image. If any of the modules isn't in the runtime image, archiving will be disabled.

ArchivedModuleGraph.java
       The constructor has an addition argument `Set addModules`
       The `get` method also has an addition argument `Set addModules`. It returns the `archivedModuleGraph` only if both the `mainModule` and the `addModules` are the same as the input arguments.

Passed tiers 1 - 4 testing.

-------------

Commit messages:
 - 8319343: Improve CDS module graph support for --add-modules option
 - Merge branch 'master' into 8319343-add-modules
 - update test
 - Merge
 - simplify vm changes
 - Merge branch 'master' into 8319343-add-modules
 - 8319343: Improve CDS module graph support for --add-modules option

Changes: https://git.openjdk.org/jdk/pull/21553/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21553&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319343
  Stats: 367 lines in 12 files changed: 346 ins; 3 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/21553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21553/head:pull/21553

PR: https://git.openjdk.org/jdk/pull/21553

From asemenyuk at openjdk.org  Wed Oct 16 22:52:48 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 16 Oct 2024 22:52:48 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree
Message-ID: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>

Make jpackage correctly handle the output directory (`--dest`) that is:
 - a subdirectory of the input directory;
 - the same as the input directory.

Make jpackage correctly handle temp directory (`--temp`) that is:
 - a subdirectory of the input directory.

jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.

The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.

`IOUtils. copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.

The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.

-------------

Commit messages:
 - Bugfix
 - Fix typo and trailing whitespaces
 - Fix JPackageCommand.execute(): remove existing output bundle (package file or app image folder) based on its type (file/directory) and not on the type of jpackage command (app image/package).
 - Make jpackage work properly when input and output directories are the same
 - Fix trailing whitespaces
 - Add commands
 - Minor improvements to simplify test debug and allow reruns on non-empty work directory
 - Add support to test jpackage execution without `--dest` parameter specified. Added BasicTest.testNoOutputDir() to test jpackage execution without `--dest` parameter.
 - Follow up change for DeployParams chnages
 - Fix packaging tests
 - ... and 5 more: https://git.openjdk.org/jdk/compare/5eae20f7...7e3ad9ce

Changes: https://git.openjdk.org/jdk/pull/21550/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325089
  Stats: 376 lines in 12 files changed: 318 ins; 24 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/21550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21550/head:pull/21550

PR: https://git.openjdk.org/jdk/pull/21550

From asemenyuk at openjdk.org  Wed Oct 16 22:52:48 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 16 Oct 2024 22:52:48 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree
In-Reply-To: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
Message-ID: <wNPjiqiH0AgpXFukp5KAEapFn0bBKDZ0Gj1Bv-0vTJk=.989cca7e-aace-440f-9d4d-6328bbd20c72@github.com>

On Wed, 16 Oct 2024 18:45:38 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage correctly handle the output directory (`--dest`) that is:
>  - a subdirectory of the input directory;
>  - the same as the input directory.
> 
> Make jpackage correctly handle temp directory (`--temp`) that is:
>  - a subdirectory of the input directory.
> 
> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
> 
> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
> 
> `IOUtils. copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
> 
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
> 
> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.

@sashamatveev please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21550#issuecomment-2418098284

From jlu at openjdk.org  Wed Oct 16 22:53:46 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 16 Oct 2024 22:53:46 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex Implementation
 Limit
Message-ID: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>

Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.

Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21554/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335271
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21554/head:pull/21554

PR: https://git.openjdk.org/jdk/pull/21554

From asmehra at openjdk.org  Wed Oct 16 23:01:15 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 16 Oct 2024 23:01:15 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
Message-ID: <P2bNpw2Ke20lBr7tLUfXdnwjqmPiEFqBchB2naVSgJ4=.c42ea920-e67c-4312-ad82-e11944747168@github.com>

On Wed, 16 Oct 2024 02:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo in last commit; fixed header inclusion order

src/hotspot/share/cds/heapShared.cpp line 675:

> 673:     const char* klass_name = info->klass_name;
> 674:     for (; fields[i].valid(); i++) {
> 675:       ArchivableStaticFieldInfo* f = &fields[i];

It looks like the pattern of nested for-loops is copied from HeapShared::archive_object_subgraphs()
but this pattern doesn't seem to give any advantage here. If so can we replace it with just single for loop to make it easier to understand?

src/hotspot/share/cds/heapShared.cpp line 717:

> 715: };
> 716: 
> 717: void HeapShared::find_archivable_hidden_classes_in_object(oop root) {

If this function find archivable hidden classes, shouldn't there be a check for`is_hidden()` on the InstanceKlass being marked as `required`. Am I missing something?

src/hotspot/share/cds/heapShared.cpp line 790:

> 788: 
> 789:   init_seen_objects_table();
> 790:   {

Why was this scope introduced?

src/hotspot/share/classfile/systemDictionaryShared.cpp line 675:

> 673: 
> 674: // Returns true if the class should be excluded. This can be called before
> 675: // SystemDictionaryShared::check_excluded_classes().

There are a couple of references to check_excluded_classes() in the comments but this function no longer exists. Can you please update the comment accordingly.

src/hotspot/share/classfile/systemDictionaryShared.cpp line 759:

> 757:       if (k->is_hidden() && should_hidden_class_be_archived(k)) {
> 758:         SystemDictionaryShared::check_for_exclusion(k, &info);
> 759:         if (info.is_excluded()) {

Is it possible that a hidden class for which `should_hidden_class_be_archived()` returns true is marked for exclusion by `SDS::check_for exclusion`? I guess only possibility is if for some reason its super or interface is excluded. Is that possible?

src/hotspot/share/classfile/systemDictionaryShared.cpp line 775:

> 773:   // Now, all hidden classes that have not yet been scanned must be marked as excluded
> 774:   auto exclude_remaining_hidden = [&] (InstanceKlass* k, DumpTimeClassInfo& info) {
> 775:     if (k->is_hidden() && !info.has_checked_exclusion()) {

Suggestion: Check for `has_checked_exclusion()` is not really required as the call to `SDS::check_for_exclusion()` does that. And the condition in `guarantee()` can be updated as `info.is_excluded() || info.is_required()`.

src/hotspot/share/oops/constantPool.cpp line 340:

> 338:     src_cp->iterate_archivable_resolved_references([&](int rr_index) {
> 339:       keep_resolved_refs.at_put(rr_index, true);
> 340:       });

Indentation seems off here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803888327
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803887158
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803887567
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803887919
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803887979
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803888011
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803889248

From jlu at openjdk.org  Wed Oct 16 23:04:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 16 Oct 2024 23:04:10 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v3]
In-Reply-To: <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
 <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
Message-ID: <eCTwZtuXelU9rTZqvBBd623G6LLlq049pJfpL_AOxWs=.a6f70b80-e14f-4c32-917a-5c400dd1701c@github.com>

On Wed, 16 Oct 2024 19:59:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined it more

BTW, can we go even further and remove "EST", "HST" and "MST" from `SHORT_IDS`? IIUC the basis for keeping those 3 specifically as part of `SHORT_IDS` was the conflicting 1.1 behavior. Now that the old mapping is removed, those 3 will always map to the TZDB data, which has them as valid links in _backwards_ instead of the previous fixed offset zones.

Or is there some other reason to keep them at this point? I guess there is also no benefit to incentivize the usage of _any_ 3 letter zone ID.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21545#issuecomment-2418110547

From asemenyuk at openjdk.org  Wed Oct 16 23:09:47 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 16 Oct 2024 23:09:47 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v2]
In-Reply-To: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
Message-ID: <Twv2ERu5NUTO2umV40ne1GgAnlD6Mw76BAxDeA9pD88=.51fe8bfe-c888-4978-906d-787c95a2fddc@github.com>

> Make jpackage correctly handle the output directory (`--dest`) that is:
>  - a subdirectory of the input directory;
>  - the same as the input directory.
> 
> Make jpackage correctly handle temp directory (`--temp`) that is:
>  - a subdirectory of the input directory.
> 
> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
> 
> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
> 
> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
> 
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
> 
> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Use jdk.jpackage.test.Annotations.Parameter annotation to parameterize packaging type in the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21550/files
  - new: https://git.openjdk.org/jdk/pull/21550/files/7e3ad9ce..20f30152

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=00-01

  Stats: 18 lines in 1 file changed: 3 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21550/head:pull/21550

PR: https://git.openjdk.org/jdk/pull/21550

From asmehra at openjdk.org  Wed Oct 16 23:18:14 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 16 Oct 2024 23:18:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
Message-ID: <vlnQGlbG7NDzWUc_gJWL6qO7pDIfmnww-JBHGiH-2zs=.3a3e0644-ea17-42aa-96de-d0d024e19f87@github.com>

On Wed, 16 Oct 2024 02:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo in last commit; fixed header inclusion order

@iklam Changes to move main module name from modules.cpp to elsewhere do not look related to AOT-linking of indy. If so, can they be done in a separate PR.

src/hotspot/share/cds/dumpTimeClassInfo.hpp line 45:

> 43:   bool                         _is_early_klass;
> 44:   bool                         _has_checked_exclusion;
> 45:   bool                         _is_required;

Is this flag only used for hidden classes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2418123427
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1803900416

From naoto at openjdk.org  Wed Oct 16 23:18:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Oct 2024 23:18:09 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v3]
In-Reply-To: <eCTwZtuXelU9rTZqvBBd623G6LLlq049pJfpL_AOxWs=.a6f70b80-e14f-4c32-917a-5c400dd1701c@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
 <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
 <eCTwZtuXelU9rTZqvBBd623G6LLlq049pJfpL_AOxWs=.a6f70b80-e14f-4c32-917a-5c400dd1701c@github.com>
Message-ID: <4idCHeN7Cd2wQ6zqL7DuXw__nTBIt9CTNJEC6fXWKBI=.421e7eda-3e7d-4bb3-9163-2ebd5b27ba2c@github.com>

On Wed, 16 Oct 2024 23:01:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> BTW, can we go even further and remove "EST", "HST" and "MST" from `SHORT_IDS`? IIUC the basis for keeping those 3 specifically as part of `SHORT_IDS` was the conflicting 1.1 behavior. Now that the old mapping is removed, those 3 will always map to the TZDB data, which has them as valid links in _backwards_ instead of the previous fixed offset zones.

Data conflict with TZDB is not the reason to keep them in `SHORT_IDS`, but they are defined as time zone ids in JDK1.1, as well as others in `SHORT_IDS` is the reason. They are all deprecated, so ideally we remove them altogether, but I expect that would break apps.

That said, it might be useful we log warnings if apps use them, then we may be able to indeed remove them in future releases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21545#issuecomment-2418124218

From jrose at openjdk.org  Wed Oct 16 23:21:11 2024
From: jrose at openjdk.org (John R Rose)
Date: Wed, 16 Oct 2024 23:21:11 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option
In-Reply-To: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
Message-ID: <6P1MFspA8SfNszgZhbSfEsfiox-cYJJiUM-8WZTdklY=.d9423f78-260d-42e2-9b67-6a9831bd1f3d@github.com>

On Wed, 16 Oct 2024 22:46:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Summary of changes:
> 
> Before dumping info the archive, all the module names from `--add-modules` will be sorted and then concatenated into one string with comma as the separator between module names.
> 
> During runtime, same function will be used to obtain the string in the same format with sorted module names. The string will be compared with the one from the archive to determine if the same module names were specified during dump time.
> 
> ModuleBootstrap.java
>         The `addModulesFromRuntimeImage` method is added to check if the modules in `addModules` are from the runtime image. If any of the modules isn't in the runtime image, archiving will be disabled.
> 
> ArchivedModuleGraph.java
>        The constructor has an addition argument `Set addModules`
>        The `get` method also has an addition argument `Set addModules`. It returns the `archivedModuleGraph` only if both the `mainModule` and the `addModules` are the same as the input arguments.
> 
> Passed tiers 1 - 4 testing.

src/hotspot/share/classfile/modules.cpp line 697:

> 695:       st.print("%s%s", prefix, m);
> 696:       last_string = m;
> 697:       prefix = ",";

You use comma as the separator.  Folks will have various opinions, but I think you should use a character which is positively forbidden by the JVMS 4.2.3.  That says, basically, that any character is fine (in the classfile format) EXCEPT control characters.  The most visible control character is probably `'\n'` so I suggest using that instead of comma.  Your key-strings will look like groups of sorted lines, one module name per line.  That's plenty readable.

If you keep comma, nothing will break, unless some smart guy figures out how to cook up a classfile that has a module name in it with a comma inside, that looks like two other legitimate modules names separated by that comma.  Something odd could happen next.  Better to avoid it from the start by using a truly illegal module name character.

(If these were class names I'd be suggesting `';'` or `'.'` not `'\n'` because the rules for class names are different, in the JVMS.  Again, none of these issues come up with inputs which are compiled from normal Java sources, but they can appear with craftily crafted classfiles.)

https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.2.3

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21553#discussion_r1803902019

From dholmes at openjdk.org  Thu Oct 17 00:06:16 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Oct 2024 00:06:16 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
Message-ID: <SJjuzK26-rhCkMC5gzPJS92YFHwPmocKzJE47NdWX5w=.0385c992-adfc-4033-ada1-54e54381a479@github.com>

On Wed, 16 Oct 2024 14:55:34 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 49:

> 47: \    -classpath <class search path of directories and zip/jar files>\n\
> 48: \    --class-path <class search path of directories and zip/jar files>\n\
> 49: \                  A "{0}"-separated list of directories, JAR archives,\n\

The usual way to express this is with the word i.e. comma-separated, semi-colon-separated and colon-separated. Not sure if that is possible given the way substitution happens here. Though you could do what the manpage does i.e.

Specifies a list of directories, JAR files, and ZIP archives to search for class files.
On Windows, semicolons (;) separate entities in this list; on other platforms it is a colon (:).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1803929464

From bpb at openjdk.org  Thu Oct 17 00:10:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 00:10:24 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on file
 junction points
Message-ID: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>

Improve support for Windows directory junctions.

-------------

Commit messages:
 - 8069345: (fs) FileTreeWalker throws NotDirectoryException on file junction points

Changes: https://git.openjdk.org/jdk/pull/21555/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21555&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8069345
  Stats: 712 lines in 7 files changed: 690 ins; 4 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/21555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21555/head:pull/21555

PR: https://git.openjdk.org/jdk/pull/21555

From bpb at openjdk.org  Thu Oct 17 00:10:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 00:10:24 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points
In-Reply-To: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
Message-ID: <POxTe97-u93f3oIuLVSwSSRBrLmETzMYNP2yn737Wf4=.023817ab-d96c-4f6c-80dc-1413d832ff9f@github.com>

On Thu, 17 Oct 2024 00:05:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Improve support for Windows directory junctions.

A Windows directory junction is an empty (void) directory which has a reparse point with tag `IO_REPARSE_TAG_MOUNT_POINT` and a data buffer containing the name of the target of the junction, which must be an absolute path beginning with a drive letter. The  absolute path is usually expected to be to a directory, although it is possible, but perhaps non-standard, that it could be to a regular file. At present, directory junctions are in general handled transparently by Java in the same manner as symbolic links.

This request proposes to make directory junctions be seen as symbolic links by having `Files.isSymbolicLink(junction)` return `true` and to return the target of the directory junction from `Files.readSymbolicLink(junction)`. The behaviors of these two methods are the only visible changes.

Two tests are added to verify the expected behavior with junctions, one for `java.io` and the other for `java.nio.file`. Both of these tests already pass without the proposed source changes except for the sub-tests which verify the changes underlying the `Files.isSymbolicLink` and `Files.readSymbolicLink` methods on Windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2418188336

From ccheung at openjdk.org  Thu Oct 17 01:28:41 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 17 Oct 2024 01:28:41 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option [v2]
In-Reply-To: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
Message-ID: <MEXuMA7PWvze61-JglQK2hAASioMTgHz59zXFUJQNT0=.a07d3fdb-ced1-44a7-9a21-d29fd7c88c7c@github.com>

> Summary of changes:
> 
> Before dumping info the archive, all the module names from `--add-modules` will be sorted and then concatenated into one string with comma as the separator between module names.
> 
> During runtime, same function will be used to obtain the string in the same format with sorted module names. The string will be compared with the one from the archive to determine if the same module names were specified during dump time.
> 
> ModuleBootstrap.java
>         The `addModulesFromRuntimeImage` method is added to check if the modules in `addModules` are from the runtime image. If any of the modules isn't in the runtime image, archiving will be disabled.
> 
> ArchivedModuleGraph.java
>        The constructor has an addition argument `Set addModules`
>        The `get` method also has an addition argument `Set addModules`. It returns the `archivedModuleGraph` only if both the `mainModule` and the `addModules` are the same as the input arguments.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @rose00 comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21553/files
  - new: https://git.openjdk.org/jdk/pull/21553/files/e9729216..5c2783f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21553&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21553&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21553/head:pull/21553

PR: https://git.openjdk.org/jdk/pull/21553

From ccheung at openjdk.org  Thu Oct 17 01:28:42 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 17 Oct 2024 01:28:42 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option [v2]
In-Reply-To: <6P1MFspA8SfNszgZhbSfEsfiox-cYJJiUM-8WZTdklY=.d9423f78-260d-42e2-9b67-6a9831bd1f3d@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
 <6P1MFspA8SfNszgZhbSfEsfiox-cYJJiUM-8WZTdklY=.d9423f78-260d-42e2-9b67-6a9831bd1f3d@github.com>
Message-ID: <VMnv7qqlXVcPG4IbnH9BJLRgkgoPNwUgYBhAbsdGn-Y=.3bff0150-1963-4c59-9ff1-4dbe45205cb8@github.com>

On Wed, 16 Oct 2024 23:18:42 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @rose00 comment
>
> src/hotspot/share/classfile/modules.cpp line 697:
> 
>> 695:       st.print("%s%s", prefix, m);
>> 696:       last_string = m;
>> 697:       prefix = ",";
> 
> You use comma as the separator.  Folks will have various opinions, but I think you should use a character which is positively forbidden by the JVMS 4.2.3.  That says, basically, that any character is fine (in the classfile format) EXCEPT control characters.  The most visible control character is probably `'\n'` so I suggest using that instead of comma.  Your key-strings will look like groups of sorted lines, one module name per line.  That's plenty readable.
> 
> If you keep comma, nothing will break, unless some smart guy figures out how to cook up a classfile that has a module name in it with a comma inside, that looks like two other legitimate modules names separated by that comma.  Something odd could happen next.  Better to avoid it from the start by using a truly illegal module name character.
> 
> (If these were class names I'd be suggesting `';'` or `'.'` not `'\n'` because the rules for class names are different, in the JVMS.  Again, none of these issues come up with inputs which are compiled from normal Java sources, but they can appear with craftily crafted classfiles.)
> 
> https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.2.3

Thanks for taking a look, John.
I've made the change based on your suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21553#discussion_r1803986162

From bpb at openjdk.org  Thu Oct 17 01:37:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 01:37:01 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
Message-ID: <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>

> 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

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21555/files
  - new: https://git.openjdk.org/jdk/pull/21555/files/bbb8567b..7d9067f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21555&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21555&range=00-01

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21555/head:pull/21555

PR: https://git.openjdk.org/jdk/pull/21555

From duke at openjdk.org  Thu Oct 17 01:41:22 2024
From: duke at openjdk.org (duke)
Date: Thu, 17 Oct 2024 01:41:22 GMT
Subject: Withdrawn: 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: <tM6Uh9qN84v9oJBsFL_ghpQid4lmvOPWOJtukPNc7RI=.2779631e-5336-436b-ada2-19a5b45775fb@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 been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20179

From almatvee at openjdk.org  Thu Oct 17 02:02:12 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 17 Oct 2024 02:02:12 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v2]
In-Reply-To: <Twv2ERu5NUTO2umV40ne1GgAnlD6Mw76BAxDeA9pD88=.51fe8bfe-c888-4978-906d-787c95a2fddc@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
 <Twv2ERu5NUTO2umV40ne1GgAnlD6Mw76BAxDeA9pD88=.51fe8bfe-c888-4978-906d-787c95a2fddc@github.com>
Message-ID: <QcFfExHcJ2N9yYk3VoJA4dm7iwBx4lCEhXd3wl7T5_s=.0870394b-d748-4d58-920e-db606e67eb71@github.com>

On Wed, 16 Oct 2024 23:09:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make jpackage correctly handle the output directory (`--dest`) that is:
>>  - a subdirectory of the input directory;
>>  - the same as the input directory.
>> 
>> Make jpackage correctly handle temp directory (`--temp`) that is:
>>  - a subdirectory of the input directory.
>> 
>> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
>> 
>> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
>> 
>> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
>> 
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
>> 
>> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jdk.jpackage.test.Annotations.Parameter annotation to parameterize packaging type in the test

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21550#pullrequestreview-2373988618

From duke at openjdk.org  Thu Oct 17 03:40:10 2024
From: duke at openjdk.org (xxDark)
Date: Thu, 17 Oct 2024 03:40:10 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
Message-ID: <sKtWeZfeznbG3pLIsbqFDXY_sNIItNpZbAXR65SK2nA=.2d787fdc-7ac1-4271-8f2a-2f8e5fee540d@github.com>

On Tue, 15 Oct 2024 22:37:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8233451: Remove use of handleAvailable() (Windows)
>  - 8233451: Remove use of handleAvailable() (UNIX)

Hello.
I see that my [report](https://bugs.openjdk.org/browse/JDK-8341666) was closed as a duplicate of JDK-8233451 (the bug this PR fixes).
This does not resolve the situation with `FileInputStream`?
`java.io` will not be fixed? Practically none of the new API such as `readNBytes` could be used as it relies on calls to `lseek` on unix systems (this affects MacOS as well).
Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2418429142

From davidalayachew at gmail.com  Thu Oct 17 03:47:52 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 16 Oct 2024 23:47:52 -0400
Subject: Would it make sense to add a new constructor to
 java.io.SequenceInputStream?
Message-ID: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>

Hello Core Libs Dev Team,

Currently, java.io.SequenceInputStream only has 2 constructors -- one that
takes in 2 instances of InputStream, and another that takes in an
Enumeration of type InputStream.

Would it make sense to add a third constructor that takes in multiple
instances of InputStream? I don't know if a list, an array, varargs, etc
makes more sense. But I would think a 3rd constructor would improve this
API.

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/20241016/5087f1b3/attachment.htm>

From iklam at openjdk.org  Thu Oct 17 04:19:27 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Oct 2024 04:19:27 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @liach comments -- added comments; added asserts for HashMap safety in MethodType.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/4be6a255..7bab10b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=06-07

  Stats: 18 lines in 5 files changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Thu Oct 17 04:23:12 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Oct 2024 04:23:12 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <XVzsnY9pNVOn-p6DILd10hZz5_kA0kGfyMJRGD-k6qQ=.087aba1f-6291-422c-ae1c-84da9d90495e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <XVzsnY9pNVOn-p6DILd10hZz5_kA0kGfyMJRGD-k6qQ=.087aba1f-6291-422c-ae1c-84da9d90495e@github.com>
Message-ID: <GbvbMQ8CGtpGftw4BEsgJp9ynxpbo1dxqpZE0EHRWNM=.9d7eb7b8-eb30-4c17-9b02-beb7d8488566@github.com>

On Tue, 15 Oct 2024 19:42:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> I recommend adding javadoc or block comments indicating that `runtimeSetup`, `resetArchivedStates`, etc. are called by VM CDS code so people don't accidentally rename this and have unintended impact.

Done.

> src/java.base/share/classes/java/lang/invoke/MethodType.java line 404:
> 
>> 402:         MethodType primordialMT = new MethodType(rtype, ptypes);
>> 403:         if (archivedMethodTypes != null) {
>> 404:             MethodType mt = archivedMethodTypes.get(primordialMT);
> 
> The use of `HashMap` naturally feels alarming given this method is invoked in a concurrent context. I just want to make sure that:
> 
> 1. `HashMap` will never have structural modifications when read access is performed (some data structures like treap do). Don't know if we have a test to verify such an intended usage, as we would hurt badly if this implied property suddenly no longer exist.
> 2. The `archivedMethodTypes` must be properly published so we won't read a partial `HashMap`. I've heard of talks about concurrent VM bootstraping so I need some help to understand how this is ensured in bootstrap.

I added asserts to check that the HashMap is written only in the CDS dumping process, so at least we know it's not being modified when we read from it.

The CDS archived heap is either mmaped or read into memory while the VM is still in single threaded mode, so the entire content of the archived heap should be published for to all future threads.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2418466360
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1804080520

From iklam at openjdk.org  Thu Oct 17 04:23:14 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 17 Oct 2024 04:23:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v6]
In-Reply-To: <DB_AbfZbFKp1UoN9RQE0mQzKc6VufflWanWJSqO2v8I=.4b41450e-79af-44f1-9bc6-4e50d927b17c@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <XrqQBGf40sQ0Ytxj2TLd_2Jf1YyTFvF4qiIJTnmyoSs=.9862390d-cb74-4bb6-a961-d3e799606206@github.com>
 <DB_AbfZbFKp1UoN9RQE0mQzKc6VufflWanWJSqO2v8I=.4b41450e-79af-44f1-9bc6-4e50d927b17c@github.com>
Message-ID: <7rLnzKl2xG-icT2_QHOW0vhBa4A-CB_gFI3P3vO_zsc=.69679147-a49b-409d-881a-36837c4f5c67@github.com>

On Wed, 16 Oct 2024 05:13:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
>> 
>>  - @DanHeidinga comments -- added comments and asserts related to ClassLoaderData used by archived hidden classes
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/11391c39...a6ad908f
>
> src/hotspot/share/cds/heapShared.cpp line 447:
> 
>> 445: 
>> 446: bool HeapShared::is_string_concat_klass(InstanceKlass* ik) {
>> 447:   return ik->is_hidden() && ik->name()->starts_with("java/lang/String$$StringConcat");
> 
> Can you add a comment in `StringConcatFactory`'s place where this name is defined, so others who change the generated class name will remember to update references here?

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1804080661

From jpai at openjdk.org  Thu Oct 17 04:51:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Oct 2024 04:51:53 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Lance's man page inputs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/2752/files
  - new: https://git.openjdk.org/jdk/pull/2752/files/bb63acba..9ebbc06e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=14-15

  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

PR: https://git.openjdk.org/jdk/pull/2752

From jai.forums2013 at gmail.com  Thu Oct 17 04:53:40 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 17 Oct 2024 10:23:40 +0530
Subject: Would it make sense to add a new constructor to
 java.io.SequenceInputStream?
In-Reply-To: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>
References: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>
Message-ID: <e2155e19-296b-48ce-a3f2-bf8e7eb3cb04@gmail.com>

Hello David,

There's an enhancement request for this here 
https://bugs.openjdk.org/browse/JDK-8305947

-Jaikiran

On 17/10/24 9:17 am, David Alayachew wrote:
> Hello Core Libs Dev Team,
>
> Currently, java.io.SequenceInputStream only has 2 constructors -- one 
> that takes in 2 instances of InputStream, and another that takes in an 
> Enumeration of type InputStream.
>
> Would it make sense to add a third constructor that takes in multiple 
> instances of InputStream? I don't know if a list, an array, varargs, 
> etc makes more sense. But I would think a 3rd constructor would 
> improve this API.
>
> Thank you for your time and help.
> David Alayachew

From davidalayachew at gmail.com  Thu Oct 17 05:06:31 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 17 Oct 2024 01:06:31 -0400
Subject: Would it make sense to add a new constructor to
 java.io.SequenceInputStream?
In-Reply-To: <e2155e19-296b-48ce-a3f2-bf8e7eb3cb04@gmail.com>
References: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>
 <e2155e19-296b-48ce-a3f2-bf8e7eb3cb04@gmail.com>
Message-ID: <CAA9v-_NMsvL+QvTi36kYgkX1CbaTVmr2WV6Ek-o6OXBTtJs3pA@mail.gmail.com>

Hello Jaikiran,

Thanks for the response. This is exactly what I was looking for.

Does this mean that this is up for grabs? There was a comment near the
bottom about more evaluations, but that was also in 2023.

If all I need to do is continue the work that the other person was doing, I
am more than happy to.

Looks like in the pr attempted but closed, all Aleksey Shipil?v wanted was
for the developer to activate the test suite, so that they could see that
the tests passed. It sounds like all I need to do is do that and then we
should be good for review?

On Thu, Oct 17, 2024, 12:54?AM Jaikiran Pai <jai.forums2013 at gmail.com>
wrote:

> Hello David,
>
> There's an enhancement request for this here
> https://bugs.openjdk.org/browse/JDK-8305947
>
> -Jaikiran
>
> On 17/10/24 9:17 am, David Alayachew wrote:
> > Hello Core Libs Dev Team,
> >
> > Currently, java.io.SequenceInputStream only has 2 constructors -- one
> > that takes in 2 instances of InputStream, and another that takes in an
> > Enumeration of type InputStream.
> >
> > Would it make sense to add a third constructor that takes in multiple
> > instances of InputStream? I don't know if a list, an array, varargs,
> > etc makes more sense. But I would think a 3rd constructor would
> > improve this API.
> >
> > 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/20241017/6e768f43/attachment.htm>

From jai.forums2013 at gmail.com  Thu Oct 17 05:32:46 2024
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 17 Oct 2024 11:02:46 +0530
Subject: Would it make sense to add a new constructor to
 java.io.SequenceInputStream?
In-Reply-To: <CAA9v-_NMsvL+QvTi36kYgkX1CbaTVmr2WV6Ek-o6OXBTtJs3pA@mail.gmail.com>
References: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>
 <e2155e19-296b-48ce-a3f2-bf8e7eb3cb04@gmail.com>
 <CAA9v-_NMsvL+QvTi36kYgkX1CbaTVmr2WV6Ek-o6OXBTtJs3pA@mail.gmail.com>
Message-ID: <07ec12dc-2526-4187-8112-caabc5233c35@gmail.com>

It was suggested in that PR that the discussion be brought to this 
mailing list to gather any inputs and interest in the change. Except for 
your current mail, there hasn't been any other discussion here in the 
mailing list about it.

In the PR itself I haven't seen any objections to this change, but it 
isn't clear what motivated the new constructor. Does it fall into the 
good-to-have category? How frequently the SequenceInputStream gets used 
and whether this new constructor would help such usages wasn't explained 
either.

If you do pick this up, I think it would be useful to find out what kind 
of usage the SequenceInputStream class sees in libraries and whether 
this new constructor is going to be helpful for such usages.

-Jaikiran

On 17/10/24 10:36 am, David Alayachew wrote:
>
> Hello Jaikiran,
>
> Thanks for the response. This is exactly what I was looking for.
>
> Does this mean that this is up for grabs? There was a comment near the 
> bottom about more evaluations, but that was also in 2023.
>
> If all I need to do is continue the work that the other person was 
> doing, I am more than happy to.
>
> Looks like in the pr attempted but closed, all Aleksey Shipil?v wanted 
> was for the developer to activate the test suite, so that they could 
> see that the tests passed. It sounds like all I need to do is do that 
> and then we should be good for review?
>
>
> On Thu, Oct 17, 2024, 12:54?AM Jaikiran Pai <jai.forums2013 at gmail.com> 
> wrote:
>
>     Hello David,
>
>     There's an enhancement request for this here
>     https://bugs.openjdk.org/browse/JDK-8305947
>
>     -Jaikiran
>
>     On 17/10/24 9:17 am, David Alayachew wrote:
>     > Hello Core Libs Dev Team,
>     >
>     > Currently, java.io.SequenceInputStream only has 2 constructors
>     -- one
>     > that takes in 2 instances of InputStream, and another that takes
>     in an
>     > Enumeration of type InputStream.
>     >
>     > Would it make sense to add a third constructor that takes in
>     multiple
>     > instances of InputStream? I don't know if a list, an array,
>     varargs,
>     > etc makes more sense. But I would think a 3rd constructor would
>     > improve this API.
>     >
>     > 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/20241017/b055f3ca/attachment-0001.htm>

From alanb at openjdk.org  Thu Oct 17 05:57:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 05:57:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
 <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
Message-ID: <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>

On Wed, 16 Oct 2024 20:14:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.
>
> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.

Okay, it already has `@see StackWalker`. My guess is that anything extending SM to call getClassContext is very old code. If that old code is compiled with JDK 17+ then they should get a warning. In any case, we replaced the implementation to use StackWalker so getClassContext will continue to work until the SM class is removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1804151450

From jpai at openjdk.org  Thu Oct 17 06:05:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Oct 2024 06:05:13 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
Message-ID: <JtMJYJYik7htgVKpeG-FBriWyUfun3OGJ-Sgvxzt3yA=.fe635d22-6455-4e6f-a8dd-ee36c64166e0@github.com>

On Wed, 16 Oct 2024 14:55:34 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 247:

> 245: \  --module-path <module path>\n\
> 246: \      a "{0}"-separated list of directories and JAR archives to search for modules\n\n\
> 247: \For more details about this launcher:   java --help\n\

Hello Jan, perhaps we should avoid the use of "launcher" here and instead reword it as:

For additional help on usage: java --help\n\

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1804160137

From alanb at openjdk.org  Thu Oct 17 06:12:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 06:12:20 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: <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@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

This is going to require time to think through whether this is a good idea or not. The JDK supports sym links on Windows and adding support for other unusual junctions types has the potential to introduce inconsistencies and weirdness that are outside the scope of the APIs.  I will try to get time in the next few weeks to comment but this is not a change that we should rush into.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2418598658

From jpai at openjdk.org  Thu Oct 17 06:17:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Oct 2024 06:17:12 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
Message-ID: <x-2TXcyi4S5VWFrQJgeVVW8hUTA5pIJ_HZfn5NxxU4E=.85cc97cd-847a-4d19-9903-76adc4ab449f@github.com>

On Wed, 16 Oct 2024 14:55:34 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

src/java.base/share/native/libjli/java.c line 1935:

> 1933:     NULL_CHECK(printConciseUsageMessage = (*env)->GetStaticMethodID(env, cls,
> 1934:                                         "printConciseUsageMessage", "(Z)V"));
> 1935:     (*env)->CallStaticVoidMethod(env, cls, printConciseUsageMessage, printTo);

Should we have a exception check here after the `CallStaticVoidMethod` returns? I realize that several places in the current launcher code, in this file, don't have those checks, but the JNI specific of `CallStaticVoidMethod` does note that this function could raise any exception thrown by the underlying Java method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1804169672

From jlahoda at openjdk.org  Thu Oct 17 06:32:14 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 17 Oct 2024 06:32:14 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <x-2TXcyi4S5VWFrQJgeVVW8hUTA5pIJ_HZfn5NxxU4E=.85cc97cd-847a-4d19-9903-76adc4ab449f@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <x-2TXcyi4S5VWFrQJgeVVW8hUTA5pIJ_HZfn5NxxU4E=.85cc97cd-847a-4d19-9903-76adc4ab449f@github.com>
Message-ID: <BXn3VapksiP7CxsgHBnVGyxgWuXGN-5XcFgpWVfmcKc=.a438854f-d968-4444-9117-95146760e932@github.com>

On Thu, 17 Oct 2024 06:14:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>
> src/java.base/share/native/libjli/java.c line 1935:
> 
>> 1933:     NULL_CHECK(printConciseUsageMessage = (*env)->GetStaticMethodID(env, cls,
>> 1934:                                         "printConciseUsageMessage", "(Z)V"));
>> 1935:     (*env)->CallStaticVoidMethod(env, cls, printConciseUsageMessage, printTo);
> 
> Should we have a exception check here after the `CallStaticVoidMethod` returns? I realize that several places in the current launcher code, in this file, don't have those checks, but the JNI specific of `CallStaticVoidMethod` does note that this function could raise any exception thrown by the underlying Java method?

I see `CHECK_EXCEPTION_LEAVE(1);` in the caller of this method. Given we could only do `CHECK_EXCEPTION_RETURN();`, which returns if an exception is thrown (so that the caller can handle the exception as they see fit), it seems unnecessary for last calls. As for last calls, it is "return if an exception is thrown, and return if it is not". Note it is not only this function, `PrintJavaVersion`, `ShowSettings`, `ShowResolvedModules`, `ListModules` and maybe other use the same pattern, where the caller handles the exceptions, and the functions don't check the exceptions for the last call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1804183643

From jpai at openjdk.org  Thu Oct 17 06:39:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Oct 2024 06:39:13 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <BXn3VapksiP7CxsgHBnVGyxgWuXGN-5XcFgpWVfmcKc=.a438854f-d968-4444-9117-95146760e932@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <x-2TXcyi4S5VWFrQJgeVVW8hUTA5pIJ_HZfn5NxxU4E=.85cc97cd-847a-4d19-9903-76adc4ab449f@github.com>
 <BXn3VapksiP7CxsgHBnVGyxgWuXGN-5XcFgpWVfmcKc=.a438854f-d968-4444-9117-95146760e932@github.com>
Message-ID: <dCc_9cjcz7EFGvo5QgCuaGS77MgHpXB5-6x9qgIwAZY=.96b7d9a0-9123-4762-b544-6ae15b34b150@github.com>

On Thu, 17 Oct 2024 06:29:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 1935:
>> 
>>> 1933:     NULL_CHECK(printConciseUsageMessage = (*env)->GetStaticMethodID(env, cls,
>>> 1934:                                         "printConciseUsageMessage", "(Z)V"));
>>> 1935:     (*env)->CallStaticVoidMethod(env, cls, printConciseUsageMessage, printTo);
>> 
>> Should we have a exception check here after the `CallStaticVoidMethod` returns? I realize that several places in the current launcher code, in this file, don't have those checks, but the JNI specific of `CallStaticVoidMethod` does note that this function could raise any exception thrown by the underlying Java method?
>
> I see `CHECK_EXCEPTION_LEAVE(1);` in the caller of this method. Given we could only do `CHECK_EXCEPTION_RETURN();`, which returns if an exception is thrown (so that the caller can handle the exception as they see fit), it seems unnecessary for last calls. As for last calls, it is "return if an exception is thrown, and return if it is not". Note it is not only this function, `PrintJavaVersion`, `ShowSettings`, `ShowResolvedModules`, `ListModules` and maybe other use the same pattern, where the caller handles the exceptions, and the functions don't check the exceptions for the last call.

That's a good point about this being a last call before the control returns out of this function. I had missed that part. What you note about not needing an exception check here, makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1804192084

From jpai at openjdk.org  Thu Oct 17 06:53:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Oct 2024 06:53:11 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <TXKFHXemKM_TY9dqTc94kjqyBsVXqrnI5FmcIuAOcfo=.3be94919-ac3f-45cb-9e64-13373e304d3c@github.com>

On Wed, 16 Oct 2024 17:40:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

test/jdk/java/util/zip/ZipOutputStream/ZipOutputStreamMaxCenHdrTest.java line 171:

> 169:         try (ZipOutputStream zos = new ZipOutputStream(
> 170:                 new BufferedOutputStream(Files.newOutputStream(ZIP_FILE)))) {
> 171:             if (expectZipException) {

Hello Lance, with this change, it looks like this now misses calling the `zos.putNextEntry(zipEntry)` when `expectZipException` is `false`. Is that an oversight?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1804206491

From jrose at openjdk.org  Thu Oct 17 08:39:14 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 17 Oct 2024 08:39:14 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
Message-ID: <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>

On Thu, 17 Oct 2024 04:19:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @liach comments -- added comments; added asserts for HashMap safety in MethodType.java

I read through it fairly thoroughly.  I made a lot of suggestions.  Rather than edit comments into lots of spots in this PR, I made the following patch file.
[aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/17408940/aot-indy-21143-commentary.diff.txt)

  The first lines of the patch file state which revision the patch applies to, which is 4be6a255cdd from Tuesday.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2418914733

From eirbjo at openjdk.org  Thu Oct 17 08:43:11 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 17 Oct 2024 08:43:11 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
 <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
Message-ID: <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>

On Tue, 15 Oct 2024 16:08:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I guess performance leans on there being only one or a small number of versions per entry. 

I checked Spring Petclinic:

* 109 JAR dependencies
* 15 are multi-release enabled.
* The 15 MR-JARs have 9347 entries, of which 21 are versioned
* 9 of 15 MR JARs use the feature exclusively to hide `module-info.class` from Java 8.
* 3 of the 6 remaining JAR files version a single class file
* The remaining JARs mostly version on the 9 release.
* The maximum number of versioned entries in a file is 5.
* Zero entries have more than a single version.

> Which I think is a fair assumption. Still would be good to have a stress test with many entries having many versions and make sure we don't regress such cases too much, no?

Such a test would be somewhat speculative. If I add 5 versions of each entry in `ZipFileOpen`, then yes, this PR sees a regression over mainline:

Baseline:

Benchmark                     (size)  Mode  Cnt       Score       Error  Units
ZipFileOpen.openCloseZipFile    1024  avgt   15  718234.380 ? 29454.645  ns/op


PR:

Benchmark                     (size)  Mode  Cnt        Score       Error  Units
ZipFileOpen.openCloseZipFile    1024  avgt   15  1284944.601 ? 74919.522  ns/op


While `JarFileGetEntry` improves over baseline:

Baseline:

Benchmark                              (mr)  (size)  Mode  Cnt    Score   Error  Units
JarFileGetEntry.getEntryHit           false    1024  avgt   15   68.984 ? 2.791  ns/op
JarFileGetEntry.getEntryHit            true    1024  avgt   15  324.763 ? 9.690  ns/op
JarFileGetEntry.getEntryHitUncached   false    1024  avgt   15   95.884 ? 1.404  ns/op
JarFileGetEntry.getEntryHitUncached    true    1024  avgt   15  333.491 ? 3.576  ns/op
JarFileGetEntry.getEntryMiss          false    1024  avgt   15   37.358 ? 2.215  ns/op
JarFileGetEntry.getEntryMiss           true    1024  avgt   15  650.467 ? 5.116  ns/op
JarFileGetEntry.getEntryMissUncached  false    1024  avgt   15   61.059 ? 0.382  ns/op
JarFileGetEntry.getEntryMissUncached   true    1024  avgt   15  678.457 ? 4.390  ns/op


PR:


Benchmark                              (mr)  (size)  Mode  Cnt    Score    Error  Units
JarFileGetEntry.getEntryHit           false    1024  avgt   15   61.333 ?  3.665  ns/op
JarFileGetEntry.getEntryHit            true    1024  avgt   15  153.987 ?  8.889  ns/op
JarFileGetEntry.getEntryHitUncached   false    1024  avgt   15   90.008 ?  4.158  ns/op
JarFileGetEntry.getEntryHitUncached    true    1024  avgt   15  168.831 ?  1.676  ns/op
JarFileGetEntry.getEntryMiss          false    1024  avgt   15   34.525 ?  1.878  ns/op
JarFileGetEntry.getEntryMiss           true    1024  avgt   15   61.036 ?  2.568  ns/op
JarFileGetEntry.getEntryMissUncached  false    1024  avgt   15   75.246 ? 20.375  ns/op
JarFileGetEntry.getEntryMissUncached   true    1024  avgt   15   81.484 ?  1.981  ns/op


Future work could probably improve this situation by shifting version resolution to `initCEN` time. That way, only the single version relevant to the `JarFile` `featureVersion` would need to be considered. That's not so easy to do currently, since this happens in `JarFile`s super constructor. But with flexible constructor bodies, we may be able to do something. But not for this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1804355452

From sspitsyn at openjdk.org  Thu Oct 17 09:13:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 09:13:51 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v4]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <21dTiM5lJRCrNIKslnwjIZB4AQBGLiGjPYg4Qckw4OM=.17fa4363-2f09-49eb-898d-47ce71fb0107@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: tweaked disabler for carrier threads; more hiddenjvmti_mount_transition frames

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/3317ea81..0ad3fd7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=02-03

  Stats: 45 lines in 3 files changed: 16 ins; 17 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From sspitsyn at openjdk.org  Thu Oct 17 09:16:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 09:16:31 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v5]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <NDpcFZo0hBSNwnfqJaVuweX3tgcjOcs63XxIDykGdIc=.1a106349-d351-4bb0-8d29-d3ccb68450f4@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/0ad3fd7a..f8d05152

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=03-04

  Stats: 20 lines in 2 files changed: 0 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From rgiulietti at openjdk.org  Thu Oct 17 09:45:20 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Oct 2024 09:45:20 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v4]
In-Reply-To: <dBIjji1datjdEFJqOoMhrAn6uytM5P1NtegTelf2H_o=.4839e626-0dbf-46c7-b6b6-ce1a1a005383@github.com>
References: <ktZDmC-1cjJNkiYuIvbPzNWNSoffSbGAVtTFYLhBCbI=.9e41dd82-3dd7-4bfd-943c-35b1fae10a47@github.com>
 <dBIjji1datjdEFJqOoMhrAn6uytM5P1NtegTelf2H_o=.4839e626-0dbf-46c7-b6b6-ce1a1a005383@github.com>
Message-ID: <VyFsh8jRkv0Sn9buBKG6QQGUzrYZTy8r4Ey57gN7CJY=.31badef4-8a57-411e-9fa4-9865d6d9b1aa@github.com>

On Tue, 30 Apr 2024 08:44:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8316662
>  - Merge branch 'master' into 8316662
>  - Uppercase JLA.
>  - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)

reopen

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15861#issuecomment-2419057955

From galder at openjdk.org  Thu Oct 17 10:10:56 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 17 Oct 2024 10:10:56 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v4]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>

> 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  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

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/583c2fbe...0a8718e1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/16ae2a33..0a8718e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=02-03

  Stats: 298782 lines in 3654 files changed: 243667 ins; 34795 del; 20320 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From galder at openjdk.org  Thu Oct 17 10:15:25 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 17 Oct 2024 10:15:25 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: <QXs7uJ-a7WLEpftyElRZcGB_R_iKJpRrj8uQG6WD3h4=.13ee5ec0-871b-4f15-a162-368bb70b4f30@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/52005a12...0a8718e1

I've re-run the benchmarks in non-AVX-512 and AVX-512 environments making sure no .ad changes were applied.
I've also added clipping range benchmarks suggested by @theRealAph.

Remember that the AVX512 and non-AVX512 results were obtained in different systems so they cannot be compared between them. AVX512 results can be compared between base and patched versions and same for non-AVX512 results.

The results for loop* and reduction* match the behaviour explained in https://github.com/openjdk/jdk/pull/20098#issuecomment-2379386872. The explanation in that comment applies here as well:


Benchmark                          (probability)  (range)  (seed)  (size)   Mode  Cnt    Score    Error   Units
MinMaxLoopBench.longReductionMax              50      N/A     N/A   10000  thrpt    8  107.441 ?  0.092  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax              80      N/A     N/A   10000  thrpt    8  107.431 ?  0.057  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax             100      N/A     N/A   10000  thrpt    8  213.200 ?  5.070  ops/ms (non-AVX512, base)
MinMaxLoopBench.longReductionMax              50      N/A     N/A   10000  thrpt    8  107.411 ?  0.088  ops/ms (non-AVX512, patch)
MinMaxLoopBench.longReductionMax              80      N/A     N/A   10000  thrpt    8  107.425 ?  0.097  ops/ms (non-AVX512, patch)
MinMaxLoopBench.longReductionMax             100      N/A     N/A   10000  thrpt    8  107.377 ?  0.075  ops/ms (non-AVX512, patch)
MinMaxLoopBench.longReductionMax              50      N/A     N/A   10000  thrpt    8  414.214 ?  0.898  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax              80      N/A     N/A   10000  thrpt    8  414.637 ?  0.074  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax             100      N/A     N/A   10000  thrpt    8  239.570 ?  3.034  ops/ms (AVX512, base)
MinMaxLoopBench.longReductionMax              50      N/A     N/A   10000  thrpt    8  414.276 ?  0.399  ops/ms (AVX512, patch)
MinMaxLoopBench.longReductionMax              80      N/A     N/A   10000  thrpt    8  414.284 ?  0.342  ops/ms (AVX512, patch)
MinMaxLoopBench.longReductionMax             100      N/A     N/A   10000  thrpt    8  413.860 ?  1.831  ops/ms (AVX512, patch)


The clipping range results show big improvements:

Benchmark                          (probability)  (range)  (seed)  (size)   Mode  Cnt    Score    Error    Units
MinMaxLoopBench.longClippingRange            N/A       90       0   10000  thrpt    8  108.503 ?  0.399   ops/ms (non-AVX512, base)
MinMaxLoopBench.longClippingRange            N/A      100       0   10000  thrpt    8  107.655 ?  1.759   ops/ms (non-AVX512, base)
MinMaxLoopBench.longClippingRange            N/A       90       0   10000  thrpt    8  613.310 ?  1.140   ops/ms (non-AVX512, patch)
MinMaxLoopBench.longClippingRange            N/A      100       0   10000  thrpt    8  613.282 ?  0.744   ops/ms (non-AVX512, patch)
MinMaxLoopBench.longClippingRange            N/A       90       0   10000  thrpt    8   64.343 ?  0.396   ops/ms (AVX512, base)
MinMaxLoopBench.longClippingRange            N/A      100       0   10000  thrpt    8   61.323 ?  6.059   ops/ms (AVX512, base)
MinMaxLoopBench.longClippingRange            N/A       90       0   10000  thrpt    8  359.525 ?  0.570   ops/ms (AVX512, patch)
MinMaxLoopBench.longClippingRange            N/A      100       0   10000  thrpt    8  360.284 ?  1.408   ops/ms (AVX512, patch)


The improvements in clipping range are due to vector instructions being used:


   0.11%  ??  0x00007f5e000266c8:   vpcmpgtq		%ymm4, %ymm5, %ymm12
   0.56%  ??  0x00007f5e000266cd:   vblendvpd		%ymm12, %ymm5, %ymm4, %ymm12
   0.04%  ??  0x00007f5e000266d3:   vpcmpgtq		%ymm6, %ymm12, %ymm11
   1.10%  ??  0x00007f5e000266d8:   vblendvpd		%ymm11, %ymm6, %ymm12, %ymm11
   2.93%  ??  0x00007f5e000266de:   vmovdqu		%ymm11, 0xf0(%r9, %r10, 8)
          ??                                                            ;*lastore {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 35 (line 211)
          ??                                                            ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)


Whereas without the changes it uses scalar instructions:


   0.56%          ??    0x00007f9e98025e83:   cmpq		%r8, %rdx
   2.98%  ?       ??    0x00007f9e98025e86:   jle		0x7f9e98025e8b      ;*ifgt {reexecute=0 rethrow=0 return_oop=0}
          ?       ??                                                              ; - java.lang.Math::min at 3 (line 2132)
          ?       ??                                                              ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 32 (line 211)
          ?       ??                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
   0.03%  ?       ??    0x00007f9e98025e88:   movq		%r8, %rdx           ;*lreturn {reexecute=0 rethrow=0 return_oop=0}
          ?       ??                                                              ; - java.lang.Math::min at 11 (line 2132)
          ?       ??                                                              ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 32 (line 211)
          ?       ??                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
   0.04%  ?       ??    0x00007f9e98025e8b:   movq		%rdx, 0x28(%r13, %rcx, 8);*lastore {reexecute=0 rethrow=0 return_oop=0}
                  ??                                                              ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 35 (line 211)
                  ??                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)
  19.79%          ??    0x00007f9e98025e90:   addl		$4, %ecx            ;*iinc {reexecute=0 rethrow=0 return_oop=0}
                  ??                                                              ; - org.openjdk.bench.java.lang.MinMaxLoopBench::longClippingRange at 36 (line 210)
                  ??                                                              ; - org.openjdk.bench.java.lang.jmh_generated.MinMaxLoopBench_longClippingRange_jmhTest::longClippingRange_thrpt_jmhStub at 19 (line 124)


Finally, I've fixed the float/double IR tests by adding conditionals to make sure they only run when UseAVX > 0.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2419120069

From lancea at openjdk.org  Thu Oct 17 10:44:51 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 17 Oct 2024 10:44:51 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add back missing putNextEntry call

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/e7ec8e0b..403c411d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From lancea at openjdk.org  Thu Oct 17 10:44:52 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 17 Oct 2024 10:44:52 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <TXKFHXemKM_TY9dqTc94kjqyBsVXqrnI5FmcIuAOcfo=.3be94919-ac3f-45cb-9e64-13373e304d3c@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <TXKFHXemKM_TY9dqTc94kjqyBsVXqrnI5FmcIuAOcfo=.3be94919-ac3f-45cb-9e64-13373e304d3c@github.com>
Message-ID: <zbSEoqwTkpfQkF1B3uY24AZE28jV_4TX2h470dISn7s=.3ff43bfd-bbaf-4cc2-b705-a80ed9d4453d@github.com>

On Thu, 17 Oct 2024 06:50:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add back missing putNextEntry call
>
> test/jdk/java/util/zip/ZipOutputStream/ZipOutputStreamMaxCenHdrTest.java line 171:
> 
>> 169:         try (ZipOutputStream zos = new ZipOutputStream(
>> 170:                 new BufferedOutputStream(Files.newOutputStream(ZIP_FILE)))) {
>> 171:             if (expectZipException) {
> 
> Hello Lance, with this change, it looks like this now misses calling the `zos.putNextEntry(zipEntry)` when `expectZipException` is `false`. Is that an oversight?

Yes, an oversight as sometimes you see what you want to see.

added a call to `zos.putNextEntry(zipEntry) `when when `expectZipException` is `false`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1804534470

From swen at openjdk.org  Thu Oct 17 10:53:14 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 17 Oct 2024 10:53:14 GMT
Subject: Integrated: 8342336: Optimize ClassFile imports
In-Reply-To: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
References: <5HijQVApXBrbQUe6fd-NHlmEwyUObWyXhBDVH8EDBNk=.2b346028-a74e-4308-aa7e-b8446d8ec2ff@github.com>
Message-ID: <EvE_cWRmZBgxdiAN2SnCBjRsRp6N6bIijiC48ANVmPM=.60dfaf2f-0555-486e-b196-12f987f70e68@github.com>

On Sun, 13 Oct 2024 01:42:38 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This is a code style improvement for imports in the java/lang/classfile and jdk/internal/classfile/impl directories, includes:
> 1. Import in alphabetical order
> 2. Add a blank line between java and jdk imports
> 3. Use import * for a large number of imports

This pull request has now been integrated.

Changeset: 3ebfc6c1
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ebfc6c1e27119180700af5ea85e5fa6c1771050
Stats:     1435 lines in 198 files changed: 430 ins; 910 del; 95 mod

8342336: Optimize ClassFile imports

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21482

From lancea at openjdk.org  Thu Oct 17 10:56:21 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 17 Oct 2024 10:56:21 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
Message-ID: <COWrLW14fysR_5V1eH1mwTzaLQ5XgnKMzPXtJwowJjw=.2cdaf856-1f7a-4fc1-bc10-89cf6c36c25c@github.com>

On Thu, 17 Oct 2024 04:51:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's man page inputs

Looks good Jai

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/2752#pullrequestreview-2374864115

From alanb at openjdk.org  Thu Oct 17 10:58:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 10:58:20 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <wdqAxZs9snttDKfZBWWy7M9Eu4MfTxG_Musdo7h6NIQ=.bcf31986-8690-4be2-9b1d-bb2aac5aade3@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
 <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>
 <Wht-tuuGDZt_XliGWoBzXmQRNiY5xe-nsYusevJtHoE=.e68c0c34-0007-4098-a631-99c640b7f989@github.com>
 <wdqAxZs9snttDKfZBWWy7M9Eu4MfTxG_Musdo7h6NIQ=.bcf31986-8690-4be2-9b1d-bb2aac5aade3@github.com>
Message-ID: <KIphK6l9cXtPiOTaVZkwLCydGuUFlcqYwNj8QSfxXsE=.9a55f32d-88d9-4411-822c-58236673dec2@github.com>

On Wed, 16 Oct 2024 17:01:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> No issue from me on moving the notifications to the run method. My comment was more for the JvmtiMountTransition's class description as it's not easy to audit the use of this annotation.
>
> Got it, thanks.

The updated changes to VirtualThread look fine. I'm still wondering about JvmtiMountTransition's class description.  There's nothing obvious in yield and yield0 that they start/end a VTMS.  Maybe for a future PR but I think the description could be expanded as the same questions will come up each time that anything using this annotation changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1804553428

From jpai at openjdk.org  Thu Oct 17 11:03:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 17 Oct 2024 11:03:11 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
Message-ID: <WfF6Qlru-b751ixqKC7MaovW2JYgl-6Y2Xm9LqDu9zY=.221f7ce6-96ad-4cda-8fab-8d59e443a93f@github.com>

On Thu, 17 Oct 2024 10:44:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back missing putNextEntry call

Thank you for the update Lance, these changes look good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21544#pullrequestreview-2374877149

From alanb at openjdk.org  Thu Oct 17 11:26:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 11:26:18 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
Message-ID: <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>

On Tue, 15 Oct 2024 22:37:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8233451: Remove use of handleAvailable() (Windows)
>  - 8233451: Remove use of handleAvailable() (UNIX)

src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 56:

> 54:     private byte[] b1;
> 55: 
> 56:     private Boolean isOther = null;

I don't particularly like using a Boolean for tri-states but it's not too bad here. No need to initialize to null. It could be Stable but probably not much benefit here all usages require file I/O that dominates.

Are you going to add a comment to this field as readers might know now what "other" means? In the APIs we say "something other than a regular file, directory, or symbolic link" and maybe that could be useful here.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 533:

> 531:     }
> 532: 
> 533:     public int available() throws IOException {

This can be package-private. It would be useful to add a method description as FC doesn't define this method, same thing for isOther.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 565:

> 563:                 return isOther = nd.isOther(fd);
> 564:             } finally {
> 565:                 Blocker.end(attempted);

No need for Blocker begin/end here, we only use for direct I/O or file locking.

src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c line 233:

> 231: 
> 232:     return JNI_TRUE;
> 233: }

Can you check these syscalls for EINTR? Might be okay, but worth checking.

src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c line 438:

> 436: 
> 437:     BY_HANDLE_FILE_INFORMATION finfo;
> 438:     GetFileInformationByHandle(handle, &finfo);

This returns a BOOL that needs to be checked.

test/jdk/java/nio/file/Files/InputStreamTest.java line 139:

> 137:             InputStream s = Files.newInputStream(stdin);
> 138:             s.available();
> 139:         }

I assume you meant to close the input stream.

What about the other methods defined by InputStream that have special handling in ChannelInputStream? I assume we should add test coverage for these methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804577608
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804580164
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804581541
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804585370
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804586710
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1804588059

From weijun at openjdk.org  Thu Oct 17 11:27:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Oct 2024 11:27:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
Message-ID: <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>

On Wed, 16 Oct 2024 20:51:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:
>> 
>>> 29: 
>>> 30: /**
>>> 31:  * This class is for GSS security context permissions.
>> 
>> Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.
>
> In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.
> 
> If there are other Permission classes you think should have their text modified or removed, let me know.

All JGSS permission classes follow the same style:

In `javax.security.auth.kerberos.DelegationPermission`:

 * This class is used to restrict the usage of the Kerberos
 * delegation model, ie: forwardable and proxiable tickets.
 ```
In `javax.security.auth.kerberos.DelegationPermission`:

 * This class is used to restrict the usage of the Kerberos
 * delegation model, ie: forwardable and proxiable tickets.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1804590136

From lbourges at openjdk.org  Thu Oct 17 11:28:19 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 17 Oct 2024 11:28:19 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v4]
In-Reply-To: <dBIjji1datjdEFJqOoMhrAn6uytM5P1NtegTelf2H_o=.4839e626-0dbf-46c7-b6b6-ce1a1a005383@github.com>
References: <ktZDmC-1cjJNkiYuIvbPzNWNSoffSbGAVtTFYLhBCbI=.9e41dd82-3dd7-4bfd-943c-35b1fae10a47@github.com>
 <dBIjji1datjdEFJqOoMhrAn6uytM5P1NtegTelf2H_o=.4839e626-0dbf-46c7-b6b6-ce1a1a005383@github.com>
Message-ID: <qan5dKDGsRfGZT31DMW3RlbjZVFcLMyE-HCpw3vKhoE=.b3068344-421b-4e14-8dd2-72acd5aff3fe@github.com>

On Tue, 30 Apr 2024 08:44:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8316662
>  - Merge branch 'master' into 8316662
>  - Uppercase JLA.
>  - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)

Looks promising

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15861#issuecomment-2419261478

From eirbjo at openjdk.org  Thu Oct 17 11:32:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 17 Oct 2024 11:32:12 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
Message-ID: <7IxPd36daC_uVSUiZ6-1ZNbXJUHlo-rbgjfumkItAaw=.74556159-722e-4da1-bd98-e37e115e479c@github.com>

On Thu, 17 Oct 2024 10:44:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back missing putNextEntry call

src/java.base/share/classes/java/util/zip/ZipEntry.java line 97:

> 95:     // for entries in order to not exceed 65,489 bytes minus 46 bytes for the CEN
> 96:     // header length
> 97:     private static final int MAX_NAME_COMMENT_EXTRA_SIZE =

Would it make sense to validate the actual combined length here, instead of just pretending that all other components of the combined lenghts are zero-length?

We could introduce a method like this:


/*
 * Validate that the combined length of the 46 byte CEN header, the name,
 * the extra field and the comment does not exceed 0xFFFF
 */
private void validateCombinedLength(String name, byte[] extra, String comment, String message) {
    int headerLength = ZipEntry.CENHDR;

    if (name != null) {
        headerLength += name.length();
    }
    if (extra != null) {
        headerLength += extra.length;
    }

    if (comment != null) {
        headerLength += comment.length();
    }

    if (headerLength > 0xFFFF) {
        throw new IllegalArgumentException(message);
    }
}


Then the constructor could use it like this:

validateCombinedLength(name, null, null, "entry name too long");


setExtra:


validateCombinedLength(name, extra, comment, "invalid extra field length");


setComment:

validateCombinedLength(name, extra, comment, "entry comment too long");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1804594587

From abimpoudis at openjdk.org  Thu Oct 17 11:42:17 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 17 Oct 2024 11:42:17 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <VRI5dtGUy8-7LPMyYP7qyLU31oLxxnLvPGG1X8xUjb4=.2009b0ce-094d-4247-a455-fd68e68b9a06@github.com>

On Mon, 14 Oct 2024 12:46:29 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 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java line 159:

> 157:     enum ScopeType {
> 158:         ORDINARY,
> 159:         START_IMPORT,

Is this a "start" import or a "star"*  import? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1804609420

From eirbjo at openjdk.org  Thu Oct 17 11:44:11 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 17 Oct 2024 11:44:11 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
Message-ID: <i32u_ZUDLq3paDwZ4vqPYdeGpvB6Ly8h_57jFuLGAK0=.1e094dad-ad4e-4aed-9ccc-27f38d153a00@github.com>

On Thu, 17 Oct 2024 10:44:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back missing putNextEntry call

test/jdk/java/util/zip/ZipOutputStream/ZipOutputStreamMaxCenHdrTest.java line 73:

> 71:     static final String ENTRY_COMMENT = "A Comment";
> 72:     // Max length minus the size of the ENTRY_NAME or ENTRY_COMMENT
> 73:     static final int MAX_FIElD_LEN_MINUS_ENTRY_NAME =

The "l" in "FIElD" seems lowercase?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1804611083

From jlahoda at openjdk.org  Thu Oct 17 11:49:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 17 Oct 2024 11:49:18 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <VRI5dtGUy8-7LPMyYP7qyLU31oLxxnLvPGG1X8xUjb4=.2009b0ce-094d-4247-a455-fd68e68b9a06@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
 <VRI5dtGUy8-7LPMyYP7qyLU31oLxxnLvPGG1X8xUjb4=.2009b0ce-094d-4247-a455-fd68e68b9a06@github.com>
Message-ID: <vAxuMlrhQk9kUPI4gI0PXo1FL47Pnz4wM8Tnla5xRRM=.03404217-58f4-4df2-87ea-f54cfe760b28@github.com>

On Thu, 17 Oct 2024 11:39:51 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - Make very sure java.base is completed.
>>  - Keep jdk.internal.javac qualified export from java.base.
>>  - Adding forgotten change.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacScope.java line 159:
> 
>> 157:     enum ScopeType {
>> 158:         ORDINARY,
>> 159:         START_IMPORT,
> 
> Is this a "start" import or a "star"*  import? ?

Star import. Will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1804617634

From weijun at openjdk.org  Thu Oct 17 11:51:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Oct 2024 11:51:12 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
Message-ID: <vLgjIZArIyHJzFREWzeXpRDsefvXFe332RvT9S5Qqio=.aaea196b-155d-41f9-b4f6-02f40d0e9e34@github.com>

On Wed, 16 Oct 2024 14:55:34 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

`<SourceFile>.java          to compile and execute a single-file program`

This is no more precise since we have [JEP 458: Launch Multi-File Source-Code Programs](https://openjdk.org/jeps/458).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2419309559

From davidalayachew at gmail.com  Thu Oct 17 12:00:48 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 17 Oct 2024 08:00:48 -0400
Subject: Would it make sense to add a new constructor to
 java.io.SequenceInputStream?
In-Reply-To: <07ec12dc-2526-4187-8112-caabc5233c35@gmail.com>
References: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>
 <e2155e19-296b-48ce-a3f2-bf8e7eb3cb04@gmail.com>
 <CAA9v-_NMsvL+QvTi36kYgkX1CbaTVmr2WV6Ek-o6OXBTtJs3pA@mail.gmail.com>
 <07ec12dc-2526-4187-8112-caabc5233c35@gmail.com>
Message-ID: <CAA9v-_PomuyvPU1bUBOZgSVB2GpLqDa1Aavr4VOvB-H+PPDK+A@mail.gmail.com>

Well, my personal use case is to Frankenstein my own InputStream out of
several different things for libraries that only take InputStream. For
example, what if I need to prepend or postpend with a newline? I am doing
that now, which is actually what prompted me to ask this.

On Thu, Oct 17, 2024, 1:33?AM Jaikiran Pai <jai.forums2013 at gmail.com> wrote:

> It was suggested in that PR that the discussion be brought to this mailing
> list to gather any inputs and interest in the change. Except for your
> current mail, there hasn't been any other discussion here in the mailing
> list about it.
>
> In the PR itself I haven't seen any objections to this change, but it
> isn't clear what motivated the new constructor. Does it fall into the
> good-to-have category? How frequently the SequenceInputStream gets used and
> whether this new constructor would help such usages wasn't explained
> either.
>
> If you do pick this up, I think it would be useful to find out what kind
> of usage the SequenceInputStream class sees in libraries and whether this
> new constructor is going to be helpful for such usages.
>
> -Jaikiran
> On 17/10/24 10:36 am, David Alayachew wrote:
>
> Hello Jaikiran,
>
> Thanks for the response. This is exactly what I was looking for.
>
> Does this mean that this is up for grabs? There was a comment near the
> bottom about more evaluations, but that was also in 2023.
>
> If all I need to do is continue the work that the other person was doing,
> I am more than happy to.
>
> Looks like in the pr attempted but closed, all Aleksey Shipil?v wanted was
> for the developer to activate the test suite, so that they could see that
> the tests passed. It sounds like all I need to do is do that and then we
> should be good for review?
>
> On Thu, Oct 17, 2024, 12:54?AM Jaikiran Pai <jai.forums2013 at gmail.com>
> wrote:
>
>> Hello David,
>>
>> There's an enhancement request for this here
>> https://bugs.openjdk.org/browse/JDK-8305947
>>
>> -Jaikiran
>>
>> On 17/10/24 9:17 am, David Alayachew wrote:
>> > Hello Core Libs Dev Team,
>> >
>> > Currently, java.io.SequenceInputStream only has 2 constructors -- one
>> > that takes in 2 instances of InputStream, and another that takes in an
>> > Enumeration of type InputStream.
>> >
>> > Would it make sense to add a third constructor that takes in multiple
>> > instances of InputStream? I don't know if a list, an array, varargs,
>> > etc makes more sense. But I would think a 3rd constructor would
>> > improve this API.
>> >
>> > 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/20241017/cded00d2/attachment.htm>

From rgiulietti at openjdk.org  Thu Oct 17 12:41:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Oct 2024 12:41:14 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
 <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
Message-ID: <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>

On Tue, 15 Oct 2024 09:56:30 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> I would say yes... The invariant `i == max{n : 5^(2^n) <= 5^remainingZeros}` should be a sufficient condition to affirm it, indeed the 2nd loop ends when `remainingZeros == 0`, so `remainingZeros >= z` implies `z == 0`...
>
>> Yes, I considered that as well. Not sure, however, if this is sufficient to prove that intVal has been indeed divided by 5^z after the 2nd loop is terminated.
> 
> New comments just added should be sufficient to prove it.

The comments are OK. However, there seems to be no explicit relation between the "running" vars used in the reasoning and the expected outcome.

To clarify what I mean, let v0, z0 and s0 be the initial values at method entry of intVal, z and scale, resp.
At the exit of the method, the following is supposed to hold by contract:

v0 = intVal * 10^z0, s0 = scale + z0.

At least to me, this is not apparent from the comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1804710014

From duke at openjdk.org  Thu Oct 17 13:03:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Oct 2024 13:03:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
 <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
 <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>
Message-ID: <XP8S9VnK0-0PDHcDjVfvjF8LuF-4PLriiX8mu85aT-U=.edba371b-47a3-495a-bac4-345ce2c83ebd@github.com>

On Thu, 17 Oct 2024 12:38:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> The comments are OK. However, there seems to be no explicit relation between the "running" vars used in the reasoning and the expected outcome.
> 
> To clarify what I mean, let v0, z0 and s0 be the initial values at method entry of intVal, z and scale, resp. At the exit of the method, the following is supposed to hold by contract:
> 
> v0 = intVal * 10^z0, s0 = scale + z0.
> 
> At least to me, this is not apparent from the comments.

@rgiulietti Starting from the facts `min(scale - preferredScale, powsOf2) >= remainingZeros` and `remainingZeros >= 2^i`, if `intVal % 5^(2^i) == 0`, then `(intVal * 2^powsOf2) % 10^(2^i) == 0`, so dividing `intVal` by `5^(2^i)` is legit (in the sense that we don't remove powers of 2 and we don't reduce the scale more than allowed) and exactly mimics the division `(intVal * 2^powsOf2) / 10^n` subtracting `2^i` from `powsOf2`. This allows to reduce the initial problem to the new values of the "running" vars after an iteration. So, I don't see the reason why it should not be apparent from the comments onestly...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1804743139

From lancea at openjdk.org  Thu Oct 17 13:55:48 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 17 Oct 2024 13:55:48 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v3]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <Nc_c4twfgDT3fhEuhlqnMxAqJqQ9CFwstIJSvg7X3-w=.55c1533a-06fb-4ec7-a133-0419dad22e9c@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address typo in MAX_FIELD_LEN_MINUS_ENTRY_NAME

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/403c411d..1ffaa722

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=01-02

  Stats: 17 lines in 2 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From lancea at openjdk.org  Thu Oct 17 13:55:49 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 17 Oct 2024 13:55:49 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <i32u_ZUDLq3paDwZ4vqPYdeGpvB6Ly8h_57jFuLGAK0=.1e094dad-ad4e-4aed-9ccc-27f38d153a00@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
 <i32u_ZUDLq3paDwZ4vqPYdeGpvB6Ly8h_57jFuLGAK0=.1e094dad-ad4e-4aed-9ccc-27f38d153a00@github.com>
Message-ID: <X9DH9ixb2jY6EL-zDzckiVU7njvF-Q5Xq6NJX5JrdKA=.122dfc29-cad1-4df1-b1d3-2b8fe8cd0edb@github.com>

On Thu, 17 Oct 2024 11:41:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add back missing putNextEntry call
>
> test/jdk/java/util/zip/ZipOutputStream/ZipOutputStreamMaxCenHdrTest.java line 73:
> 
>> 71:     static final String ENTRY_COMMENT = "A Comment";
>> 72:     // Max length minus the size of the ENTRY_NAME or ENTRY_COMMENT
>> 73:     static final int MAX_FIElD_LEN_MINUS_ENTRY_NAME =
> 
> The "l" in "FIElD" seems lowercase?

Thanks fixed and easy to miss :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1804830326

From alan.bateman at oracle.com  Thu Oct 17 13:57:16 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Thu, 17 Oct 2024 14:57:16 +0100
Subject: Would it make sense to add a new constructor to
 java.io.SequenceInputStream?
In-Reply-To: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>
References: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>
Message-ID: <4d96d695-8ed8-4445-91f5-34a31624175d@oracle.com>



On 17/10/2024 04:47, David Alayachew wrote:
> Hello Core Libs Dev Team,
>
> Currently, java.io.SequenceInputStream only has 2 constructors -- one 
> that takes in 2 instances of InputStream, and another that takes in an 
> Enumeration of type InputStream.
>
> Would it make sense to add a third constructor that takes in multiple 
> instances of InputStream? I don't know if a list, an array, varargs, 
> etc makes more sense. But I would think a 3rd constructor would 
> improve this API.

If you are exploring this topic then put InputStream.of(InputStream... 
sources) on the list to try out. InputStream.of() could work the 
equivalent of InputStream.nulInputStream().

-Alan

From lancea at openjdk.org  Thu Oct 17 13:59:13 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 17 Oct 2024 13:59:13 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <7IxPd36daC_uVSUiZ6-1ZNbXJUHlo-rbgjfumkItAaw=.74556159-722e-4da1-bd98-e37e115e479c@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
 <7IxPd36daC_uVSUiZ6-1ZNbXJUHlo-rbgjfumkItAaw=.74556159-722e-4da1-bd98-e37e115e479c@github.com>
Message-ID: <JPJjKswSCLPuUlnPg9rNlRizhP0W6S8TB4WZBrBBhGk=.26866ef0-9900-4ea3-9937-05be6e5cb86e@github.com>

On Thu, 17 Oct 2024 11:28:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add back missing putNextEntry call
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 97:
> 
>> 95:     // for entries in order to not exceed 65,489 bytes minus 46 bytes for the CEN
>> 96:     // header length
>> 97:     private static final int MAX_NAME_COMMENT_EXTRA_SIZE =
> 
> Would it make sense to validate the actual combined length here, instead of just pretending that all other components of the combined lenghts are zero-length?
> 
> We could introduce a method like this:
> 
> 
> /* CEN header size + name length + comment length + extra length
>  * should not exceed 65,535 bytes per the PKWare APP.NOTE
>  * 4.4.10, 4.4.11, & 4.4.12.
>  */
> private void checkCombinedLength(String name, byte[] extra, String comment, String message) {
>     
>     int elen = extra == null ? 0 : extra.length;
>     int clen = comment == null ? 0 : comment.length();
> 
>     long headerLength = ZipEntry.CENHDR + name.length() + elen + clen;
> 
>     if (headerLength > 0xFFFF) {
>         throw new IllegalArgumentException(message);
>     }
> }
> 
> 
> 
> Then the constructor could use it like this:
> 
> checkCombinedLength(name, null, null, "entry name too long");
> 
> 
> setExtra:
> 
> 
> checkCombinedLength(name, extra, comment, "invalid extra field length");
> 
> 
> setComment:
> 
> checkCombinedLength(name, extra, comment, "entry comment too long");
> 
> 
> 
> With this solution, I suppose`ZipEntry` enforces the invariant fully, and repeating the validation in `ZipOutputStream` should be unneccessary.
> 
> Or did I miss something?

I had thought about that and decided to keep the changes as they are.  I am not opposed to revisiting this in a follow on PR.  Any additional changes would require more javadoc updates to address the overall change in validation. 

So after we fork JDK 24, happyt to revisit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1804839093

From rriggs at openjdk.org  Thu Oct 17 14:07:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Oct 2024 14:07:13 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit
In-Reply-To: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
Message-ID: <tJMX_FtX6Th87M_EGT-g7zeDSRd524ddVU0kuB3Ecpk=.8fbf6cb0-fe89-4dce-8ecb-a5223ddf505b@github.com>

On Wed, 16 Oct 2024 22:48:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
> 
> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.

src/java.base/share/classes/java/text/MessageFormat.java line 127:

> 125:  * not shown in the table are illegal. A <i>SubformatPattern</i> must
> 126:  * be a valid pattern string for the {@code Format} subclass used.
> 127:  * @implSpec For this implementation, the limit of <b>ArgumentIndex</b> is 10,000

I don't think the number should be *specified*; it would be fine as an implementation note.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21554#discussion_r1804852671

From rgiulietti at openjdk.org  Thu Oct 17 14:32:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Oct 2024 14:32:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <XP8S9VnK0-0PDHcDjVfvjF8LuF-4PLriiX8mu85aT-U=.edba371b-47a3-495a-bac4-345ce2c83ebd@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
 <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
 <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>
 <XP8S9VnK0-0PDHcDjVfvjF8LuF-4PLriiX8mu85aT-U=.edba371b-47a3-495a-bac4-345ce2c83ebd@github.com>
Message-ID: <3clpPOmwcsIOQLIc3Te5vMmYxHl32hTZGEK-dLENKu8=.0e38626f-9205-43e6-bc93-160fb043091b@github.com>

On Thu, 17 Oct 2024 12:59:37 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> The comments are OK. However, there seems to be no explicit relation between the "running" vars used in the reasoning and the expected outcome.
>> 
>> To clarify what I mean, let v0, z0 and s0 be the initial values at method entry of intVal, z and scale, resp.
>> At the exit of the method, the following is supposed to hold by contract:
>> 
>> v0 = intVal * 10^z0, s0 = scale + z0.
>> 
>> At least to me, this is not apparent from the comments.
>
>> The comments are OK. However, there seems to be no explicit relation between the "running" vars used in the reasoning and the expected outcome.
>> 
>> To clarify what I mean, let v0, z0 and s0 be the initial values at method entry of intVal, z and scale, resp. At the exit of the method, the following is supposed to hold by contract:
>> 
>> v0 = intVal * 10^z0, s0 = scale + z0.
>> 
>> At least to me, this is not apparent from the comments.
> 
> @rgiulietti Starting from the facts `min(scale - preferredScale, powsOf2) >= remainingZeros` and `remainingZeros >= 2^i`, if `intVal % 5^(2^i) == 0`, then `(intVal * 2^powsOf2) % 10^(2^i) == 0`, so dividing `intVal` by `5^(2^i)` is legit (in the sense that we don't remove powers of 2 and we don't reduce the scale more than allowed) and exactly mimics the division `(intVal * 2^powsOf2) / 10^(2^i)` subtracting `2^i` from `powsOf2`. This allows to reduce the initial problem to the new values of the "running" vars after an iteration. So, I don't see the reason why it should not be apparent from the comments onestly...

OK, let me reformulate the reasoning to check that we are in sync.
For simplicity, I'm assuming that the powers of 2 are _not_ stripped away, so I'm using powers of 10 rather than powers of 5. Adding the powers of 2 optimization to the reasoning is then straightforward.

As above, let v0, z0 and s0 be the initial values at method entry of intVal, z and scale, resp.
We need to return intVal = v0 / 10^z0, scale = s0 - z0.

Let sexp be the running sum of all exponents exp inside both loops that lead to zero remainders in the division intVal / 10^exp.
It should be easy to see that both "then" branches maintain

z = z0 - sexp, intVal = v0 / 10^sexp, scale = s0 - sexp

and that both branches in both loops maintain

remainingZeros >= z

When the 2nd loop exits, remainingZeros = 0, so z = 0. This means z0 = sexp, intVal = v0 / 10^z0, scale = s0 - z0 (correctness).

In addition, both loops exit for the reasons in the comments (termination) and both loops require very few iterations (quality of service).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1804899523

From duke at openjdk.org  Thu Oct 17 14:55:16 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Oct 2024 14:55:16 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <3clpPOmwcsIOQLIc3Te5vMmYxHl32hTZGEK-dLENKu8=.0e38626f-9205-43e6-bc93-160fb043091b@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
 <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
 <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>
 <XP8S9VnK0-0PDHcDjVfvjF8LuF-4PLriiX8mu85aT-U=.edba371b-47a3-495a-bac4-345ce2c83ebd@github.com>
 <3clpPOmwcsIOQLIc3Te5vMmYxHl32hTZGEK-dLENKu8=.0e38626f-9205-43e6-bc93-160fb043091b@github.com>
Message-ID: <tCDzg9__t_w38gdJMk3-Suvg4Lngh2m-kzLynTBfa5Y=.6781fce7-16e5-465f-96fc-499f0f7af986@github.com>

On Thu, 17 Oct 2024 14:29:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> The comments are OK. However, there seems to be no explicit relation between the "running" vars used in the reasoning and the expected outcome.
>>> 
>>> To clarify what I mean, let v0, z0 and s0 be the initial values at method entry of intVal, z and scale, resp. At the exit of the method, the following is supposed to hold by contract:
>>> 
>>> v0 = intVal * 10^z0, s0 = scale + z0.
>>> 
>>> At least to me, this is not apparent from the comments.
>> 
>> @rgiulietti Starting from the facts `min(scale - preferredScale, powsOf2) >= remainingZeros` and `remainingZeros >= 2^i`, if `intVal % 5^(2^i) == 0`, then `(intVal * 2^powsOf2) % 10^(2^i) == 0`, so dividing `intVal` by `5^(2^i)` is legit (in the sense that we don't remove powers of 2 and we don't reduce the scale more than allowed) and exactly mimics the division `(intVal * 2^powsOf2) / 10^(2^i)` subtracting `2^i` from `powsOf2`. This allows to reduce the initial problem to the new values of the "running" vars after an iteration. So, I don't see the reason why it should not be apparent from the comments onestly...
>
> OK, let me reformulate the reasoning to check that we are in sync.
> For simplicity, I'm assuming that the powers of 2 are _not_ stripped away, so I'm using powers of 10 rather than powers of 5. Adding the powers of 2 optimization to the reasoning is then straightforward.
> 
> As above, let v0, z0 and s0 be the initial values at method entry of intVal, z and scale, resp.
> We need to return intVal = v0 / 10^z0, scale = s0 - z0.
> 
> Let sexp be the running sum of all exponents exp inside both loops that lead to zero remainders in the division intVal / 10^exp.
> It should be easy to see that both "then" branches maintain
> 
> z = z0 - sexp, intVal = v0 / 10^sexp, scale = s0 - sexp
> 
> and that both branches in both loops maintain
> 
> remainingZeros >= z
> 
> When the 2nd loop exits, remainingZeros = 0, so z = 0. This means z0 = sexp, intVal = v0 / 10^z0, scale = s0 - z0 (correctness).
> 
> In addition, both loops exit for the reasons in the comments (termination) and both loops require very few iterations (quality of service).

@rgiulietti That's correct, although I prefer that the correctness is proved by "reducing the size of the problem" rather than "total number of removed powers", because it was the logic to prove implicitly the correctness of the older implementation, namely by reducing the number of zeros without exceeding the largest scale decreasing allowed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1804936621

From rgiulietti at openjdk.org  Thu Oct 17 15:15:25 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Oct 2024 15:15:25 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <tCDzg9__t_w38gdJMk3-Suvg4Lngh2m-kzLynTBfa5Y=.6781fce7-16e5-465f-96fc-499f0f7af986@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
 <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
 <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>
 <XP8S9VnK0-0PDHcDjVfvjF8LuF-4PLriiX8mu85aT-U=.edba371b-47a3-495a-bac4-345ce2c83ebd@github.com>
 <3clpPOmwcsIOQLIc3Te5vMmYxHl32hTZGEK-dLENKu8=.0e38626f-9205-43e6-bc93-160fb043091b@github.com>
 <tCDzg9__t_w38gdJMk3-Suvg4Lngh2m-kzLynTBfa5Y=.6781fce7-16e5-465f-96fc-499f0f7af986@github.com>
Message-ID: <Ag7nT9F6zYHDnaRIP-HLnP9YqA5riuf43NKruMy-rDg=.24b9995e-cba8-4a24-9780-b35f284b67b9@github.com>

On Thu, 17 Oct 2024 14:51:28 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> OK, let me reformulate the reasoning to check that we are in sync.
>> For simplicity, I'm assuming that the powers of 2 are _not_ stripped away, so I'm using powers of 10 rather than powers of 5. Adding the powers of 2 optimization to the reasoning is then straightforward.
>> 
>> As above, let v0, z0 and s0 be the initial values at method entry of intVal, z and scale, resp.
>> We need to return intVal = v0 / 10^z0, scale = s0 - z0.
>> 
>> Let sexp be the running sum of all exponents exp inside both loops that lead to zero remainders in the division intVal / 10^exp.
>> It should be easy to see that both "then" branches maintain
>> 
>> z = z0 - sexp, intVal = v0 / 10^sexp, scale = s0 - sexp
>> 
>> and that both branches in both loops maintain
>> 
>> remainingZeros >= z
>> 
>> When the 2nd loop exits, remainingZeros = 0, so z = 0. This means z0 = sexp, intVal = v0 / 10^z0, scale = s0 - z0 (correctness).
>> 
>> In addition, both loops exit for the reasons in the comments (termination) and both loops require very few iterations (quality of service).
>
> @rgiulietti That's correct, although I prefer that the correctness is proved by "reducing the size of the problem" rather than "total number of removed powers", because it was the logic to prove implicitly the correctness of the older implementation, namely by reducing the number of zeros without exceeding the largest scale decreasing allowed, and because, at least for me, it is less complex to write and understand.

With the definition remainingZeros = scale - preferredScale, the proof above could be adapted almost on the fly to the old implementation.

In any reduction approach, you still need to prove that the reduced problem is equivalent to the original. This is to say that the running variables (in code and proof) must somehow be related to the initial values.

Anyway, very nice contribution! Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1804972052

From rgiulietti at openjdk.org  Thu Oct 17 15:22:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Oct 2024 15:22:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <Ag7nT9F6zYHDnaRIP-HLnP9YqA5riuf43NKruMy-rDg=.24b9995e-cba8-4a24-9780-b35f284b67b9@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
 <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
 <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>
 <XP8S9VnK0-0PDHcDjVfvjF8LuF-4PLriiX8mu85aT-U=.edba371b-47a3-495a-bac4-345ce2c83ebd@github.com>
 <3clpPOmwcsIOQLIc3Te5vMmYxHl32hTZGEK-dLENKu8=.0e38626f-9205-43e6-bc93-160fb043091b@github.com>
 <tCDzg9__t_w38gdJMk3-Suvg4Lngh2m-kzLynTBfa5Y=.6781fce7-16e5-465f-96fc-499f0f7af986@github.com>
 <Ag7nT9F6zYHDnaRIP-HLnP9YqA5riuf43NKruMy-rDg=.24b9995e-cba8-4a24-9780-b35f284b67b9@github.com>
Message-ID: <217jSP2NY4pHDwzQD2hrR8P5oSQvXY4M7rcK_cFOIPw=.2d3cb579-f496-4ddd-a38e-a395a97ebce5@github.com>

On Thu, 17 Oct 2024 15:12:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> @rgiulietti That's correct, although I prefer that the correctness is proved by "reducing the size of the problem" rather than "total number of removed powers", because it was the logic to prove implicitly the correctness of the older implementation, namely by reducing the number of zeros without exceeding the largest scale decreasing allowed, and because, at least for me, it is less complex to write and understand.
>
> With the definition remainingZeros = scale - preferredScale, the proof above could be adapted almost on the fly to the old implementation.
> 
> In any reduction approach, you still need to prove that the reduced problem is equivalent to the original. This is to say that the running variables (in code and proof) must somehow be related to the initial values.
> 
> Anyway, very nice contribution! Thanks.

Will approve at the beginning of next week to let you add some last minute (not substantial) changes during the next few days.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1804979931

From duke at openjdk.org  Thu Oct 17 15:22:15 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Oct 2024 15:22:15 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <217jSP2NY4pHDwzQD2hrR8P5oSQvXY4M7rcK_cFOIPw=.2d3cb579-f496-4ddd-a38e-a395a97ebce5@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
 <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
 <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>
 <XP8S9VnK0-0PDHcDjVfvjF8LuF-4PLriiX8mu85aT-U=.edba371b-47a3-495a-bac4-345ce2c83ebd@github.com>
 <3clpPOmwcsIOQLIc3Te5vMmYxHl32hTZGEK-dLENKu8=.0e38626f-9205-43e6-bc93-160fb043091b@github.com>
 <tCDzg9__t_w38gdJMk3-Suvg4Lngh2m-kzLynTBfa5Y=.6781fce7-16e5-465f-96fc-499f0f7af986@github.com>
 <Ag7nT9F6zYHDnaRIP-HLnP9YqA5riuf43NKruMy-rDg=.24b9995e-cba8-4a24-9780-b35f284b67b9@github.com>
 <217jSP2NY4pHDwzQD2hrR8P5oSQvXY4M7rcK_cFOIPw=.2d3cb579-f496-4ddd-a38e-a395a97ebce5@github.com>
Message-ID: <sIbtGO255aKlW76i6PNffBUCr65AIXAzpbeH2DRMyOA=.73578603-b9e9-43a8-84f8-c1ca4551f3ea@github.com>

On Thu, 17 Oct 2024 15:17:38 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> With the definition remainingZeros = scale - preferredScale, the proof above could be adapted almost on the fly to the old implementation.
>> 
>> In any reduction approach, you still need to prove that the reduced problem is equivalent to the original. This is to say that the running variables (in code and proof) must somehow be related to the initial values.
>> 
>> Anyway, very nice contribution! Thanks.
>
> Will approve at the beginning of next week to let you add some last minute (not substantial) changes during the next few days.

> In any reduction approach, you still need to prove that the reduced problem is equivalent to the original. This is to say that the running variables (in code and proof) must somehow be related to the initial values.

Yes, although in the proof by "reducing the size of the problem" this should be evident by induction...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1804983630

From jbhateja at openjdk.org  Thu Oct 17 15:33:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 15:33:38 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v26]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <Sjy8msqKoDsvOZPP6tiYVBBnihejr0oU1wLqhnP3veY=.a8a82548-9767-4e7a-b548-1a8c67c788ae@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - New IR tests + additional IR transformations
 - Update adlc changes.
 - Merge branch 'JDK-8338201' of http://github.com/jatin-bhateja/jdk into JDK-8338201
 - Update VectorMath.java
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Typographical error fixups
 - Doc fixups
 - Typographic error
 - Merge stashing and re-commit
 - ... and 19 more: https://git.openjdk.org/jdk/compare/44151f47...c92084d9

-------------

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=25
  Stats: 10221 lines in 55 files changed: 9784 ins; 27 del; 410 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Thu Oct 17 15:45:19 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 15:45:19 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
Message-ID: <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>

On Wed, 16 Oct 2024 19:44:08 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Rather than adding more IR test functionality to this PR that requires additional review my recommendation would be to follow up in another PR or before hand rethink our approach.

Agree, I am thinking of developing an automated IR validation infrastructure for all vector API operations, till then and for the sake of completeness of this patch we can let newly created IR based tests be part of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2419895522

From sspitsyn at openjdk.org  Thu Oct 17 15:56:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 15:56:18 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v5]
In-Reply-To: <NDpcFZo0hBSNwnfqJaVuweX3tgcjOcs63XxIDykGdIc=.1a106349-d351-4bb0-8d29-d3ccb68450f4@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <NDpcFZo0hBSNwnfqJaVuweX3tgcjOcs63XxIDykGdIc=.1a106349-d351-4bb0-8d29-d3ccb68450f4@github.com>
Message-ID: <M6Sa2VzhGAsMAoHWstAHeApRzL4r-WJUMZyVRSxD4rc=.35707321-347a-42db-ba6f-65c23c28ef09@github.com>

On Thu, 17 Oct 2024 09:16:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller

I believe, I've resolved almost all review comments.
Please, let me know if anything is missed or there are some issues in my latest updates.
The mach5 tiers 1-6 are good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2419922957

From sspitsyn at openjdk.org  Thu Oct 17 15:56:20 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 15:56:20 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>
Message-ID: <PA6ZSw_0zaN_4yXaiUqY-8vU7ZsY0zlbNlaYQq-FBc0=.0fb7abd7-869c-4926-80b0-b1a771f2432a@github.com>

On Tue, 15 Oct 2024 21:26:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 588:
> 
>> 586:   // There should not be any VTMS transition here. This is for safety.
>> 587:   if (java_thread->is_in_VTMS_transition()) {
>> 588:     jvf = JvmtiEnvBase::check_and_skip_hidden_frames(java_thread, jvf);
> 
> The code now checks `java_thread->is_in_VTMS_transition()`, so it may be simplified to
> Suggestion:
> 
>     jvf = JvmtiEnvBase::check_and_skip_hidden_frames(true, jvf);

Thank you for the comment. Unfortunately, with my latest update it is not relevant anymore.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 753:
> 
>> 751:     // Skip hidden frames only for carrier threads
>> 752:     // which are in non-temporary VTMS transition.
>> 753:     jvf = check_and_skip_hidden_frames(jt, jvf);
> 
> Can be
> Suggestion:
> 
>     jvf = check_and_skip_hidden_frames(true, jvf);

Thank you for the comment. Unfortunately, with my latest update it is not relevant anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1805031938
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1805032070

From jlu at openjdk.org  Thu Oct 17 16:12:45 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Oct 2024 16:12:45 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v2]
In-Reply-To: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
Message-ID: <OR5iwrd6v7lTWdcCmnuupPZrwQhA9LPUKVMiYa6uyWA=.fd59eba7-93ad-4c13-9eac-2f09817134d5@github.com>

> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
> 
> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review: implSpec -> implNote

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21554/files
  - new: https://git.openjdk.org/jdk/pull/21554/files/c95716a1..cacaecee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21554&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21554&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21554/head:pull/21554

PR: https://git.openjdk.org/jdk/pull/21554

From sviswanathan at openjdk.org  Thu Oct 17 16:19:22 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 17 Oct 2024 16:19:22 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
 <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
Message-ID: <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>

On Thu, 17 Oct 2024 15:41:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Rather than adding more IR test functionality to this PR that requires additional review my recommendation would be to follow up in another PR or before hand rethink our approach.
> 
> Agree, I am thinking of developing an automated IR validation infrastructure for all vector API operations, till then and for the sake of completeness of this patch we can let newly created IR based tests be part of this PR.

@jatin-bhateja I agree with Paul, it would be good to remove the newly added IR test changes from this PR to reduce the load on reviewers. You can always send it as a separate PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2419973468

From jbhateja at openjdk.org  Thu Oct 17 16:25:34 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 16:25:34 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v27]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <ZsejVRsI4V6pi5CWcRMniFQtMAtwcmy7b7-wrd_e1nE=.997911c4-581b-4671-89a1-9bef50c18259@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Prod build fix
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - New IR tests + additional IR transformations
 - Update adlc changes.
 - Merge branch 'JDK-8338201' of http://github.com/jatin-bhateja/jdk into JDK-8338201
 - Update VectorMath.java
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Typographical error fixups
 - Doc fixups
 - ... and 21 more: https://git.openjdk.org/jdk/compare/236c71ca...d9a379b2

-------------

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=26
  Stats: 10219 lines in 55 files changed: 9784 ins; 28 del; 407 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From naoto at openjdk.org  Thu Oct 17 17:21:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Oct 2024 17:21:27 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v3]
In-Reply-To: <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
 <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
Message-ID: <B5uUlsEIC5Z_SxGM1IhULCPWGfOYB4uuAfXqdkVARqg=.35e9c763-8dce-478d-9126-9769d1a2a5eb@github.com>

On Wed, 16 Oct 2024 19:59:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined it more

Issue created for those IDs to be removed: https://bugs.openjdk.org/browse/JDK-8342550

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21545#issuecomment-2420073357

From bpb at openjdk.org  Thu Oct 17 17:48:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 17:48:24 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <sKtWeZfeznbG3pLIsbqFDXY_sNIItNpZbAXR65SK2nA=.2d787fdc-7ac1-4271-8f2a-2f8e5fee540d@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <sKtWeZfeznbG3pLIsbqFDXY_sNIItNpZbAXR65SK2nA=.2d787fdc-7ac1-4271-8f2a-2f8e5fee540d@github.com>
Message-ID: <Hhndq8WNGrTk7AuG7CC--qE2w4ftlObf0_CuPK6CMp0=.fa5007c5-3876-451a-86d5-6fd5d4f7e2b6@github.com>

On Thu, 17 Oct 2024 03:37:30 GMT, xxDark <duke at openjdk.org> wrote:

> I see that my [report](https://bugs.openjdk.org/browse/JDK-8341666) was closed as a duplicate of JDK-8233451 (the bug this PR fixes). This does not resolve the situation with `FileInputStream`?` java.io` will not be fixed?

You are correct. Sorry for the confusion. Either the problem reported in [JDK-8341666](https://bugs.openjdk.org/browse/JDK-8341666) will be addressed in the context of this PR, or that issue will be reopened and addressed by a subsequent PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2420134433

From mullan at openjdk.org  Thu Oct 17 18:03:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Oct 2024 18:03:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
Message-ID: <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>

On Thu, 17 Oct 2024 11:24:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.
>> 
>> If there are other Permission classes you think should have their text modified or removed, let me know.
>
> All JGSS permission classes follow the same style:
> 
> In `javax.security.auth.kerberos.DelegationPermission`:
> 
>  * This class is used to restrict the usage of the Kerberos
>  * delegation model, ie: forwardable and proxiable tickets.
>  ```
> In `javax.security.auth.kerberos.DelegationPermission`:
> 
>  * This class is used to restrict the usage of the Kerberos
>  * delegation model, ie: forwardable and proxiable tickets.

I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1805188374

From bpb at openjdk.org  Thu Oct 17 18:05:40 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 18:05:40 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <Hhndq8WNGrTk7AuG7CC--qE2w4ftlObf0_CuPK6CMp0=.fa5007c5-3876-451a-86d5-6fd5d4f7e2b6@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <sKtWeZfeznbG3pLIsbqFDXY_sNIItNpZbAXR65SK2nA=.2d787fdc-7ac1-4271-8f2a-2f8e5fee540d@github.com>
 <Hhndq8WNGrTk7AuG7CC--qE2w4ftlObf0_CuPK6CMp0=.fa5007c5-3876-451a-86d5-6fd5d4f7e2b6@github.com>
Message-ID: <M8j-Pp96fQLOB4SvSi3C3m9XAyZ03HMVsG3HqENVcPU=.7e47273e-1d2a-4ab1-a9e7-2d7225b6ccb4@github.com>

On Thu, 17 Oct 2024 17:44:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Either the problem reported in [JDK-8341666](https://bugs.openjdk.org/browse/JDK-8341666) will be addressed in the context of this PR, or that issue will be reopened and addressed by a subsequent PR.

@xxDark I reopened [JDK-8341666](https://bugs.openjdk.org/browse/JDK-8341666) which will be addressed by a separate PR. Thanks for pointing out our oversight.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2420183057

From kcr at openjdk.org  Thu Oct 17 18:13:45 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 17 Oct 2024 18:13:45 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal [v4]
In-Reply-To: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
Message-ID: <nk5r14-3w2MmjxmRoIx2SAHxXrelp8FqGlzB5k0zK68=.d52f5002-bd4a-44ab-904a-454118607951@github.com>

> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
> 
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
> 
> This PR does two things:
> 
> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

Kevin Rushforth 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 branch 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Merge branch 'master' into 8311530-depr-jsobject
 - Update javadoc
 - Update copyright years
 - Merge branch 'master' into 8311530-depr-jsobject
 - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test
 - 8311530: Deprecate jdk.jsobject module for removal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20555/files
  - new: https://git.openjdk.org/jdk/pull/20555/files/7afc50ce..e9eb8fb4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20555&range=02-03

  Stats: 29612 lines in 760 files changed: 24122 ins; 2746 del; 2744 mod
  Patch: https://git.openjdk.org/jdk/pull/20555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20555/head:pull/20555

PR: https://git.openjdk.org/jdk/pull/20555

From jbhateja at openjdk.org  Thu Oct 17 18:26:03 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 18:26:03 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v28]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <-wd5wj8QkFZ6vORqWPFZdV_CYCQl2Y7zPNSdW_luNSY=.3c848ace-6cdd-40a5-b924-8feef4346e2d@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Restrict IR validation to newly added UMin/UMax transforms.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/d9a379b2..2b0fa016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=26-27

  Stats: 1373 lines in 3 files changed: 507 ins; 866 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Thu Oct 17 18:26:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 18:26:04 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
 <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
 <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>
Message-ID: <28MMdFkPrGQkT3nD8dUA2GAx6uZyRwERWn3bVvEPSR8=.79c2b5e5-7317-47c5-8878-30c4ac3171ab@github.com>

On Thu, 17 Oct 2024 16:17:02 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> > > Rather than adding more IR test functionality to this PR that requires additional review my recommendation would be to follow up in another PR or before hand rethink our approach.
> > 
> > 
> > Agree, I am thinking of developing an automated IR validation infrastructure for all vector API operations, till then and for the sake of completeness of this patch we can let newly created IR based tests be part of this PR.
> 
> @jatin-bhateja I agree with Paul, it would be good to remove the newly added IR test changes from this PR to reduce the load on reviewers. You can always send it as a separate PR.

I have restricted the IR validation to just newly added UMin/UMax transformations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2420238761

From duke at openjdk.org  Thu Oct 17 18:25:56 2024
From: duke at openjdk.org (wasif kirmani)
Date: Thu, 17 Oct 2024 18:25:56 GMT
Subject: RFR: 8342513: Autoboxing Overhead & Inefficient Parallel Processing
Message-ID: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>

[JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing

-------------

Commit messages:
 - 8342513 : Fixed autoboxing and aprallel processing for big dataset

Changes: https://git.openjdk.org/jdk/pull/21566/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21566&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342513
  Stats: 77 lines in 3 files changed: 28 ins; 9 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/21566.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21566/head:pull/21566

PR: https://git.openjdk.org/jdk/pull/21566

From jbhateja at openjdk.org  Thu Oct 17 18:32:53 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 18:32:53 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v29]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <zh9At4PhK2u3hdvVYSilZ-E23ECKgu4MZqlUc7n161g=.f967f139-da8d-4d28-8f7b-8fee444ba4fb@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Remove Saturating IRNode patterns.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/2b0fa016..3ee0de07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=27-28

  Stats: 40 lines in 1 file changed: 0 ins; 40 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From eirbjo at openjdk.org  Thu Oct 17 18:47:26 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 17 Oct 2024 18:47:26 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <JPJjKswSCLPuUlnPg9rNlRizhP0W6S8TB4WZBrBBhGk=.26866ef0-9900-4ea3-9937-05be6e5cb86e@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
 <7IxPd36daC_uVSUiZ6-1ZNbXJUHlo-rbgjfumkItAaw=.74556159-722e-4da1-bd98-e37e115e479c@github.com>
 <JPJjKswSCLPuUlnPg9rNlRizhP0W6S8TB4WZBrBBhGk=.26866ef0-9900-4ea3-9937-05be6e5cb86e@github.com>
Message-ID: <mtp428G15vGas0-nl19JjLQgR3vSm7sCSAIW1j9EVU0=.d16da4c2-8c2d-4610-9893-670294c99941@github.com>

On Thu, 17 Oct 2024 13:56:50 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I had thought about that and decided to keep the changes as they are. I am not opposed to revisiting this in a follow on PR. Any additional changes would require more javadoc updates to address the overall change in validation.
> 
> So after we fork JDK 24, happyt to revisit.

If the route we're taking ends up with having `ZipEntry` manage its own invariant here, then I'm only lukewarm to including this solution in 24 which only takes us half way and has weaker validation than what's already in place in `ZipOutputStream`.  There would be less API churn if we hold our breath here and do it "right" in a single release.

But that's my subjective opinion, it's understandable and fine that others see it differently.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1805262740

From vklang at openjdk.org  Thu Oct 17 19:28:23 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 17 Oct 2024 19:28:23 GMT
Subject: RFR: 8342513: Autoboxing Overhead & Inefficient Parallel
 Processing
In-Reply-To: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
References: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
Message-ID: <B1r3Z1eJgIcb-9q60S6uz4EMSP6VV400rzYfMTpyvGA=.d0003529-c479-413e-b473-73e1b1caea73@github.com>

On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani <duke at openjdk.org> wrote:

> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing

@kirmaniwasif Hi!

First of all, thanks for wanting to help out!

After reviewing the proposed changes I have some comments and questions for you:

- The primitive streams (DoubleStream, IntStream, and LongStream) are designed to avoid boxing, so I'm curious as to which step has proven unable to do so, and how this PR addresses that?
- An operation changing a stream from a sequential one to a parallel one without user opting in is definitely going to be problematic. Not only does that change observable behavior, but it also is likely going to have adverse effects on performance.
- When offering a PR to improve performance, it is important to share what methodology is used for obtaining the baseline numbers and numbers indicating the performance of the proposed change. This is usually done by creating and/or running JMH-based benchmarks. And including the numbers (allocation rates, throughput, latency, etc)
- Invoking `spliterator()` on a Stream is a terminal operation, and after that has been invoked the stream has been consumed, so when I do the following on your proposed change I get an exception:


jshell> DoubleStream.of(1d, 2d).filter(d -> d > 0d).filter(d -> d > 0d).forEach(d -> System.out.println(d))
|  Exception java.lang.IllegalStateException: stream has already been operated upon or closed
|        at AbstractPipeline.<init> (AbstractPipeline.java:201)
|        at DoublePipeline.<init> (DoublePipeline.java:91)
|        at DoublePipeline$StatelessOp.<init> (DoublePipeline.java:674)
|        at DoublePipeline$8.<init> (DoublePipeline.java:358)
|        at DoublePipeline.filter (DoublePipeline.java:357)
|        at (#1:1)


Without the PR changes it works as expected:


jshell> DoubleStream.of(1d, 2d).filter(d -> d > 0d).filter(d -> d > 0d).forEach(d -> System.out.println(d))
1.0
2.0


Cheers,
?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21566#issuecomment-2420357230

From lancea at openjdk.org  Thu Oct 17 19:32:49 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 17 Oct 2024 19:32:49 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <mtp428G15vGas0-nl19JjLQgR3vSm7sCSAIW1j9EVU0=.d16da4c2-8c2d-4610-9893-670294c99941@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
 <7IxPd36daC_uVSUiZ6-1ZNbXJUHlo-rbgjfumkItAaw=.74556159-722e-4da1-bd98-e37e115e479c@github.com>
 <JPJjKswSCLPuUlnPg9rNlRizhP0W6S8TB4WZBrBBhGk=.26866ef0-9900-4ea3-9937-05be6e5cb86e@github.com>
 <mtp428G15vGas0-nl19JjLQgR3vSm7sCSAIW1j9EVU0=.d16da4c2-8c2d-4610-9893-670294c99941@github.com>
Message-ID: <hZ4GNMOS7qO6W9ESnz0NwnxZSFQ2FZMmMJwU66lASHc=.7479104d-e1b3-4bc5-a4b3-e77f1a759701@github.com>

On Thu, 17 Oct 2024 18:45:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> But that's my subjective opinion, it's understandable and fine that others see it differently.

Again, I understand your suggestion and will give it some  additional thought. The original intent was to address the incorrect max value that each of the 3 fields were being validated against, which has been there since at least JDK 1.3.
 
Overall this is a corner case and out of a search of 90,000+ jars, only 520 CEN Headers were encountered with a size between 500-1000 bytes, all other entries were < 500 bytes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1805311563

From duke at openjdk.org  Thu Oct 17 19:43:09 2024
From: duke at openjdk.org (wasif kirmani)
Date: Thu, 17 Oct 2024 19:43:09 GMT
Subject: RFR: 8342513: Autoboxing Overhead & Inefficient Parallel
 Processing
In-Reply-To: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
References: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
Message-ID: <AmpsqDZ6Tyn_R9KecLE7wzgpmTAnUY6QAHtyS_MqgsI=.a680f905-4933-4a29-a718-4bda455abbdf@github.com>

On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani <duke at openjdk.org> wrote:

> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing

Thank you for your detailed feedback and the opportunity to clarify the proposed changes. 
The issue raised was not about the primitive streams performing unnecessary boxing, but rather about efficiently handling larger streams with more complex operations (e.g., filtering large datasets).

You're absolutely right: changing a sequential stream to a parallel one without explicit user consent introduces both observable behavior changes and possible performance degradation. Stream behavior (especially around parallelism) is something that users explicitly opt into, and this control should remain in the user's hands.

Plan for Resolution:
I will remove the automatic parallelization logic and ensure that users maintain control over when a stream becomes parallel. Any optimizations for parallel streams should only apply when the stream is explicitly parallelized by the user (via .parallel()).

Thank you for pointing this out. This issue occurs due to my incorrect assumption regarding the spliterator() method. As you correctly noted, invoking spliterator() on a stream is considered a terminal operation, which effectively consumes the stream, making it unusable for further operations.

This problem arises from trying to split the stream based on size and then applying the filter, which in turn attempts to reuse the consumed stream, causing the IllegalStateException.

Plan for Resolution:
I will rework the logic to avoid prematurely consuming the stream by calling spliterator(). Instead of trying to conditionally split the stream based on size, I will focus on optimizing the filtering operation while preserving the sequential or parallel nature of the stream as defined previously.
Additionally, I will review the stream lifecycle and ensure that no terminal operation is mistakenly invoked before all intermediate operations are applied.

I verified the filter by implementing time changes with IntStream and found out that:
 long startTime = System.nanoTime();
        long count = optimizedIntStream(IntStream.range(0, 1_000_000))
            .filter(n -> n % 2 == 0)  
            .count();
        long endTime = System.nanoTime();
        
Java 23 filter count: 500000
Java 23 filter execution time: 10 ms
Optimized filter count: 500000
Optimized filter execution time: 5 ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21566#issuecomment-2420381760

From jbhateja at openjdk.org  Thu Oct 17 19:43:21 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 19:43:21 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v3]
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
Message-ID: <0DYInN_-F8fysBMmkpd_MNYVqRE6gPeVqqsphPdKneQ=.6cc6ca2d-5d0b-4e20-a291-b5ba3f9f8717@github.com>

> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>   
> 
>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>  
> VPMULUDQ 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
> VectorXXH3HashingB...

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'JDK-8341137' of http://github.com/jatin-bhateja/jdk into JDK-8341137
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
 - Review resoultions
 - 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=02
  Stats: 349 lines in 12 files changed: 338 ins; 0 del; 11 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 Oct 17 19:43:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 19:43:22 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.7580c0c3-0bdb-44c5-afd2-2a4226ff7274@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.7580c0c3-0bdb-44c5-afd2-2a4226ff7274@github.com>
Message-ID: <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.f25d813b-b0ba-4c1e-9e77-6e86dfd34de7@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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2420384086

From jbhateja at openjdk.org  Thu Oct 17 19:43:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 17 Oct 2024 19:43:24 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.a6df3ca8-6ddd-4c7e-a803-292a5695f1e4@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.a6df3ca8-6ddd-4c7e-a803-292a5695f1e4@github.com>
Message-ID: <yq7iDk-ZY8JPHaO-C_lhEYiPeDT1snI52a00uzEhFz4=.65e5858d-4c0d-47d5-afe6-873cc67b2a52@github.com>

On Mon, 14 Oct 2024 21:26:41 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction
>
> 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.

Ah, these harmless cunning typos :-), but we should not rely on c-compiler's short circuiting.

> 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.

We do need those nodes to chop off the upper double words of quadword lanes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1805324915
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1805324796

From naoto at openjdk.org  Thu Oct 17 19:49:48 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Oct 2024 19:49:48 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v2]
In-Reply-To: <OR5iwrd6v7lTWdcCmnuupPZrwQhA9LPUKVMiYa6uyWA=.fd59eba7-93ad-4c13-9eac-2f09817134d5@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
 <OR5iwrd6v7lTWdcCmnuupPZrwQhA9LPUKVMiYa6uyWA=.fd59eba7-93ad-4c13-9eac-2f09817134d5@github.com>
Message-ID: <oKyk3ajU7xfv_SNiXIY2mPAZdfWsi2uPtQsx4Qy6zWc=.073634f3-622b-4f62-94ec-cfd6d104751a@github.com>

On Thu, 17 Oct 2024 16:12:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
>> 
>> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: implSpec -> implNote

LGTM, with a minor nit

src/java.base/share/classes/java/text/MessageFormat.java line 113:

> 111:  *
> 112:  * <p>
> 113:  * The <b>ArgumentIndex</b> value is a non-negative integer written

If we would deviate from the format in the above form, I'd use @code tag, instead of explicit <b>.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21554#pullrequestreview-2376134108
PR Review Comment: https://git.openjdk.org/jdk/pull/21554#discussion_r1805329693

From naoto at openjdk.org  Thu Oct 17 20:07:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Oct 2024 20:07:06 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln
Message-ID: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>

Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/21569/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341975
  Stats: 93 lines in 4 files changed: 52 ins; 37 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21569/head:pull/21569

PR: https://git.openjdk.org/jdk/pull/21569

From jlu at openjdk.org  Thu Oct 17 20:11:16 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Oct 2024 20:11:16 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v3]
In-Reply-To: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
Message-ID: <W73IBb3sHKEZQNokaC4oxmEmOi5YS2Mg3Ef7y5NXCXU=.cf2a8ec1-9484-43bb-9531-4be66c8c2e54@github.com>

> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
> 
> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review: <b> -> code tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21554/files
  - new: https://git.openjdk.org/jdk/pull/21554/files/cacaecee..448c2453

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21554&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21554&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21554/head:pull/21554

PR: https://git.openjdk.org/jdk/pull/21554

From jlu at openjdk.org  Thu Oct 17 20:19:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Oct 2024 20:19:52 GMT
Subject: RFR: 8340554: Improve MessageFormat readObject checks
Message-ID: <0hSlYistdp3kSZMl2Frm65PSONFmtwpkx0EcJb_x1-E=.8f597ec0-df3c-499b-a555-92ede1bb1cfb@github.com>

Please review this PR which improves the readObject logic for _j.text.MessageFormat_.

No offset should be larger than the pattern length. We already ensure the offsets when consumed backwards are equal/descending. The existing first/initial check was off by 1 since it was checking against the pattern length + 1; (see L2040 and L2043).

Please see the JBS issue for further info and other test details.

-------------

Commit messages:
 - test corrections
 - add 'good' test cases
 - init

Changes: https://git.openjdk.org/jdk/pull/21570/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340554
  Stats: 9 lines in 2 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21570/head:pull/21570

PR: https://git.openjdk.org/jdk/pull/21570

From naoto at openjdk.org  Thu Oct 17 20:25:40 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Oct 2024 20:25:40 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v2]
In-Reply-To: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
Message-ID: <pRwHfJTJTU64D5BdOB8ixl8W6Np6KBSnFe6uyObKRso=.1fa4b113-f5df-4db5-8dc7-ff4ae4be5f0e@github.com>

> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  A bit of re-org

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21569/files
  - new: https://git.openjdk.org/jdk/pull/21569/files/43f4e87e..581bed89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=00-01

  Stats: 9 lines in 2 files changed: 3 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21569/head:pull/21569

PR: https://git.openjdk.org/jdk/pull/21569

From duke at openjdk.org  Thu Oct 17 20:26:33 2024
From: duke at openjdk.org (xxDark)
Date: Thu, 17 Oct 2024 20:26:33 GMT
Subject: RFR: 8342513: Autoboxing Overhead & Inefficient Parallel
 Processing
In-Reply-To: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
References: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
Message-ID: <qr9dXKFX4uwPrSWYbWZI9DINTTlYoZ9_5DDdtVlBzL0=.1c151174-f445-44f4-9949-3e3b21270050@github.com>

On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani <duke at openjdk.org> wrote:

> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing

This seems like an AI-generated change... Also, turning a stream into a parallel one is a recipe for disaster.
Consider this case:

var smallNumbers = new ArrayList<>(1_000_000);
var count = new AtomicInteger();
for (int i = 0; i < 3; i++) {
	count.set(0);
	smallNumbers.clear();
	var _ = IntStream.generate(() -> {
				return ThreadLocalRandom.current().nextInt(Character.MAX_VALUE);
			})
			.limit(9_000_000)
			.parallel() // Your code calls parallel here
			.filter(value -> {
				// Collecting in-place to smallNumbers
				if (value < 32768) {
					smallNumbers.add(value);
					count.incrementAndGet();
					return false;
				}
				return true;
			})
			.count(); // Terminate
	if (smallNumbers.size() != count.get()) {
		throw new IllegalStateException();
	}
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21566#issuecomment-2420485311

From rriggs at openjdk.org  Thu Oct 17 20:31:36 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Oct 2024 20:31:36 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v3]
In-Reply-To: <W73IBb3sHKEZQNokaC4oxmEmOi5YS2Mg3Ef7y5NXCXU=.cf2a8ec1-9484-43bb-9531-4be66c8c2e54@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
 <W73IBb3sHKEZQNokaC4oxmEmOi5YS2Mg3Ef7y5NXCXU=.cf2a8ec1-9484-43bb-9531-4be66c8c2e54@github.com>
Message-ID: <0qfI0Sz12Fj-3DdgkOm4_dw2H4kVvJZpoKmJ8zymSTw=.d0b803e5-ea38-4034-a1bd-a947cd980d09@github.com>

On Thu, 17 Oct 2024 20:11:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
>> 
>> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: <b> -> code tag

GTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21554#pullrequestreview-2376222790

From rriggs at openjdk.org  Thu Oct 17 20:31:39 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Oct 2024 20:31:39 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v11]
In-Reply-To: <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <jxm4zpRVkHlXnHtFwX78Abj8mwJze1Dqzg-XaoYfG4Y=.8ec33858-1f60-45e7-a118-357ec5c875bc@github.com>
Message-ID: <o_WCivqs_v9wl-ZoOhiimF3cCiESWKPfT3FvXknhijE=.cd4f8c3e-d56c-4ca8-8259-d877f9d4f53d@github.com>

On Sat, 12 Oct 2024 07:47:56 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'inc should be faster than add on most CPUs'

Thanks for the updates; LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2376225684

From rriggs at openjdk.org  Thu Oct 17 20:34:49 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Oct 2024 20:34:49 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v6]
In-Reply-To: <7Di2YTFOv-Q0OzRYMgHEfjP-K0LXYJnvTE7KZ0zFJ-g=.9afcf33b-9e18-4822-ae5e-6c91cb338ce4@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <7Di2YTFOv-Q0OzRYMgHEfjP-K0LXYJnvTE7KZ0zFJ-g=.9afcf33b-9e18-4822-ae5e-6c91cb338ce4@github.com>
Message-ID: <me2Hd6N658Sad2Y3mBWWMa3TKW4F42Nlb_b5HG02sGc=.9bc968a7-5d3c-4d09-8ffc-9fe6c6087694@github.com>

On Wed, 25 Sep 2024 12:58:20 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:
> 
>   Address review feedback

src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java line 194:

> 192:         return delegate.serialPersistentFields(cl);
> 193:     }
> 194: 

Can the serialPersistentFields method be moved to keep the defaultRead... and defaultWrite... method next to each other. (and be consistent with the other ReflectionFactory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1794241140

From mchung at openjdk.org  Thu Oct 17 20:49:46 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 17 Oct 2024 20:49:46 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification for
 core reflection
Message-ID: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>

The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3] uncovered over time.

The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   These VM hacks can be removed together with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   In addition, the special metaspace for reflection can also be removed.   I will create a separate issue to remove `Metaspace::ReflectionMetaspaceType` and update existing GTests together.

[1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
[2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
[3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

-------------

Commit messages:
 - 8327624: Remove VM implementation that bypass verification for core reflection

Changes: https://git.openjdk.org/jdk/pull/21571/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21571&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327624
  Stats: 981 lines in 17 files changed: 0 ins; 973 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21571/head:pull/21571

PR: https://git.openjdk.org/jdk/pull/21571

From naoto at openjdk.org  Thu Oct 17 20:59:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 17 Oct 2024 20:59:01 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v3]
In-Reply-To: <W73IBb3sHKEZQNokaC4oxmEmOi5YS2Mg3Ef7y5NXCXU=.cf2a8ec1-9484-43bb-9531-4be66c8c2e54@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
 <W73IBb3sHKEZQNokaC4oxmEmOi5YS2Mg3Ef7y5NXCXU=.cf2a8ec1-9484-43bb-9531-4be66c8c2e54@github.com>
Message-ID: <gT4NbEwJMfY2sJdOz9T7pijaFaZoX3aL1e_miMWVn3Y=.524c5c00-d033-4c36-8224-be2ac023a924@github.com>

On Thu, 17 Oct 2024 20:11:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
>> 
>> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: <b> -> code tag

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21554#pullrequestreview-2376282314

From duke at openjdk.org  Thu Oct 17 21:24:59 2024
From: duke at openjdk.org (duke)
Date: Thu, 17 Oct 2024 21:24:59 GMT
Subject: RFR: 8311530: Deprecate jdk.jsobject module for removal [v4]
In-Reply-To: <nk5r14-3w2MmjxmRoIx2SAHxXrelp8FqGlzB5k0zK68=.d52f5002-bd4a-44ab-904a-454118607951@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
 <nk5r14-3w2MmjxmRoIx2SAHxXrelp8FqGlzB5k0zK68=.d52f5002-bd4a-44ab-904a-454118607951@github.com>
Message-ID: <OPgjXmQP_NpruqrHY_nIQ1UmwsN7VMvRCuL5z91rnZI=.3846baf0-e267-4254-b8a0-7f3ebf33960b@github.com>

On Thu, 17 Oct 2024 18:13:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
>> 
>> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
>> 
>> This PR does two things:
>> 
>> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
>> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.
>
> Kevin Rushforth 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 branch 'master' into 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Update javadoc
>  - Update copyright years
>  - Merge branch 'master' into 8311530-depr-jsobject
>  - Add jdk.jsobject to list of UPGRADEABLE_MODULES in UpgradeableModules test
>  - 8311530: Deprecate jdk.jsobject module for removal

@kevinrushforth 
Your change (at version e9eb8fb45613dc8051b63d82e97f5c140c333304) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20555#issuecomment-2420596810

From vlivanov at openjdk.org  Thu Oct 17 21:57:06 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 17 Oct 2024 21:57:06 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.f25d813b-b0ba-4c1e-9e77-6e86dfd34de7@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.7580c0c3-0bdb-44c5-afd2-2a4226ff7274@github.com>
 <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.f25d813b-b0ba-4c1e-9e77-6e86dfd34de7@github.com>
Message-ID: <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.c088a91d-ef71-48ca-b7dd-e39a224523bf@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?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2420668490

From liach at openjdk.org  Thu Oct 17 22:06:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Oct 2024 22:06:14 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection
In-Reply-To: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
Message-ID: <oODbuFH2zjuvwWvgpcUNpAStux1PurM6UhW74YC_z00=.0c4fc01a-e389-4db7-87f3-02aca92e3ade@github.com>

On Thu, 17 Oct 2024 20:45:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
> 
> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
> 
> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
> 
> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

It seems we can now remove `AccessorGenerator`, `ByteVector*`, `ClassFile*`, `Label`, and `MagicAccessorImpl` Java files from `jdk.internal.reflect`. Do we plan to do that in another RFE?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21571#issuecomment-2420680392

From bpb at openjdk.org  Thu Oct 17 22:14:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 22:14:59 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
Message-ID: <B8Rns0_aYc_nZGjxQael8igpi7Lj5FMHGPgVSEcHStE=.40144816-89f0-4c67-affb-d2ce8477341e@github.com>

On Thu, 17 Oct 2024 11:20:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8233451: Remove use of handleAvailable() (Windows)
>>  - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c line 233:
> 
>> 231: 
>> 232:     return JNI_TRUE;
>> 233: }
> 
> Can you check if any of these syscalls can fail with EINTR? I don't think so but need to check.

None of them are documented to so fail in the Linux and macOS man pages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805502975

From joehw at openjdk.org  Thu Oct 17 22:22:14 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 17 Oct 2024 22:22:14 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v3]
In-Reply-To: <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
 <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
Message-ID: <i1eCulObS6lnbMSG7T1QKsRVhONAboK-9KXUx3sXRXc=.6edc07fd-c6ca-48c8-ad21-b1e28d37743d@github.com>

On Wed, 16 Oct 2024 19:59:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined it more

Nice cleanup.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21545#pullrequestreview-2376418221

From redestad at openjdk.org  Thu Oct 17 22:35:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 17 Oct 2024 22:35:22 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
 <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
 <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>
Message-ID: <rJ5z1Z1yVMcXP1JKrybs08oBvYkjhZ-J8dF0ma-A7IY=.dbcc5fac-97f0-49f6-b168-aa1ac651bca9@github.com>

On Thu, 17 Oct 2024 08:40:05 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> I guess performance leans on there being only one or a small number of versions per entry. Which I think is a fair assumption. Still would be good to have a stress test with many entries having many versions and make sure we don't regress such cases too much, no?
>
>> I guess performance leans on there being only one or a small number of versions per entry. 
> 
> I checked Spring Petclinic:
> 
> * 109 JAR dependencies
> * 15 are multi-release enabled.
> * The 15 MR-JARs have 9347 entries, of which 21 are versioned
> * 9 of 15 MR JARs use the feature exclusively to hide `module-info.class` from Java 8.
> * 3 of the 6 remaining JAR files version a single class file
> * The remaining JARs mostly version on the 9 release.
> * The maximum number of versioned entries in a file is 5.
> * Zero entries have more than a single version.
> 
>> Which I think is a fair assumption. Still would be good to have a stress test with many entries having many versions and make sure we don't regress such cases too much, no?
> 
> Such a test would be somewhat speculative. If I add 5 versions of each entry in `ZipFileOpen`, then yes, this PR sees a regression over mainline:
> 
> Baseline:
> 
> Benchmark                     (size)  Mode  Cnt       Score       Error  Units
> ZipFileOpen.openCloseZipFile    1024  avgt   15  718234.380 ? 29454.645  ns/op
> 
> 
> PR:
> 
> Benchmark                     (size)  Mode  Cnt        Score       Error  Units
> ZipFileOpen.openCloseZipFile    1024  avgt   15  1284944.601 ? 74919.522  ns/op
> 
> 
> While `JarFileGetEntry` improves over baseline:
> 
> Baseline:
> 
> Benchmark                              (mr)  (size)  Mode  Cnt    Score   Error  Units
> JarFileGetEntry.getEntryHit           false    1024  avgt   15   68.984 ? 2.791  ns/op
> JarFileGetEntry.getEntryHit            true    1024  avgt   15  324.763 ? 9.690  ns/op
> JarFileGetEntry.getEntryHitUncached   false    1024  avgt   15   95.884 ? 1.404  ns/op
> JarFileGetEntry.getEntryHitUncached    true    1024  avgt   15  333.491 ? 3.576  ns/op
> JarFileGetEntry.getEntryMiss          false    1024  avgt   15   37.358 ? 2.215  ns/op
> JarFileGetEntry.getEntryMiss           true    1024  avgt   15  650.467 ? 5.116  ns/op
> JarFileGetEntry.getEntryMissUncached  false    1024  avgt   15   61.059 ? 0.382  ns/op
> JarFileGetEntry.getEntryMissUncached   true    1024  avgt   15  678.457 ? 4.390  ns/op
> 
> 
> PR:
> 
> 
> Benchmark                              (mr)  (size)  Mode  Cnt    Score    Error  Units
> JarFileGetEntry.getEntryHit           false    1024  avgt   15   61.333 ?  3.665  ns/op
> JarFileGetEntry.getEntryHit            true    1024  avgt   15  153.987 ?  8.889  ns/op
> JarFileGetEntry.getEntryHitUncached   false    1024  avgt   15   90.008 ?  4.158  ns/op
> JarFileGetEntry.getEntryHitUncached    true    1024  avgt   15  168.831 ?  1.676  ns/o...

I poked around with an alternative approach that uses `java.util.BitSet`. This also allows us to use the map we build up as-is, avoids sorting et.c. Performance on `JarFileGetEntry` (#21489 version) is the same in my testing, but performance on `ZipFileOpen` with your 5 versions of each entry stress test should be much improved (might beat the baseline). Can you share your local changes to that micro in a gist or e-mail so I can verify?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1805524895

From vlivanov at openjdk.org  Thu Oct 17 22:36:23 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 17 Oct 2024 22:36:23 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <HvR4CCPeXXjDit9Tz6g71KbKIoPkXtJo0h5d4iQLD44=.efe1b43f-b3f4-4e8b-8d43-4c2c941b19a1@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <Zu93PI-ZSrlkhthhBjZoqlZZ8oKd0-G_aclNTxOJurE=.ba563dba-6eeb-4eaf-a312-3d4b8c9b02fe@github.com>
 <HvR4CCPeXXjDit9Tz6g71KbKIoPkXtJo0h5d4iQLD44=.efe1b43f-b3f4-4e8b-8d43-4c2c941b19a1@github.com>
Message-ID: <b9wBuOTqWnB5l-dL9OOuVx8cOsPa7yPb1rtOJrjjyfU=.a0e5ed16-e081-44d7-9aaa-1bed36c6cb2c@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 mchung at openjdk.org  Thu Oct 17 22:44:05 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 17 Oct 2024 22:44:05 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
Message-ID: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>

> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
> 
> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
> 
> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
> 
> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21571/files
  - new: https://git.openjdk.org/jdk/pull/21571/files/4753637c..245cfb6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21571&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21571&range=00-01

  Stats: 1836 lines in 11 files changed: 0 ins; 1832 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21571.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21571/head:pull/21571

PR: https://git.openjdk.org/jdk/pull/21571

From duke at openjdk.org  Thu Oct 17 22:44:07 2024
From: duke at openjdk.org (wasif kirmani)
Date: Thu, 17 Oct 2024 22:44:07 GMT
Subject: RFR: 8342513: Autoboxing Overhead & Inefficient Parallel
 Processing
In-Reply-To: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
References: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
Message-ID: <xGo0Q5DtGoqqIhgGRjva7HMDfluHfC8xGcFKbllX5wk=.44a37754-a7f9-465b-8a0d-8522c01bd9ca@github.com>

On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani <duke at openjdk.org> wrote:

> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing

> [xxDark](/xxDark)

Quite an allegation. Well, I initially wrote it for IntStraem and as I mentioned the performance change I found and it was working fine. But, yes I couldn't check it thoroughly which was my bad.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21566#issuecomment-2420742010

From duke at openjdk.org  Thu Oct 17 22:44:07 2024
From: duke at openjdk.org (wasif kirmani)
Date: Thu, 17 Oct 2024 22:44:07 GMT
Subject: Withdrawn: 8342513: Autoboxing Overhead & Inefficient Parallel
 Processing
In-Reply-To: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
References: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
Message-ID: <1svlcE8vdh_rKLcbXfbwvykThPphYR-2MxykULysC6I=.e706e88a-d875-4517-8eb0-ccf23508da32@github.com>

On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani <duke at openjdk.org> wrote:

> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21566

From mchung at openjdk.org  Thu Oct 17 22:44:06 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 17 Oct 2024 22:44:06 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection
In-Reply-To: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
Message-ID: <tcwHq7I7vx0-rYOPFW4n2PU2_lQ7wMRW_KDsaQAZ_j0=.51c264ac-2e3d-4801-aaa4-89a7e1de328a@github.com>

On Thu, 17 Oct 2024 20:45:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
> 
> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
> 
> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
> 
> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

Good catch!  Patch updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21571#issuecomment-2420740316

From bpb at openjdk.org  Thu Oct 17 22:55:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 22:55:57 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v3]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <TZWrkJHDEt5WqBMzCvVt5ivmcW5cYIRt3rrnh_-_LSs=.6ce4cb1f-2ffb-4704-94c9-50d3bf644c3d@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 8233451: Do not initialize isOther to null
 - 8233451: Address reviewer comments; convert test to JUnit 5

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/51df5d81..492659f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=01-02

  Stats: 62 lines in 4 files changed: 32 ins; 6 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

PR: https://git.openjdk.org/jdk/pull/21508

From bpb at openjdk.org  Thu Oct 17 22:55:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 22:55:58 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
Message-ID: <KEfmTSY5hGpjwbKHLiY5eebwNp2u9zjK9qMzMj3I5pM=.2e29d341-401f-4707-baba-2f1a57f01de0@github.com>

On Thu, 17 Oct 2024 11:14:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8233451: Remove use of handleAvailable() (Windows)
>>  - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 56:
> 
>> 54:     private byte[] b1;
>> 55: 
>> 56:     private Boolean isOther = null;
> 
> I don't particularly like using a Boolean for tri-states but it's not too bad here. No need to initialize to null. It could be Stable but probably not much benefit here all usages require file I/O that dominates.
> 
> Are you going to add a comment to this field as readers might know now what "other" means? In the APIs we say "something other than a regular file, directory, or symbolic link" and maybe that could be useful here.

Fixed in a163d8d and 492659f.

> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 533:
> 
>> 531:     }
>> 532: 
>> 533:     public int available() throws IOException {
> 
> This can be package-private. It would be useful to add a method description as FC doesn't define this method, same thing for isOther.

Fixed in a163d8d.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805544190
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805544463

From bpb at openjdk.org  Thu Oct 17 22:59:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 17 Oct 2024 22:59:57 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
Message-ID: <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>

On Thu, 17 Oct 2024 11:17:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8233451: Remove use of handleAvailable() (Windows)
>>  - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 565:
> 
>> 563:                 return isOther = nd.isOther(fd);
>> 564:             } finally {
>> 565:                 Blocker.end(attempted);
> 
> No need for Blocker begin/end here, we only use for direct I/O or file locking.

Fixed in a163d8d.

> test/jdk/java/nio/file/Files/InputStreamTest.java line 139:
> 
>> 137:             InputStream s = Files.newInputStream(stdin);
>> 138:             s.available();
>> 139:         }
> 
> I assume you meant to close the input stream.
> 
> What about the other methods defined by InputStream that have special handling in ChannelInputStream? I assume we should add test coverage for these methods.

I added test coverage for `skip` but not for `readAllBytes` nor `readNBytes`:
- `readAllBytes` throws before but hangs after the change;
- `readNBytes` hangs both before and after the change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805546933
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1805546604

From vlivanov at openjdk.org  Thu Oct 17 23:02:59 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 17 Oct 2024 23:02:59 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v9]
In-Reply-To: <qJE1LA6Oe5e7nsAnMmNVdB7uI3_O8x1znkkCsUxjvGc=.971ca044-0168-4163-ba9a-b767104ae8f3@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
 <qJE1LA6Oe5e7nsAnMmNVdB7uI3_O8x1znkkCsUxjvGc=.971ca044-0168-4163-ba9a-b767104ae8f3@github.com>
Message-ID: <mAq5JIIQiH2XX8ABS1ZQl_Ho5mrPXR3gqZLBnxRUpjM=.64e6e6bf-497b-4117-83d7-8023dcb36ec9@github.com>

On Wed, 16 Oct 2024 00:03:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 16 additional commits since the last revision:
> 
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - reviews from @iwanowww and @rose00 -- move USE_SOFT_CACHE to MethodHandleNatives as a @Stable field; use system prop for init
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @liach and @cl4es comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/31f55db0...11391c39

Still looks good except `@Stable` on `USE_SOFT_CACHE`. As it is implemented now, I don't see any point in dropping `final` in favor of `@Stable` since it is initialized only once and only from static initializer.

@iklam I'd be surprised if this class is AOT-initialized. I hope it's not the case here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21049#issuecomment-2420771205

From duke at openjdk.org  Thu Oct 17 23:25:13 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 17 Oct 2024 23:25:13 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v44]
In-Reply-To: <sIbtGO255aKlW76i6PNffBUCr65AIXAzpbeH2DRMyOA=.73578603-b9e9-43a8-84f8-c1ca4551f3ea@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <4zcNxRvJVyE51td2yyqdSab2gtmY6XL_ytxBN9Tzkms=.20bbaea6-dca6-4ddd-bb9b-7815a68982c4@github.com>
 <tHQZOlmNunXLLYQOZy9MTRUAVJLLote5HceK4XWKOgU=.61b88f81-0624-4de6-b105-a6b5e6c06a1b@github.com>
 <R_oyx3hbDVCnkRRw9EAOnKwsbuWS0fzOGlmoDTvRSTM=.2fdf7673-b6a7-463e-9d1d-038cbfaaf78e@github.com>
 <vT8RFK-rPvnnoEIz_u5NsVlJtYatL2lVHJ83x1pC92U=.80867aee-86d1-42ec-b051-0ff7ed597b6d@github.com>
 <R7RYwlFwAbHAwGRXYwC2SGJzeg3ecrNdKzV5ptYZEIg=.cd789529-45db-4556-9501-359510dccfe8@github.com>
 <SUtk7-6Bq0EkptM0iG-QNLBFw35hMJ3ghP1nFK2qpEc=.ae85984c-4ee1-484e-9484-5cafd242dc2a@github.com>
 <NRT9hs6460XEQcziv_ZcUMhxuLTbXk0deAonMpSjAaI=.a59b02f7-2af9-4739-99eb-5a39c418a696@github.com>
 <YK22A8A2iycfaXbbClc6ZqVr9ZO_Oojur-avHAj2rg8=.53606430-850d-43c4-a1c9-31fb71a91f61@github.com>
 <FGi18tJDZXgQPglM6ytVVCLtqyRRyNoqWbLF0NHR1pc=.f121b0a4-151c-4896-85cd-1a46a5d54200@github.com>
 <IINUkqZh-wZg5JQ6pUfhLrVCrAxAilqrp-f
 4EbkQV2g=.5cc39033-6c95-46ba-96de-8eb1ae5096b1@github.com>
 <7CgNg8TsEjdyiVRshEHqgxHoQUJ7MfaZQkZ-psAk8Ys=.955319be-b734-4802-8347-c686c29596a9@github.com>
 <-o4uFD5xgJcVQdaC774sZn9MhKcsgnUDwZParJPPxcI=.b2b7bb09-6284-429e-a9f2-27ba478da602@github.com>
 <Oj4nF1MqPocw-dmr7sX3ytLlX2kVD7kew9X2QYV4JwU=.5c63ed46-0472-4d8f-bb75-b9e27ab38fff@github.com>
 <XP8S9VnK0-0PDHcDjVfvjF8LuF-4PLriiX8mu85aT-U=.edba371b-47a3-495a-bac4-345ce2c83ebd@github.com>
 <3clpPOmwcsIOQLIc3Te5vMmYxHl32hTZGEK-dLENKu8=.0e38626f-9205-43e6-bc93-160fb043091b@github.com>
 <tCDzg9__t_w38gdJMk3-Suvg4Lngh2m-kzLynTBfa5Y=.6781fce7-16e5-465f-96fc-499f0f7af986@github.com>
 <Ag7nT9F6zYHDnaRIP-HLnP9YqA5riuf43NKruMy-rDg=.24b9995e-cba8-4a24-9780-b35f284b67b9@github.com>
 <217jSP2NY4pHDwzQD2hrR8P5oSQvXY4M7rcK_cFOIPw=.2d3cb579-f496-4ddd-a38e-a395a97ebce5@github.com>
 <sIbtGO255aKlW76i6PNffBUCr65AIXAzpbeH2DRMyOA=.73578603-b9e9-43a8-84f8-c1ca4551f3ea@github.com>
Message-ID: <VCeNKPRK0rQXjJOSm59YcmWYJTRqVl9vvMjaLdBwedw=.542b33a2-19a3-4664-8bfb-1b7c35018358@github.com>

On Thu, 17 Oct 2024 15:19:52 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> Will approve at the beginning of next week to let you add some last minute (not substantial) changes during the next few days.
>
>> In any reduction approach, you still need to prove that the reduced problem is equivalent to the original. This is to say that the running variables (in code and proof) must somehow be related to the initial values.
> 
> Yes, although in the proof by "reducing the size of the problem" this should be evident by induction...

> Will approve at the beginning of next week to let you add some last minute (not substantial) changes during the next few days.

I thought that maybe could be useful add a comment highlighting that `(intVal * 2^powsOf2) / 10^z` and `scale - z` are invariant values, to point out the substructure of the problem better...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1805580561

From psandoz at openjdk.org  Thu Oct 17 23:38:28 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 17 Oct 2024 23:38:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <28MMdFkPrGQkT3nD8dUA2GAx6uZyRwERWn3bVvEPSR8=.79c2b5e5-7317-47c5-8878-30c4ac3171ab@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
 <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
 <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>
 <28MMdFkPrGQkT3nD8dUA2GAx6uZyRwERWn3bVvEPSR8=.79c2b5e5-7317-47c5-8878-30c4ac3171ab@github.com>
Message-ID: <sWXg913xsqvSuL3EiMoZqRwF0Hpro4lUdhZ1tP4LyXA=.e8330ff5-57d8-40e5-afdf-a088bf63be7d@github.com>

On Thu, 17 Oct 2024 18:23:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> I have restricted the IR validation to just newly added UMin/UMax transformations.

Even then i think it better to do so in follow on PR, otherwise it is a moving target for review and testing. This new test fails on aarch64 e.g.,


STATUS:Failed.`main' threw exception: compiler.lib.ir_framework.shared.TestFormatException: Violations (16) --------------- - Could not find VM flag "UseAVX" in @IR rule 1 at public void compiler.vectorapi.VectorUnsignedMinMaxIRTransformsTest.umin_ir_transform1_byte()
...


Testing tier 1 to 3 with latest PR looks good otherwise.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2420845538

From liach at openjdk.org  Thu Oct 17 23:56:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Oct 2024 23:56:54 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <Xc6xPI3k3rN3lj3iBadSM3SOPaojT-WFeT5INFZ6t78=.2f4d0cd4-6566-4e24-81e8-8b7028e35824@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

The `jdk.internal.reflect` changes look good; need other reviewers to review hotspot changes.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2376578713

From bpb at openjdk.org  Fri Oct 18 00:00:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Oct 2024 00:00:04 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
 <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>
Message-ID: <PRTuRxv2U5mku-JnMAHkvvQsSBo6zffjIupx8q77Xmc=.be0cea42-2c1f-4538-b6b4-386762e1ef62@github.com>

On Thu, 17 Oct 2024 06:09:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The JDK supports sym links on Windows and adding support for other unusual junctions types has the potential to introduce inconsistencies and weirdness that are outside the scope of the APIs.

There appear to be two types of junctions for reparse points with tag `IO_REPARSE_TAG_MOUNT_POINT`: directory junctions and volume junctions. The reparse tag is set on a directory which is empty. Both of these reparse points contain a target string which represents a path.

For directory junctions, the path is an absolute path beginning with a drive letter such as

C:\Users\username\directory\subdirectory

This path is intended to be to a directory, but there is nothing preventing storing the path to a file or a symbolic link.

For volume junctions, the path uses a GUID, for example, like this

\?\Volume{blah-foo-bar-gus-blah}\


Presently, the JDK _appears_ already to support "true" directory junctions, i.e., where the target path begins with a drive letter and is an absolute path to a directory. The two new tests proposed in this request verify at least a portion of this behavior. All but two sub-tests of these tests already pass with no source changes.

> [...] this is not a change that we should rush into.

Agreed. Note that the only actual implementation changes being proposed here are

1. `Files.isSymbolicLink` would return `true` for directory junctions.
2. `Files.readSymbolicLink` would return the target of the mount point.

It is incomplete in the current form of this request, but I think tighter checks should be performed to ensure that the target does not represent a volume mount point, nor a regular file, nor a symbolic link.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2420886803

From kcr at openjdk.org  Fri Oct 18 00:26:54 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 18 Oct 2024 00:26:54 GMT
Subject: Integrated: 8311530: Deprecate jdk.jsobject module for removal
In-Reply-To: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
References: <IGLgrBcj15QFo70cviDkjokoBOBpDBYXru2PS2N7hKQ=.d365a073-1153-420f-992c-03c7994073e9@github.com>
Message-ID: <vN_Ha7TIVklDQ3GkQA2dvbplEwxRuI-cOwlXnW4EyNg=.8c26690e-6368-4223-818e-24ceb16432f2@github.com>

On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with JavaFX instead.
> 
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX. That PR describes the needed test scenarios.
> 
> This PR does two things:
> 
> 1. Deprecates the `jdk.jsobject` module for removal; the javadoc indicates that the module will be delivered with JavaFX
> 2. Makes `jdk.jsobject` an upgradeable module, which will facilitate the transition by allowing the version of the module shipped with JavaFX to be used in favor of the deprecated module in the JDK itself.

This pull request has now been integrated.

Changeset: 2b03dbda
Author:    Kevin Rushforth <kcr at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b03dbdac4819bc0d40912f273a1ca7ab4e8715e
Stats:     27 lines in 7 files changed: 17 ins; 5 del; 5 mod

8311530: Deprecate jdk.jsobject module for removal

Reviewed-by: rriggs, alanb, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/20555

From jpai at openjdk.org  Fri Oct 18 00:51:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Oct 2024 00:51:58 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v16]
In-Reply-To: <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <HVJ60Vs7kUA9f41UFb3IxSU5vmFsFsuCxBMzzkosSL0=.1743c450-f14e-4cd9-9027-1c0203658243@github.com>
Message-ID: <xfIZlbcYvMcXmJHGX16PouQv99R4Ga8x1a2EeKc8YFE=.02e2d84b-48da-4c75-b9d3-426455efbada@github.com>

On Thu, 17 Oct 2024 04:51:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
>> 
>> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lance's man page inputs

The CSR has been approved. I'll go ahead and integrate this now. Thank you everyone for the inputs and reviews here on the PR and elsewhere.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2752#issuecomment-2420999286

From sspitsyn at openjdk.org  Fri Oct 18 00:53:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 18 Oct 2024 00:53:37 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v6]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <lTyFI-rG1EircImARu90iJW5vTmbs-pBkboLoVSx4Ok=.b388e925-385b-4e8d-b10b-0586725bd5d2@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: clarify the use of annotation @JvmtiMountTransition in yield/yield0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/f8d05152..94862c30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=04-05

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From jpai at openjdk.org  Fri Oct 18 00:54:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Oct 2024 00:54:30 GMT
Subject: Integrated: 8173970: jar tool should have a way to extract to a
 directory
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <rpzTOuR14TYvVlDThd16XRcynjNMIbW57J9jQmPYcXE=.2a3c95c8-b693-4997-b9c7-17cdbd15003a@github.com>

On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> Edit: This PR description has now been updated to match the changes that were done over the course of review inputs that were received for this enhancement.
> 
> The commit in this PR introduces the ability to use `jar` tool to extract the contents of the JAR file to a specific directory of choice. Optional `-C` and `--dir` options are added to the `-x` main operation of the jar tool. The value for these options is expected to be a file path which is expected to be a directory to which the jar will be extracted. When neither `-C` nor `--dir` are used, the extract operation of the jar tool will continue to behave like it did before this enhancement and will extract the jar into the current working directory.
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

This pull request has now been integrated.

Changeset: ffe60919
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffe60919df59196d65832b8ce6b2cd38099d64df
Stats:     617 lines in 5 files changed: 605 ins; 0 del; 12 mod

8173970: jar tool should have a way to extract to a directory

Reviewed-by: lancea, cstein

-------------

PR: https://git.openjdk.org/jdk/pull/2752

From jpai at openjdk.org  Fri Oct 18 00:58:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Oct 2024 00:58:13 GMT
Subject: RFR: 8341134: Deprecate for removal the jrunscript tool [v5]
In-Reply-To: <RVqTDqexv9ICI2fzagkynzzJBJkVpEZ5NlrpUk5070k=.2aebc7a0-e88d-4205-84c9-71ba37c6f913@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
 <RVqTDqexv9ICI2fzagkynzzJBJkVpEZ5NlrpUk5070k=.2aebc7a0-e88d-4205-84c9-71ba37c6f913@github.com>
Message-ID: <NdGfKrzn99lkVfpLoNvwyq4VRnYLzMS5WwPh73g1bkA=.36ae9178-0b96-4a56-bb96-7ad26b4bc407@github.com>

On Wed, 9 Oct 2024 07:00:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
>> 
>> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
>> 
>> 
>> $> jrunscript
>> script engine for language js can not be found
>> 
>> 
>> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
>> 
>> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mandy's review suggestion for man page

Thank you all for the reviews. The CSR has been approved. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21380#issuecomment-2421008132

From jpai at openjdk.org  Fri Oct 18 01:00:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Oct 2024 01:00:19 GMT
Subject: Integrated: 8341134: Deprecate for removal the jrunscript tool
In-Reply-To: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
References: <-VCIzR_wMAzt85QWxjy0PAhmzk-v6A41A5OSVX8WIoI=.58492b2c-4c7c-4725-9f64-6b7adbb6c63d@github.com>
Message-ID: <v4293fL8ILBQen-ysoN2ZCP16uCZXi_SPp82aBnY3do=.7ac782e2-df3e-4f55-aeda-36e4f9034679@github.com>

On Mon, 7 Oct 2024 04:23:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get  a review for this change which proposes to deprecate for removal the `jrunscript` tool?
> 
> The `jrunscript` tool as documented in its specification https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.html was an experimental and unsupported tool. Ever since the script engine implementations have been removed from the JDK, the default usage of this tool has been non-functional:
> 
> 
> $> jrunscript
> script engine for language js can not be found
> 
> 
> The tool itself could be launched by specifying a script engine implementation in the classpath, in which case it will use that script engine implementation. However, given that the JDK itself ships no such engines anymore and since there are no plans to continue support for this tool, the tool will now print a deprecation warning in preparation for its removal from a future release.
> 
> No new tests have been added and existing tests in tier1, tier2 and tier3 continue to pass. I will draft a CSR (and a release note) shortly.

This pull request has now been integrated.

Changeset: 7a16906e
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a16906ed0dce716bc9516cb75b6450725fe9dbb
Stats:     14 lines in 4 files changed: 10 ins; 0 del; 4 mod

8341134: Deprecate for removal the jrunscript tool

Reviewed-by: mchung, alanb, sundar

-------------

PR: https://git.openjdk.org/jdk/pull/21380

From swen at openjdk.org  Fri Oct 18 01:09:09 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Oct 2024 01:09:09 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName [v6]
In-Reply-To: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
Message-ID: <vl4xB3woW0rN9BazX7TIX_e-ce7XJpPz8tygn0wGtFo=.8ed4f870-048b-4422-aa6f-54af36cfb23c@github.com>

> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

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 eight additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
 - suggestion from @liach
 - stable
 - ReferenceClassDescImpl cache internalName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21373/files
  - new: https://git.openjdk.org/jdk/pull/21373/files/a18164f2..77549c52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21373&range=04-05

  Stats: 24424 lines in 722 files changed: 19635 ins; 2228 del; 2561 mod
  Patch: https://git.openjdk.org/jdk/pull/21373.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21373/head:pull/21373

PR: https://git.openjdk.org/jdk/pull/21373

From jbhateja at openjdk.org  Fri Oct 18 02:03:21 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Oct 2024 02:03:21 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
Message-ID: <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>

> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>   
> 
>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>  
> VPMULUDQ 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
> VectorXXH3HashingB...

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - 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=03
  Stats: 351 lines in 12 files changed: 339 ins; 0 del; 12 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 dholmes at openjdk.org  Fri Oct 18 02:23:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Oct 2024 02:23:02 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
 <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>
Message-ID: <H9zBs7z0MHZsdJ2ufOwuGDaA_ccTbE3vaZbRLUWSU1g=.c8dab9ef-5963-4bff-b9b9-b134fb4152c2@github.com>

On Thu, 17 Oct 2024 08:36:53 GMT, John R Rose <jrose at openjdk.org> wrote:

> I read through it fairly thoroughly. I made a lot of suggestions. Rather than edit comments into lots of spots in this PR, I made the following patch file. [aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/17408940/aot-indy-21143-commentary.diff.txt)


+bool InstanceKlass::is_enum_subclass(bool direct_only) const {
+  InstanceKlass* s = java_super();
+  return (s == vmClasses::Enum_klass() ||
+          (s != null && s->java_super() == vmClasses::Enum_klass()));
+}

Just happened to notice you aren't checking `direct_only`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2421125248

From jbhateja at openjdk.org  Fri Oct 18 02:27:06 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Oct 2024 02:27:06 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v2]
In-Reply-To: <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.c088a91d-ef71-48ca-b7dd-e39a224523bf@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <aWTRSrONXcFTZIrv_NporwTPgXg4kbbOoRiCOjSaoUw=.035ec9d6-aeb1-4e06-a3dc-24fddf2bcb81@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.7580c0c3-0bdb-44c5-afd2-2a4226ff7274@github.com>
 <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.f25d813b-b0ba-4c1e-9e77-6e86dfd34de7@github.com>
 <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.c088a91d-ef71-48ca-b7dd-e39a224523bf@github.com>
Message-ID: <v-weAyRxbDmC2JXt5IDP-cS2LurHrhu-1dsoPoRd7R0=.6c72753d-05e1-42be-94ab-27a86e30914e@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 dholmes at openjdk.org  Fri Oct 18 02:37:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Oct 2024 02:37:40 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Nice cleanup! Great to see all this old code go. Just one mistake ...

Thanks

src/hotspot/share/classfile/classFileParser.cpp line 4098:

> 4096:       }
> 4097:     }
> 4098: 

This code should not be removed. The spec for this code should now be:

  // If the loader is not the boot loader then throw an exception if its
  // superclass is in package jdk.internal.reflect 

All we need do is remove the check:

&& !java_lang_ClassLoader::is_reflection_class_loader

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2376812107
PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1805745905

From qamai at openjdk.org  Fri Oct 18 02:44:52 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 18 Oct 2024 02:44:52 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
Message-ID: <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>

On Fri, 18 Oct 2024 02:03:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Review resolutions
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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-2421157206

From davidalayachew at gmail.com  Fri Oct 18 02:53:07 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 17 Oct 2024 22:53:07 -0400
Subject: Would it make sense to add a new constructor to
 java.io.SequenceInputStream?
In-Reply-To: <4d96d695-8ed8-4445-91f5-34a31624175d@oracle.com>
References: <CAA9v-_OGnXwyuTUmV4=YpKWLTv=kzzS_PcKHV4i0YN4B5e3vyQ@mail.gmail.com>
 <4d96d695-8ed8-4445-91f5-34a31624175d@oracle.com>
Message-ID: <CAA9v-_MueAnrhS79vxY4q5-H5tu=pAAfAFwkYpP-dyTjJaY3Xw@mail.gmail.com>

I very much like this. I didn't even know about the SequenceInputStream
until a few days ago, so this would have way more visibility. And then it
could just delegate to SequenceInputStream under the hood. I like it a lot.

It looks like Jaikiran gave me a task to go search up other libraries and
see where and how SequenceInputStream is being used. I will start that next
week and respond onto this thread with my findings. This is my first time
doing this, so any suggestions on strategies would be appreciated.

On Thu, Oct 17, 2024, 9:57?AM Alan Bateman <alan.bateman at oracle.com> wrote:

>
>
> On 17/10/2024 04:47, David Alayachew wrote:
> > Hello Core Libs Dev Team,
> >
> > Currently, java.io.SequenceInputStream only has 2 constructors -- one
> > that takes in 2 instances of InputStream, and another that takes in an
> > Enumeration of type InputStream.
> >
> > Would it make sense to add a third constructor that takes in multiple
> > instances of InputStream? I don't know if a list, an array, varargs,
> > etc makes more sense. But I would think a 3rd constructor would
> > improve this API.
>
> If you are exploring this topic then put InputStream.of(InputStream...
> sources) on the list to try out. InputStream.of() could work the
> equivalent of InputStream.nulInputStream().
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241017/88620117/attachment.htm>

From jrose at openjdk.org  Fri Oct 18 03:58:00 2024
From: jrose at openjdk.org (John R Rose)
Date: Fri, 18 Oct 2024 03:58:00 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <FNQ8C8DWodZYnFtwFGGP1bSb1hHwp7QijYYB1tC8vsY=.ee363dee-15f2-4f54-b744-be15d4a326ea@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

This is a most impressive example of C.D.E. (code deletion engineering).

I remember when this was written, as an accelerator for the JNI methods, long long before we had method handles to do the same thing more flexibly.  I think it was Ken Russell that did the work.  And of course I remember Mandy's newer work (3 years ago) fitting method handles into reflection (a move I applauded of course).

As it happens I was just reviewing the reflection implementation this week, to understand its interaction with upcoming Leyden changes to bootstrap sequences.  Of course I wondered, "when will we ever retire this older implementation?"  Happily, that day has come.

Thanks Mandy!

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2376932358

From iklam at openjdk.org  Fri Oct 18 04:08:37 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:08:37 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v9]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <SpnCtAq_0LNu7_emQ-Z1QQtolBtpeb0jkdpnkVhLjVc=.008bae82-a659-446b-85e2-463b65c14e1b@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @rose00 comments -- tighten up the checks for what can or cannot be aot-inited; removed is_trivial_clinit() as it is used only in logging but the meaning is unclear

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/7bab10b2..030cac23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=07-08

  Stats: 543 lines in 16 files changed: 356 ins; 80 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Fri Oct 18 04:11:47 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:11:47 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
Message-ID: <UclqKuf6jZl1nnmiy3qPqWmoLlFDkN6x84Lr7akjCzo=.74e73243-d75e-4c7c-87be-e1506e4fa79b@github.com>

On Tue, 15 Oct 2024 17:03:40 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/cds/metaspaceShared.cpp line 873:
> 
>> 871:       Symbol* method_sig = vmSymbols::void_method_signature();
>> 872:       JavaCalls::call_static(&result, vmClasses::Class_klass(),
>> 873:                              method_name, method_sig, CHECK);
> 
> Is this a good candidate for a `runtimeResolve` helper method?  Can we roll it into the same mechanism as the other `runtimeResolve` classes use?

`Class::reflectionFactory` is a large table that must be cleared, or else we will bring unwanted (unsupported) objects into the cache.

During runtime, `reflectionFactory` will be initialized on demand, so there's no need to explicitly create it with `runtimeSetup`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1805823385

From iklam at openjdk.org  Fri Oct 18 04:19:29 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:19:29 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v9]
In-Reply-To: <SpnCtAq_0LNu7_emQ-Z1QQtolBtpeb0jkdpnkVhLjVc=.008bae82-a659-446b-85e2-463b65c14e1b@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SpnCtAq_0LNu7_emQ-Z1QQtolBtpeb0jkdpnkVhLjVc=.008bae82-a659-446b-85e2-463b65c14e1b@github.com>
Message-ID: <lO25avhbfpA3fo8Giwg_6AauA-4cJwXQzIWgR5hrSi4=.3e5b67e1-e0f6-4aa8-b2bb-19b6884029bc@github.com>

On Fri, 18 Oct 2024 04:08:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @rose00 comments -- tighten up the checks for what can or cannot be aot-inited; removed is_trivial_clinit() as it is used only in logging but the meaning is unclear

> I read through it fairly thoroughly. I made a lot of suggestions. Rather than edit comments into lots of spots in this PR, I made the following patch file. [aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/17408940/aot-indy-21143-commentary.diff.txt)
> 
> The first lines of the patch file state which revision the patch applies to, which is [4be6a25](https://github.com/openjdk/jdk/commit/4be6a255cdd300bb6e15ded1dc163b00cd24dbd8) from Tuesday.

Hi John,

Thank you so much for the code. I have merged most of your diffs into the PR. There are a few items left which I will go over tomorrow. I simplified the `InstanceKlass::interface_needs_clinit_execution_as_super()` as I don't need to check against non-interface classes, so I worry about adding code that's not used by this JEP.

I also moved the `InstanceKlass::assert_no_clinit_will_run_for_aot_initialized_class()` function to be closed to `InstanceKlass::initialize_with_aot_initialized_mirror()` -- the latter has been simplified as we would never need to take the "quicker path" from the previous version of the code.

I also cleaned up the "firewall" check in `mark_for_aot_initialization()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2421300475

From jbhateja at openjdk.org  Fri Oct 18 04:20:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Oct 2024 04:20:22 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
Message-ID: <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@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 iklam at openjdk.org  Fri Oct 18 04:22:09 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:22:09 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
Message-ID: <-gsu1c1EwtLH2w22G9YTdmEPXoGLIYTCdGIH8MrcL2M=.b62cd88d-edf7-4b9a-926d-79570d1cd2c4@github.com>

On Tue, 15 Oct 2024 15:19:36 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/cds/heapShared.cpp line 1140:
> 
>> 1138:       return false;
>> 1139:     }
>> 1140:   }
> 
> This is conservatively correct in that it checks all implemented interfaces.  We could be less conservative and only check interfaces that have a "non-abstract non-static" (aka default) method as those are the interfaces that will be initialized along with the class as per JVMS 5.5

I've removed this function altogether. It was used in logging only, and it wasn't clear what the output meant (w.r.t to interfaces that have non-trivial <clinit>). I think it's best to remove this function, and implement it properly in a future RFE that automatically aot-init all classes that can be initialized with no observable side effects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1805829136

From iklam at openjdk.org  Fri Oct 18 04:28:06 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 04:28:06 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
Message-ID: <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>

On Wed, 16 Oct 2024 01:26:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 235:
>> 
>>> 233: }
>>> 234: 
>>> 235: // TODO -- is this really correct? Do we need a special ClassLoaderData for each hidden class?
>> 
>> There are multiple kinds of hidden classes: 
>> * default ones which can be unloaded immediately when no longer referenced
>> * MHs.Lookup.ClassOption::STRONG which are associated with their defining loader and can only be unloaded when that loader is unloaded.
>> 
>> I think we need special ClassLoaderData for the non-strong (default) hidden classes
>
> We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've added a comment and tightened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)

(I've replied to this comment. I can see it in the mailing list but it seems to be lost on this page, so I'll add it again)

We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've updated the comment and tghtened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1805831730

From vlivanov at openjdk.org  Fri Oct 18 05:03:22 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 18 Oct 2024 05:03:22 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
Message-ID: <34KZVRjCMAl5-KAG6hLnJUe2RZF2fThQAWuresTL5Pk=.83d5f516-4a5a-4f0e-9eeb-67b78cfc074b@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 qamai at openjdk.org  Fri Oct 18 05:09:34 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 18 Oct 2024 05:09:34 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
Message-ID: <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.5e4e5b2b-c03a-41bb-8a9e-293631895841@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 vlivanov at openjdk.org  Fri Oct 18 05:19:39 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 18 Oct 2024 05:19:39 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.5e4e5b2b-c03a-41bb-8a9e-293631895841@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.5e4e5b2b-c03a-41bb-8a9e-293631895841@github.com>
Message-ID: <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.f4ad234c-ecab-4523-af46-f2c3cf1262ad@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 qamai at openjdk.org  Fri Oct 18 05:41:20 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 18 Oct 2024 05:41:20 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.f4ad234c-ecab-4523-af46-f2c3cf1262ad@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.5e4e5b2b-c03a-41bb-8a9e-293631895841@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.f4ad234c-ecab-4523-af46-f2c3cf1262ad@github.com>
Message-ID: <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.e21aa2f2-784a-400f-bea7-3db41605faf7@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 vlivanov at openjdk.org  Fri Oct 18 05:41:41 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 18 Oct 2024 05:41:41 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
Message-ID: <DAhGbWHDcL0l0ENFga7Fd8qr6JqPnSdDzboCmCynE6Q=.03143ee4-88bc-40f8-9918-f825ecee5e17@github.com>

On Fri, 18 Oct 2024 02:03:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Review resolutions
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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 Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1805886268

From qamai at openjdk.org  Fri Oct 18 05:41:41 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 18 Oct 2024 05:41:41 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <DAhGbWHDcL0l0ENFga7Fd8qr6JqPnSdDzboCmCynE6Q=.03143ee4-88bc-40f8-9918-f825ecee5e17@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <DAhGbWHDcL0l0ENFga7Fd8qr6JqPnSdDzboCmCynE6Q=.03143ee4-88bc-40f8-9918-f825ecee5e17@github.com>
Message-ID: <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.534ecebb-9e6b-4bf5-8991-d02e62809d33@github.com>

On Fri, 18 Oct 2024 05:35:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Review resolutions
>>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction
>
> 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  Fri Oct 18 05:41:41 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 18 Oct 2024 05:41:41 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.534ecebb-9e6b-4bf5-8991-d02e62809d33@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <DAhGbWHDcL0l0ENFga7Fd8qr6JqPnSdDzboCmCynE6Q=.03143ee4-88bc-40f8-9918-f825ecee5e17@github.com>
 <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.534ecebb-9e6b-4bf5-8991-d02e62809d33@github.com>
Message-ID: <pTaJgdWlRELOLYKakooudS-5TkW3xmDJrOI5wx3FUT4=.3378d911-2522-43fb-9700-ef4c544657e4@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 liach at openjdk.org  Fri Oct 18 05:42:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Oct 2024 05:42:50 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <UclqKuf6jZl1nnmiy3qPqWmoLlFDkN6x84Lr7akjCzo=.74e73243-d75e-4c7c-87be-e1506e4fa79b@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
 <UclqKuf6jZl1nnmiy3qPqWmoLlFDkN6x84Lr7akjCzo=.74e73243-d75e-4c7c-87be-e1506e4fa79b@github.com>
Message-ID: <bawYxEbNMLLsVKFAcdwD3Bu_Zoc1_5w0kpIU8OJB9D4=.21544e14-d107-49bf-9d00-afa56b6bf63d@github.com>

On Fri, 18 Oct 2024 04:09:00 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/metaspaceShared.cpp line 873:
>> 
>>> 871:       Symbol* method_sig = vmSymbols::void_method_signature();
>>> 872:       JavaCalls::call_static(&result, vmClasses::Class_klass(),
>>> 873:                              method_name, method_sig, CHECK);
>> 
>> Is this a good candidate for a `runtimeResolve` helper method?  Can we roll it into the same mechanism as the other `runtimeResolve` classes use?
>
> `Class::reflectionFactory` is a large table that must be cleared, or else we will bring unwanted (unsupported) objects into the cache.
> 
> During runtime, `reflectionFactory` will be initialized on demand, so there's no need to explicitly create it with `runtimeSetup`.

That said, can reflectionFactory field be stable in the future with this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1805889297

From jbhateja at openjdk.org  Fri Oct 18 05:44:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Oct 2024 05:44:22 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.f4ad234c-ecab-4523-af46-f2c3cf1262ad@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.5e4e5b2b-c03a-41bb-8a9e-293631895841@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.f4ad234c-ecab-4523-af46-f2c3cf1262ad@github.com>
Message-ID: <TLmt4TKSzAFKntKnCqogV3l6Ulw3edvTy4MdpIY45J4=.db500adb-7fd8-4885-8cb4-89707b5cf098@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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421448784

From vlivanov at openjdk.org  Fri Oct 18 05:49:54 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 18 Oct 2024 05:49:54 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <pTaJgdWlRELOLYKakooudS-5TkW3xmDJrOI5wx3FUT4=.3378d911-2522-43fb-9700-ef4c544657e4@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <DAhGbWHDcL0l0ENFga7Fd8qr6JqPnSdDzboCmCynE6Q=.03143ee4-88bc-40f8-9918-f825ecee5e17@github.com>
 <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.534ecebb-9e6b-4bf5-8991-d02e62809d33@github.com>
 <pTaJgdWlRELOLYKakooudS-5TkW3xmDJrOI5wx3FUT4=.3378d911-2522-43fb-9700-ef4c544657e4@github.com>
Message-ID: <YBfK7uCVlgzfZ-K8l-aMbl8Ddu5lMroutXdEEHcyik8=.d3886993-5beb-4b91-abf2-0ef199490774@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 vlivanov at openjdk.org  Fri Oct 18 05:55:07 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 18 Oct 2024 05:55:07 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <YBfK7uCVlgzfZ-K8l-aMbl8Ddu5lMroutXdEEHcyik8=.d3886993-5beb-4b91-abf2-0ef199490774@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <DAhGbWHDcL0l0ENFga7Fd8qr6JqPnSdDzboCmCynE6Q=.03143ee4-88bc-40f8-9918-f825ecee5e17@github.com>
 <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.534ecebb-9e6b-4bf5-8991-d02e62809d33@github.com>
 <pTaJgdWlRELOLYKakooudS-5TkW3xmDJrOI5wx3FUT4=.3378d911-2522-43fb-9700-ef4c544657e4@github.com>
 <YBfK7uCVlgzfZ-K8l-aMbl8Ddu5lMroutXdEEHcyik8=.d3886993-5beb-4b91-abf2-0ef199490774@github.com>
Message-ID: <xobYQ9YwUCE7wwErWEmsnZufYV83RGomYlsaVpyQwbA=.7cd4e2f4-adb4-434c-a6d3-f48d74530c13@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 vlivanov at openjdk.org  Fri Oct 18 06:08:48 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 18 Oct 2024 06:08:48 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.e21aa2f2-784a-400f-bea7-3db41605faf7@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.5e4e5b2b-c03a-41bb-8a9e-293631895841@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.f4ad234c-ecab-4523-af46-f2c3cf1262ad@github.com>
 <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.e21aa2f2-784a-400f-bea7-3db41605faf7@github.com>
Message-ID: <Ofu_nlH8iKfZiL5JtUW9exKSrpN0WGch40B7BCOCVU8=.90a60b9c-489b-4b1f-bd4e-32067adcca05@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 jbhateja at openjdk.org  Fri Oct 18 06:22:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Oct 2024 06:22:38 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.e21aa2f2-784a-400f-bea7-3db41605faf7@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.5e4e5b2b-c03a-41bb-8a9e-293631895841@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.f4ad234c-ecab-4523-af46-f2c3cf1262ad@github.com>
 <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.e21aa2f2-784a-400f-bea7-3db41605faf7@github.com>
Message-ID: <RdgfPrfy2VjFALAMljLKoKDCluGZSHUAZC8Y1pNjEWM=.464850a5-db11-4c16-98f1-1e7e2a93e4c2@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).

Hi @iwanowww , @merykitty , Thanks for your inputs!!

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-2421511006

From qamai at openjdk.org  Fri Oct 18 06:22:38 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 18 Oct 2024 06:22:38 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <RdgfPrfy2VjFALAMljLKoKDCluGZSHUAZC8Y1pNjEWM=.464850a5-db11-4c16-98f1-1e7e2a93e4c2@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
 <RPJ6BpFHRx00za8_3r2gk3lQBKe0Ev7Dq2tJE8NoYc8=.3c5716ab-6732-44f3-ada0-c0622fde8bd7@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.da4ceed7-236b-4f91-b453-81f03b5a01d1@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.5e4e5b2b-c03a-41bb-8a9e-293631895841@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.f4ad234c-ecab-4523-af46-f2c3cf1262ad@github.com>
 <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.e21aa2f2-784a-400f-bea7-3db41605faf7@github.com>
 <RdgfPrfy2VjFALAMljLKoKDCluGZSHUAZC8Y1pNjEWM=.464850a5-db11-4c16-98f1-1e7e2a93e4c2@github.com>
Message-ID: <8p95gYaAnNAIfqVBosZgvMMCVhHn2M0fQx7FLLgCn9U=.94cd8db9-894c-4590-ae08-45afecfae2ad@github.com>

On Fri, 18 Oct 2024 06:10:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @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).
> 
> Hi @iwanowww , @merykitty , Thanks for your inputs!!
> 
> 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 vlivanov at openjdk.org  Fri Oct 18 06:30:38 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 18 Oct 2024 06:30:38 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
Message-ID: <c2W71hipndd93Bj44iQvthpvWa7S-_t2U7zXqrYm_vI=.14222032-f83d-44cc-a0f6-2e340ae1b7d2@github.com>

On Fri, 18 Oct 2024 02:03:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Review resolutions
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421529658

From aboldtch at openjdk.org  Fri Oct 18 06:46:22 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 18 Oct 2024 06:46:22 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v4]
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <0wC3rZqgWGF5Pyjs9yfUPEXpkU_Q-uYE1gUth7jGfew=.ee3e19a3-3951-4cde-ac19-b8a0b089508b@github.com>

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge tag 'jdk-24+20' into JDK-8341692
   
   Added tag jdk-24+20 for changeset 7a64fbbb
 - Merge tag 'jdk-24+19' into JDK-8341692
   
   Added tag jdk-24+19 for changeset e7c5bf45
 - LargeWindowPaintTest.java fix id typo
 - Fix problem-listed @requires typo
 - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
 - Reorder z_globals options: product > diagnostic product > develop
 - Consistent albite special code style
 - Consistent order between ZArguments and GCArguments
 - Remove XCollectedHeap from HSDB
 - Fix typo in TestZUncommitEvent.java
 - ... and 3 more: https://git.openjdk.org/jdk/compare/7a64fbbb...76c5d0c6

-------------

Changes: https://git.openjdk.org/jdk/pull/21401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=03
  Stats: 39433 lines in 406 files changed: 155 ins; 39008 del; 270 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

PR: https://git.openjdk.org/jdk/pull/21401

From stefank at openjdk.org  Fri Oct 18 07:24:40 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 18 Oct 2024 07:24:40 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v4]
In-Reply-To: <0wC3rZqgWGF5Pyjs9yfUPEXpkU_Q-uYE1gUth7jGfew=.ee3e19a3-3951-4cde-ac19-b8a0b089508b@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <0wC3rZqgWGF5Pyjs9yfUPEXpkU_Q-uYE1gUth7jGfew=.ee3e19a3-3951-4cde-ac19-b8a0b089508b@github.com>
Message-ID: <-V8KgQ0UJkawIutURV9UhV1kmb8Yh4oDumTryF069cA=.0be23393-ced1-4c14-9113-bf1a819b1d9a@github.com>

On Fri, 18 Oct 2024 06:46:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge tag 'jdk-24+20' into JDK-8341692
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - Remove XCollectedHeap from HSDB
>  - Fix typo in TestZUncommitEvent.java
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/7a64fbbb...76c5d0c6

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2377217619

From alanb at openjdk.org  Fri Oct 18 07:57:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 07:57:05 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v6]
In-Reply-To: <lTyFI-rG1EircImARu90iJW5vTmbs-pBkboLoVSx4Ok=.b388e925-385b-4e8d-b10b-0586725bd5d2@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <lTyFI-rG1EircImARu90iJW5vTmbs-pBkboLoVSx4Ok=.b388e925-385b-4e8d-b10b-0586725bd5d2@github.com>
Message-ID: <yytrrZQvNLLvLMUC4lZPTjhn8ExroM56uRT9_TFctOI=.a9247b9a-9d05-47d3-9691-eb37753cb5b2@github.com>

On Fri, 18 Oct 2024 00:53:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: clarify the use of annotation @JvmtiMountTransition in yield/yield0

src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java line 35:

> 33:  * The Continuation yield and yield0 frames normally are in VTMS transition
> 34:  * but can be found out of transition in an unmounted virtual thread.
> 35:  * This inconsistency is the reason why they also need this annotation.

In ChangesCurrentThread, Hidden and the other annotations, the description explains where they must be used. The JvmtiMountTransition description isn't very clear as it's explain why the Continuation yield methods need the annotation. It's okay if the description is re-worked in some future PR, my comment is just that the current description is very confusing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1806047399

From liach at openjdk.org  Fri Oct 18 07:59:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Oct 2024 07:59:40 GMT
Subject: RFR: 8341664: ReferenceClassDescImpl cache internalName [v6]
In-Reply-To: <vl4xB3woW0rN9BazX7TIX_e-ce7XJpPz8tygn0wGtFo=.8ed4f870-048b-4422-aa6f-54af36cfb23c@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
 <vl4xB3woW0rN9BazX7TIX_e-ce7XJpPz8tygn0wGtFo=.8ed4f870-048b-4422-aa6f-54af36cfb23c@github.com>
Message-ID: <ar06W2WkFCpoxuIZplfbnQzWAfCJ9kp5oXraOSguEGE=.0d1648da-f572-488b-bca9-2f145cf93fba@github.com>

On Fri, 18 Oct 2024 01:09:09 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.
>
> 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 eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
>  - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
>  - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
>  - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
>  - Merge remote-tracking branch 'upstream/master' into optim_internal_name_202410
>  - suggestion from @liach
>  - stable
>  - ReferenceClassDescImpl cache internalName

Good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21373#pullrequestreview-2377307000

From epeter at openjdk.org  Fri Oct 18 08:09:32 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 18 Oct 2024 08:09:32 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v19]
In-Reply-To: <KC5Z--UoI5bQj9T3KWD-Nj3CvHqIlyHKpYpkVp_6wCE=.305930b1-4591-4fbc-a14d-7e93b53993f1@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <KC5Z--UoI5bQj9T3KWD-Nj3CvHqIlyHKpYpkVp_6wCE=.305930b1-4591-4fbc-a14d-7e93b53993f1@github.com>
Message-ID: <fmCTPyboBVnPDgCpxboLXLLRj2hgC9y-QI4HEHND9m4=.0477b1d3-d3a1-4738-bf0e-8e297a01e8d3@github.com>

On Mon, 23 Sep 2024 23:23:12 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 incrementally with one additional commit since the last revision:
> 
>   fix build error

Ok, now I have a patch out for review: https://github.com/openjdk/jdk/pull/19970

Can you see if this speeds up the `PutBytesTest` benchmark for you?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2421773875

From alanb at openjdk.org  Fri Oct 18 08:09:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 08:09:57 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
 <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>
Message-ID: <s8rlCXNr1Y5mrQu2J-Ec6zn0SeilcN-aSv_9CMeqMh8=.997ecee3-e683-421b-ae16-73bc994264ae@github.com>

On Thu, 17 Oct 2024 22:56:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/file/Files/InputStreamTest.java line 139:
>> 
>>> 137:             InputStream s = Files.newInputStream(stdin);
>>> 138:             s.available();
>>> 139:         }
>> 
>> I assume you meant to close the input stream.
>> 
>> What about the other methods defined by InputStream that have special handling in ChannelInputStream? I assume we should add test coverage for these methods.
>
> I added test coverage for `skip` but not for `readAllBytes` nor `readNBytes`:
> - `readAllBytes` throws before but hangs after the change;
> - `readNBytes` hangs both before and after the change.

I wonder if there is another special file that could be read to EOF to allow the methods be tested. Asking because the overrides have a code path we need to test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1806067813

From swen at openjdk.org  Fri Oct 18 08:09:57 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Oct 2024 08:09:57 GMT
Subject: Integrated: 8341664: ReferenceClassDescImpl cache internalName
In-Reply-To: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
References: <g0yDxExQtCjtxAlVlB2uLmVn-mQpeHfj3YApJNVe9OM=.44c8825e-8e41-47fc-b687-ec196f3043d1@github.com>
Message-ID: <6CxzzYogq3IwWsNFpUOwNutwjEeYAIrOm3MvSMGh_FM=.17879d48-07a9-4867-a0f3-372fa5f4f162@github.com>

On Sun, 6 Oct 2024 01:22:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> ReferenceClassDescImpl caches internalName to avoid creating a new String object for each call, which can also simplify the implementation of classfile.

This pull request has now been integrated.

Changeset: 0963b9e8
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0963b9e8918670badc956a325fe2ca0bf55f6d29
Stats:     97 lines in 5 files changed: 14 ins; 74 del; 9 mod

8341664: ReferenceClassDescImpl cache internalName

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21373

From abimpoudis at openjdk.org  Fri Oct 18 08:30:44 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 18 Oct 2024 08:30:44 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <7-Avj4deqgRbrdSLUYjssAoC2XeAAjyN7sd_-K0hiOg=.195e4158-bc74-4bfa-81e4-ef675ffbc42c@github.com>

On Mon, 14 Oct 2024 12:46:29 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 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

LGTM

-------------

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2377389927

From duke at openjdk.org  Fri Oct 18 08:36:30 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 18 Oct 2024 08:36:30 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v48]
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <8_eviT-0AZjEDucZSR2WfvWHCZRULKOVHlcN0ec5ekA=.c40fc44b-c0fb-4037-ba96-b181d4178a60@github.com>

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Refine comments to point out the substructure of the method's contract better

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21323/files
  - new: https://git.openjdk.org/jdk/pull/21323/files/929d0abe..ae40145e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21323&range=46-47

  Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21323/head:pull/21323

PR: https://git.openjdk.org/jdk/pull/21323

From eirbjo at openjdk.org  Fri Oct 18 09:20:15 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 09:20:15 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v2]
In-Reply-To: <ZZAq8q5mhcTAdSJhTreqT6hUfqyjmYxEP0TTvYbH7qk=.ce1ad101-8fd9-4ba9-836c-7afbac86caa0@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <ZZAq8q5mhcTAdSJhTreqT6hUfqyjmYxEP0TTvYbH7qk=.ce1ad101-8fd9-4ba9-836c-7afbac86caa0@github.com>
Message-ID: <t6U5MuEzwr8QPfDQW0Ks9HYw1eMEOdNpoHdftGkwJ74=.c8cdc290-29d4-4909-83bc-10af13bc3dde@github.com>

On Mon, 14 Oct 2024 19:50:45 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which speeds up `JarFile::getEntry` lookup significantly for multi-release JAR files.
>> 
>> The changes in this PR are motivated by the following insights:
>> 
>> * `META-INF/versions/` is sparsely populated.
>> * Most entries are not versioned
>> * The number of unique versions for each versioned entry is small
>> * Many JAR files are 'accidentally' multi-release; they use the feature to hide `module-info.class` from Java 8.
>> 
>> Instead of  performing one lookup for every version identified in the JAR, this PR narrows the version search down to only the number of versions found for the entry being looked up, which will most often be zero. This speeds up lookup for non-versioned entries, and provides a more targeted search for versioned entries.
>> 
>> An alternative approach could be to normalize the hash code to use the none-versioned name such that versioned and non-versioned names would be resolved in the same lookup. This was quickly abandoned since the code changes were intrusive and mixed too many JAR specific concerns into `ZipFile`.
>> 
>> Testing: The existing `JarFileGetEntry` benchmark is updated to optionally test a multi-release JAR file with one versioned entry for `module-info.class` plus two other versioned class files for two distinct versions. Performance results in [first comment](#issuecomment-2410901754).
>> 
>> Running `ZipFileOpen` on a multi-release JAR did not show a significat difference between this PR and mainline. 
>> 
>> The JAR and ZIP tests are run locally. GHA results green. The `noreg-perf` label is added in JBS.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Arrays.sort instead of TreeSet

Marking this PR as draft while investigating alternatives as proposed by @cl4es

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21489#issuecomment-2421937705

From alanb at openjdk.org  Fri Oct 18 10:09:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 10:09:16 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <_zMUWasnrrO1r3Tuxvqb3YG_2lcidmqlXlF0GT5QiRI=.091fec45-32fc-4438-9159-6928922e3e63@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Good cleanup. 

I searched the tests as I expected to find some tests exercising -Djdk.reflect.useOldSerializableConstructor but nothing found.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2377641911

From vklang at openjdk.org  Fri Oct 18 10:17:52 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 18 Oct 2024 10:17:52 GMT
Subject: RFR: 8342513: Autoboxing Overhead & Inefficient Parallel
 Processing
In-Reply-To: <xGo0Q5DtGoqqIhgGRjva7HMDfluHfC8xGcFKbllX5wk=.44a37754-a7f9-465b-8a0d-8522c01bd9ca@github.com>
References: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
 <xGo0Q5DtGoqqIhgGRjva7HMDfluHfC8xGcFKbllX5wk=.44a37754-a7f9-465b-8a0d-8522c01bd9ca@github.com>
Message-ID: <vJnH8bWKyxsFCX5EzPS2XX8ornL-_LP1L_tFodWLZ2I=.eaec628e-890c-46df-ba27-79c004f73857@github.com>

On Thu, 17 Oct 2024 22:41:02 GMT, wasif kirmani <duke at openjdk.org> wrote:

>> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing
>
>> [xxDark](/xxDark)
> 
> Quite an allegation. Well, I initially wrote it for IntStraem and as I mentioned the performance change I found and it was working fine. But, yes I couldn't check it thoroughly which was my bad.

@kirmaniwasif 

>The issue raised was not about the primitive streams performing unnecessary boxing, but rather about efficiently handling larger streams with more complex operations (e.g., filtering large datasets).

Wouldn't, as a user, adding `parallel()` to the stream do the exact same thing (but the user would still remain in control of whether the stream is parallel or sequential)?

>I verified the filter by implementing time changes with IntStream and found out that:
>long startTime = System.nanoTime();
>long count = optimizedIntStream(IntStream.range(0, 1_000_000))
>.filter(n -> n % 2 == 0)
>.count();
>long endTime = System.nanoTime();

The above kind of performance benchmarking is highly likely to give you the wrong impression (there are a lot of concerns you'll have to handle in order to arrive at a benchmark setup which will produce reliable results)?you'll have to create (or reuse an existing) JMH-based benchmark. Also, only testing a single stream length (which also happens to have a known length) is not going to paint a complete picture, so you're going to have to test different stream lengths ranging from 0 to millions both with streams of known lengths and unknown lengths. Also, only testing a single intermediate operation might obscure the fact that a change can have adverse effects when combined with other operations, so you're going to have to bench a bunch of combinations of operations to make sure that the change doesn't have unintended performance consequences.

What I'd recommend you doing is first verify the claims: is auto-boxing happening, and if so where. Then the next step is to check if it is possible to fix that auto-boxing locally (since the primitive streams try very hard to avoid boxing).

>From experience, it is vital run the tests after each change (even before running the benchmarks).

Please see https://openjdk.org/contribute/ for further information on contributing to OpenJDK.

Cheers,
?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21566#issuecomment-2422078650

From duke at openjdk.org  Fri Oct 18 10:17:52 2024
From: duke at openjdk.org (wasif kirmani)
Date: Fri, 18 Oct 2024 10:17:52 GMT
Subject: RFR: 8342513: Autoboxing Overhead & Inefficient Parallel
 Processing
In-Reply-To: <xGo0Q5DtGoqqIhgGRjva7HMDfluHfC8xGcFKbllX5wk=.44a37754-a7f9-465b-8a0d-8522c01bd9ca@github.com>
References: <iQiMiwSu9_K_0W4m8Efxp0YhA4bMKef8QNAprn9zy54=.2a9dad73-6286-4f8a-b77b-bb42f96f409f@github.com>
 <xGo0Q5DtGoqqIhgGRjva7HMDfluHfC8xGcFKbllX5wk=.44a37754-a7f9-465b-8a0d-8522c01bd9ca@github.com>
Message-ID: <otQ8bL-ZFAw14xHjkRl6sDhKmb_aQWcnytPRW2JDuxQ=.726ae8dc-5ffe-4901-84a0-3dac6acffa60@github.com>

On Thu, 17 Oct 2024 22:41:02 GMT, wasif kirmani <duke at openjdk.org> wrote:

>> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing Overhead & Inefficient Parallel Processing
>
>> [xxDark](/xxDark)
> 
> Quite an allegation. Well, I initially wrote it for IntStraem and as I mentioned the performance change I found and it was working fine. But, yes I couldn't check it thoroughly which was my bad.

> @kirmaniwasif
> 
> > The issue raised was not about the primitive streams performing unnecessary boxing, but rather about efficiently handling larger streams with more complex operations (e.g., filtering large datasets).
> 
> Wouldn't, as a user, adding `parallel()` to the stream do the exact same thing (but the user would still remain in control of whether the stream is parallel or sequential)?
> 
> > I verified the filter by implementing time changes with IntStream and found out that:
> > long startTime = System.nanoTime();
> > long count = optimizedIntStream(IntStream.range(0, 1_000_000))
> > .filter(n -> n % 2 == 0)
> > .count();
> > long endTime = System.nanoTime();
> 
> The above kind of performance benchmarking is highly likely to give you the wrong impression (there are a lot of concerns you'll have to handle in order to arrive at a benchmark setup which will produce reliable results)?you'll have to create (or reuse an existing) JMH-based benchmark. Also, only testing a single stream length (which also happens to have a known length) is not going to paint a complete picture, so you're going to have to test different stream lengths ranging from 0 to millions both with streams of known lengths and unknown lengths. Also, only testing a single intermediate operation might obscure the fact that a change can have adverse effects when combined with other operations, so you're going to have to bench a bunch of combinations of operations to make sure that the change doesn't have unintended performance consequences.
> 
> What I'd recommend you doing is first verify the claims: is auto-boxing happening, and if so where. Then the next step is to check if it is possible to fix that auto-boxing locally (since the primitive streams try very hard to avoid boxing).
> 
> From experience, it is vital run the tests after each change (even before running the benchmarks).
> 
> Please see https://openjdk.org/contribute/ for further information on contributing to OpenJDK.
> 
> Cheers, ?

Thank you for the response. I have closed this PR. But, will keep an eye in future

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21566#issuecomment-2422085704

From alanb at openjdk.org  Fri Oct 18 10:47:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 10:47:08 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v3]
In-Reply-To: <TZWrkJHDEt5WqBMzCvVt5ivmcW5cYIRt3rrnh_-_LSs=.6ce4cb1f-2ffb-4704-94c9-50d3bf644c3d@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <TZWrkJHDEt5WqBMzCvVt5ivmcW5cYIRt3rrnh_-_LSs=.6ce4cb1f-2ffb-4704-94c9-50d3bf644c3d@github.com>
Message-ID: <5mXY3emfvAVuyQz3ehVNBhKDdj72MWqy8XZbddlt458=.c65db645-4e5a-4b83-9036-1bdeea8e89e0@github.com>

On Thu, 17 Oct 2024 22:55:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8233451: Do not initialize isOther to null
>  - 8233451: Address reviewer comments; convert test to JUnit 5

The latest update looks okay, maybe we might find a better special file so the readAllXXX methods can be tested.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21508#pullrequestreview-2377752580

From alanb at openjdk.org  Fri Oct 18 11:28:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 11:28:35 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option [v2]
In-Reply-To: <MEXuMA7PWvze61-JglQK2hAASioMTgHz59zXFUJQNT0=.a07d3fdb-ced1-44a7-9a21-d29fd7c88c7c@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
 <MEXuMA7PWvze61-JglQK2hAASioMTgHz59zXFUJQNT0=.a07d3fdb-ced1-44a7-9a21-d29fd7c88c7c@github.com>
Message-ID: <4nH8pVUf8BoCEwWAC3RunrTlXCSd5GHDPJg6IIw43R8=.a2826545-e806-4040-869e-25addf4e5967@github.com>

On Thu, 17 Oct 2024 01:28:41 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Summary of changes:
>> 
>> Before dumping info the archive, all the module names from `--add-modules` will be sorted and then concatenated into one string with comma as the separator between module names.
>> 
>> During runtime, same function will be used to obtain the string in the same format with sorted module names. The string will be compared with the one from the archive to determine if the same module names were specified during dump time.
>> 
>> ModuleBootstrap.java
>>         The `addModulesFromRuntimeImage` method is added to check if the modules in `addModules` are from the runtime image. If any of the modules isn't in the runtime image, archiving will be disabled.
>> 
>> ArchivedModuleGraph.java
>>        The constructor has an addition argument `Set addModules`
>>        The `get` method also has an addition argument `Set addModules`. It returns the `archivedModuleGraph` only if both the `mainModule` and the `addModules` are the same as the input arguments.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @rose00 comment

src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 467:

> 465:         if (CDS.isDumpingStaticArchive()
> 466:                 && !haveUpgradeModulePath
> 467:                 && (addModules.isEmpty() || addModulesFromRuntimeImage(addModules))

I think it would be better to check the modules in the Configuration as that is what will be archived. Can you try this, calling addJrt(cf, addModules) where this method is below (it's similar to allJrtOrModularJar that we added recently, not tested btw).


    /**
     * Returns true if all modules named in the given set are in the Configuration and
     * the run-time image.
     */
    private static boolean allJrt(Configuration cf, Set<String> moduleNames) {
        return !moduleNames.stream()
                .map(mn -> cf.findModule(mn).orElseThrow())
                .map(m -> m.reference().location().orElseThrow())
                .anyMatch(uri -> !uri.getScheme().equalsIgnoreCase("jrt"));
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21553#discussion_r1806342360

From alanb at openjdk.org  Fri Oct 18 11:54:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 11:54:59 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <PRTuRxv2U5mku-JnMAHkvvQsSBo6zffjIupx8q77Xmc=.be0cea42-2c1f-4538-b6b4-386762e1ef62@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
 <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>
 <PRTuRxv2U5mku-JnMAHkvvQsSBo6zffjIupx8q77Xmc=.be0cea42-2c1f-4538-b6b4-386762e1ef62@github.com>
Message-ID: <X16uDSTJspQ3PJG1MtMzDCZm5eq_Htp0ogTFNar1F3E=.73295114-fa93-444c-a395-448e5a8af4a0@github.com>

On Thu, 17 Oct 2024 23:56:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Agreed. Note that the only actual implementation changes being proposed here are
> 
> 1. `Files.isSymbolicLink` would return `true` for directory junctions.
> 2. `Files.readSymbolicLink` would return the target of the mount point.
> 
> It is incomplete in the current form of this request, but I think tighter checks should be performed to ensure that the target does not represent a volume mount point, nor a regular file, nor a symbolic link.

Junctions, volume mount points, and several other reparse points are just too messy and NFTS specific to support in the standard API. Directory junctions may be semantically close but aren't quite the same thing so I fear that this will require effort to audit every I/O operation to flush out oddities. I also fear this will leading to weasel words in the specs. So not sure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2422291737

From dl at openjdk.org  Fri Oct 18 12:35:17 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 18 Oct 2024 12:35:17 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
In-Reply-To: <1weO1tM4iaGbFnxuDPEoICXG0Ri-5f1QQgtiZJ1CccI=.49d4f46d-ef9f-4b5a-9f47-61da21473a24@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <1weO1tM4iaGbFnxuDPEoICXG0Ri-5f1QQgtiZJ1CccI=.49d4f46d-ef9f-4b5a-9f47-61da21473a24@github.com>
Message-ID: <nkkbbyhK4cmjKqcTdMa1OZAwAGiQDZyjcFuZ6VloDQ4=.ab61c966-8dd2-4f34-a43c-6fdd8631735e@github.com>

On Wed, 16 Oct 2024 16:32:32 GMT, Viktor Klang <vklang 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),
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 854:
> 
>> 852:      * usages of ForkJoinTasks ignore interrupt status when executing
>> 853:      * or awaiting completion.  Otherwise, reporting task results or
>> 854:      * exceptions is preferred to throwing InterruptedExeptions,
> 
> Suggestion:
> 
>      * exceptions is preferred to throwing InterruptedExceptions,

Thanks.  I keep losing that typo fix!

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1287:
> 
>> 1285:             if (!internal)
>> 1286:                 unlockPhase();
>> 1287:             if ((room == 0 || U.getReference(a, pk) == null) && pool != null)
> 
> We used to look at `- 2` but now we look at `- 1`, perhaps that could account for stalls?

Well, the interplay of signal rules in push, runWorker, and deactivate lead to under/over signalling, scanning, contention. I'm about to commit a different tactic.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1913:
> 
>> 1911:                 if (!all)
>> 1912:                     break;
>> 1913:             }
> 
> Stylistically, it might be cleaner to do this:
> 
> Suggestion:
> 
>         do {
>             WorkQueue[] qs; WorkQueue v; int sp, i;
>             if ((sp = (int)c) == 0 || (qs = queues) == null ||
>                 qs.length <= (i = sp & SMASK) || (v = qs[i]) == null)
>                 break;
>             if (c == (c = compareAndExchangeCtl(
>                           c, ((UMASK & (c + RC_UNIT)) | (c & TC_MASK) |
>                               (v.stackPred & LMASK))))) {
>                 v.phase = sp;
>                 if (v.parking != 0)
>                     U.unpark(v.owner);
>             } while(all);

Yeah, except not quite that way, since the break should occur only if the CAS succeeds. I'll try other options.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806413628
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806417526
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806411821

From vklang at openjdk.org  Fri Oct 18 12:35:17 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 18 Oct 2024 12:35:17 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
In-Reply-To: <nkkbbyhK4cmjKqcTdMa1OZAwAGiQDZyjcFuZ6VloDQ4=.ab61c966-8dd2-4f34-a43c-6fdd8631735e@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <1weO1tM4iaGbFnxuDPEoICXG0Ri-5f1QQgtiZJ1CccI=.49d4f46d-ef9f-4b5a-9f47-61da21473a24@github.com>
 <nkkbbyhK4cmjKqcTdMa1OZAwAGiQDZyjcFuZ6VloDQ4=.ab61c966-8dd2-4f34-a43c-6fdd8631735e@github.com>
Message-ID: <JZ7HR922KuOi-fyD1pxMrKKbcTtFsOTybskndXH_4kE=.9cdd0b3c-b37d-471d-a9f0-b4c499a844af@github.com>

On Fri, 18 Oct 2024 12:27:34 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1913:
>> 
>>> 1911:                 if (!all)
>>> 1912:                     break;
>>> 1913:             }
>> 
>> Stylistically, it might be cleaner to do this:
>> 
>> Suggestion:
>> 
>>         do {
>>             WorkQueue[] qs; WorkQueue v; int sp, i;
>>             if ((sp = (int)c) == 0 || (qs = queues) == null ||
>>                 qs.length <= (i = sp & SMASK) || (v = qs[i]) == null)
>>                 break;
>>             if (c == (c = compareAndExchangeCtl(
>>                           c, ((UMASK & (c + RC_UNIT)) | (c & TC_MASK) |
>>                               (v.stackPred & LMASK))))) {
>>                 v.phase = sp;
>>                 if (v.parking != 0)
>>                     U.unpark(v.owner);
>>             } while(all);
>
> Yeah, except not quite that way, since the break should occur only if the CAS succeeds. I'll try other options.

Ah, I see what you mean, I must've inferred a closing brace before.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806415929

From duke at openjdk.org  Fri Oct 18 12:37:10 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 18 Oct 2024 12:37:10 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v7]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <eetIJK_Hp8RLbJZV26k5xzoFDw74CNGojMUi8hYP42o=.3b489cf6-ba06-4f39-acae-5e05f11aaa5a@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 incrementally with one additional commit since the last revision:

  Move `serialPersistentFields` for a degree of method order consistency

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19702/files
  - new: https://git.openjdk.org/jdk/pull/19702/files/38f7b79a..11bc95e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=05-06

  Stats: 70 lines in 2 files changed: 35 ins; 35 del; 0 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 vklang at openjdk.org  Fri Oct 18 12:51:09 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 18 Oct 2024 12:51:09 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
In-Reply-To: <nkkbbyhK4cmjKqcTdMa1OZAwAGiQDZyjcFuZ6VloDQ4=.ab61c966-8dd2-4f34-a43c-6fdd8631735e@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <1weO1tM4iaGbFnxuDPEoICXG0Ri-5f1QQgtiZJ1CccI=.49d4f46d-ef9f-4b5a-9f47-61da21473a24@github.com>
 <nkkbbyhK4cmjKqcTdMa1OZAwAGiQDZyjcFuZ6VloDQ4=.ab61c966-8dd2-4f34-a43c-6fdd8631735e@github.com>
Message-ID: <l_-EFZ3FCh9j8b9ZgjTxXVRlsL-bumltn5hDOzpBeRY=.95ebdf58-425f-4517-aa68-3ffbf2ed8e3a@github.com>

On Fri, 18 Oct 2024 12:32:21 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1287:
>> 
>>> 1285:             if (!internal)
>>> 1286:                 unlockPhase();
>>> 1287:             if ((room == 0 || U.getReference(a, pk) == null) && pool != null)
>> 
>> We used to look at `- 2` but now we look at `- 1`, perhaps that could account for stalls?
>
> Well, the interplay of signal rules in push, runWorker, and deactivate lead to under/over signalling, scanning, contention. I'm about to commit a different tactic.

Ok, staying tuned!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806440304

From lancea at openjdk.org  Fri Oct 18 12:58:17 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 12:58:17 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v4]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <aD0mpwaFtwRf1Fs8sELgrjyR2NPSl8CXuzHP28lLJ84=.4b7938bd-e479-4f76-b7ee-53c29e577efc@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Added additional validation to ZipEntry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/1ffaa722..15b8c26a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=02-03

  Stats: 218 lines in 2 files changed: 20 ins; 185 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From lancea at openjdk.org  Fri Oct 18 13:02:20 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 13:02:20 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v2]
In-Reply-To: <hZ4GNMOS7qO6W9ESnz0NwnxZSFQ2FZMmMJwU66lASHc=.7479104d-e1b3-4bc5-a4b3-e77f1a759701@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <sGaABOepb-P6VpubrMLlI2SzKX7dcWUfoi0TUHfOydc=.f5e9152c-5e5f-4253-a8cd-8506c398b8be@github.com>
 <7IxPd36daC_uVSUiZ6-1ZNbXJUHlo-rbgjfumkItAaw=.74556159-722e-4da1-bd98-e37e115e479c@github.com>
 <JPJjKswSCLPuUlnPg9rNlRizhP0W6S8TB4WZBrBBhGk=.26866ef0-9900-4ea3-9937-05be6e5cb86e@github.com>
 <mtp428G15vGas0-nl19JjLQgR3vSm7sCSAIW1j9EVU0=.d16da4c2-8c2d-4610-9893-670294c99941@github.com>
 <hZ4GNMOS7qO6W9ESnz0NwnxZSFQ2FZMmMJwU66lASHc=.7479104d-e1b3-4bc5-a4b3-e77f1a759701@github.com>
Message-ID: <03DxjTWp7-jXvCbbFh1Sogyq5Q6qqCEfmuphArmUObg=.27bf6c4e-0df5-400a-94ca-e9db393572d4@github.com>

On Thu, 17 Oct 2024 19:29:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> I had thought about that and decided to keep the changes as they are. I am not opposed to revisiting this in a follow on PR. Any additional changes would require more javadoc updates to address the overall change in validation.
>>> 
>>> So after we fork JDK 24, happyt to revisit.
>> 
>> If the route we're taking ends up with having `ZipEntry` manage its own invariant here, then I'm only lukewarm to including this solution in 24 which only takes us half way and has weaker validation than what's already in place in `ZipOutputStream`.  There would be less API churn if we hold our breath here and do it "right" in a single release.
>> 
>> But that's my subjective opinion, it's understandable and fine that others see it differently.
>
>> But that's my subjective opinion, it's understandable and fine that others see it differently.
> 
> Again, I understand your suggestion and will give it some  additional thought. The original intent was to address the incorrect max value that each of the 3 fields were being validated against, which has been there since at least JDK 1.3.
>  
> Overall this is a corner case and out of a search of 90,000+ jars, only 520 CEN Headers were encountered with a size between 500-1000 bytes, all other entries were < 500 bytes.

Ok,  I revised ZipEntry to incorporate your suggestion.   I kept the validation in ZipOutputStream::putNextEntry in the unlikely event ZipEntry is extended based on a suggestion from Jai.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806452806

From dl at openjdk.org  Fri Oct 18 13:02:51 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 18 Oct 2024 13:02:51 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
In-Reply-To: <c1Y1dp7t9hdgBh0fg5DNTiFqR3hjtjwRRbNL6HHH42U=.4593b749-0db5-4e5d-ab78-9010386768e0@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <c1Y1dp7t9hdgBh0fg5DNTiFqR3hjtjwRRbNL6HHH42U=.4593b749-0db5-4e5d-ab78-9010386768e0@github.com>
Message-ID: <Q628Pg5Gg6pNL_H70IskSWX7B5oSKnXwfJ3Ee5HpiG4=.450b830b-dac6-45f9-b20e-7bc064e3478c@github.com>

On Wed, 16 Oct 2024 16:38:13 GMT, Viktor Klang <vklang 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),
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1969:
> 
>> 1967:             int phase = w.phase, r = w.stackPred;     // seed from registerWorker
>> 1968:             int cfg = w.config, nsteals = 0, src = -1;
>> 1969:             for (;;) {
> 
> Could the non-labeled version introduce different GC safepoints which could have adverse impacts? ?

Yes, one of many uncertainties and tradeoffs...

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2279:
> 
>> 2277:                                 if (U.compareAndSetReference(a, k, t, null)) {
>> 2278:                                     q.base = b + 1;
>> 2279:                                     w.source = j;
> 
> Might be worth commenting the volatile-write piggybacking which allows to get away with not calling updateBase above? ?

Thanks; done

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2433:
> 
>> 2431:                             if (U.compareAndSetReference(a, k, t, null)) {
>> 2432:                                 q.base = nb;
>> 2433:                                 w.source = j;
> 
> Might be worth commenting the volatile-write piggybacking which allows to get away with not calling updateBase above? ?

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806452514
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806454588
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806454936

From eirbjo at openjdk.org  Fri Oct 18 13:22:14 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 13:22:14 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v4]
In-Reply-To: <aD0mpwaFtwRf1Fs8sELgrjyR2NPSl8CXuzHP28lLJ84=.4b7938bd-e479-4f76-b7ee-53c29e577efc@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <aD0mpwaFtwRf1Fs8sELgrjyR2NPSl8CXuzHP28lLJ84=.4b7938bd-e479-4f76-b7ee-53c29e577efc@github.com>
Message-ID: <qhTIjBtHThU_j_FZjfMJ46Qfd7very-l04D3TT4hLcQ=.b2af26aa-1bd9-4e0c-bcfb-2d720b574861@github.com>

On Fri, 18 Oct 2024 12:58:17 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added additional validation to ZipEntry

src/java.base/share/classes/java/util/zip/ZipEntry.java line 723:

> 721:      * @return true if valid CEN Header size; false otherwise
> 722:      */
> 723:     private static  boolean isCENHeaderValid(String name, byte[] extra, String comment) {

Extra space before `boolean`

Suggestion:

    private static boolean isCENHeaderValid(String name, byte[] extra, String comment) {

src/java.base/share/classes/java/util/zip/ZipEntry.java line 726:

> 724:         int clen = comment == null ? 0 : comment.length();
> 725:         int elen = extra == null ? 0 : extra.length;
> 726:         int headerSize = CENHDR + name.length() + clen + elen;

`headerSize` may overflow `int`

src/java.base/share/classes/java/util/zip/ZipEntry.java line 727:

> 725:         int elen = extra == null ? 0 : extra.length;
> 726:         int headerSize = CENHDR + name.length() + clen + elen;
> 727:         return headerSize <= MAX_COMBINED_CEN_HEADER_SIZE ? true : false;

Unless this was a stylistic choice, this might be simpler:

Suggestion:

        return headerSize <= MAX_COMBINED_CEN_HEADER_SIZE;

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 268:

> 266:         // should not exceed 65,535 bytes per the PKWare APP.NOTE
> 267:         // 4.4.10, 4.4.11, & 4.4.12.
> 268:         int clen = e.comment == null ? 0 : e.comment.length();

If `ZipEntry.isCENHeaderValid` was package-protected, it seems you could use it from here, like:

`ZipEntry.isCENHeaderValid(e.name, e.extra, e.length)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806470587
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806472325
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806472519
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806476434

From asemenyuk at openjdk.org  Fri Oct 18 13:30:47 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Oct 2024 13:30:47 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v3]
In-Reply-To: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
Message-ID: <mhaLOdw575kjyV82oMuQwAMUdGMiDExDylAxCNVJf80=.ac60afe3-4701-4e57-90b5-e52204c76d50@github.com>

> Make jpackage correctly handle the output directory (`--dest`) that is:
>  - a subdirectory of the input directory;
>  - the same as the input directory.
> 
> Make jpackage correctly handle temp directory (`--temp`) that is:
>  - a subdirectory of the input directory.
> 
> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
> 
> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
> 
> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
> 
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
> 
> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Replace Path.equals() call with Files.isSameFile()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21550/files
  - new: https://git.openjdk.org/jdk/pull/21550/files/20f30152..3cbd2a2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=01-02

  Stats: 9 lines in 1 file changed: 2 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21550/head:pull/21550

PR: https://git.openjdk.org/jdk/pull/21550

From eirbjo at openjdk.org  Fri Oct 18 13:32:38 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 13:32:38 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v4]
In-Reply-To: <aD0mpwaFtwRf1Fs8sELgrjyR2NPSl8CXuzHP28lLJ84=.4b7938bd-e479-4f76-b7ee-53c29e577efc@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <aD0mpwaFtwRf1Fs8sELgrjyR2NPSl8CXuzHP28lLJ84=.4b7938bd-e479-4f76-b7ee-53c29e577efc@github.com>
Message-ID: <t-5S1HQnUbG9GpAFkuleMEj_54p8jVjlUtpujcvLsPw=.09a9410f-bafd-4a62-b8ad-cc22070b17e1@github.com>

On Fri, 18 Oct 2024 12:58:17 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added additional validation to ZipEntry

Looks good. See comment about `headerSize` overflow plus some other minor comments.

Would this change in the `ZipEntry` API description require a re-approval of the CSR, even if just a formality?

src/java.base/share/classes/java/util/zip/ZipEntry.java line 106:

> 104:      * @throws NullPointerException if the entry name is null
> 105:      * @throws IllegalArgumentException if the combined length of the entry name
> 106:      * and {@linkplain #CENHDR CEN Header size} exceeds 65,535 bytes.

English is not my native language, but should 'CEN header size" be preceded by the definite article "the", here and in setExtra/setComment ?

src/java.base/share/classes/java/util/zip/ZipEntry.java line 652:

> 650:      * @param comment the comment string
> 651:      * @throws IllegalArgumentException if the combined length
> 652:      * of the specified entry comment, {@linkplain #getName() entry name},

'entry name' is preceded by the definite article 'the' in `setExtra`, but not here. Would be good to be consistent.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21544#pullrequestreview-2378084998
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806487837
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806492209

From lancea at openjdk.org  Fri Oct 18 13:42:49 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 13:42:49 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v4]
In-Reply-To: <t-5S1HQnUbG9GpAFkuleMEj_54p8jVjlUtpujcvLsPw=.09a9410f-bafd-4a62-b8ad-cc22070b17e1@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <aD0mpwaFtwRf1Fs8sELgrjyR2NPSl8CXuzHP28lLJ84=.4b7938bd-e479-4f76-b7ee-53c29e577efc@github.com>
 <t-5S1HQnUbG9GpAFkuleMEj_54p8jVjlUtpujcvLsPw=.09a9410f-bafd-4a62-b8ad-cc22070b17e1@github.com>
Message-ID: <s0sBBzoSgpysaydraxy3IJRVxsa3CHQ24SbkDahTL1M=.0210ba52-8a98-494c-83fd-4ddc46658c29@github.com>

On Fri, 18 Oct 2024 13:24:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added additional validation to ZipEntry
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 106:
> 
>> 104:      * @throws NullPointerException if the entry name is null
>> 105:      * @throws IllegalArgumentException if the combined length of the entry name
>> 106:      * and {@linkplain #CENHDR CEN Header size} exceeds 65,535 bytes.
> 
> English is not my native language, but should 'CEN header size" be preceded by the definite article "the", here and in setExtra/setComment ?

Not really needed but added anyways

> src/java.base/share/classes/java/util/zip/ZipEntry.java line 652:
> 
>> 650:      * @param comment the comment string
>> 651:      * @throws IllegalArgumentException if the combined length
>> 652:      * of the specified entry comment, {@linkplain #getName() entry name},
> 
> 'entry name' is preceded by the definite article 'the' in `setExtra`, but not here. Would be good to be consistent.

Done

> src/java.base/share/classes/java/util/zip/ZipEntry.java line 723:
> 
>> 721:      * @return true if valid CEN Header size; false otherwise
>> 722:      */
>> 723:     private static  boolean isCENHeaderValid(String name, byte[] extra, String comment) {
> 
> Extra space before `boolean`
> 
> Suggestion:
> 
>     private static boolean isCENHeaderValid(String name, byte[] extra, String comment) {

fixed

> src/java.base/share/classes/java/util/zip/ZipEntry.java line 726:
> 
>> 724:         int clen = comment == null ? 0 : comment.length();
>> 725:         int elen = extra == null ? 0 : extra.length;
>> 726:         int headerSize = CENHDR + name.length() + clen + elen;
> 
> `headerSize` may overflow `int`, here and in `ZipOutputStream`

Changed to 
`long headerSize = (long)CENHDR + name.length() + clen + elen;`

> src/java.base/share/classes/java/util/zip/ZipEntry.java line 727:
> 
>> 725:         int elen = extra == null ? 0 : extra.length;
>> 726:         int headerSize = CENHDR + name.length() + clen + elen;
>> 727:         return headerSize <= MAX_COMBINED_CEN_HEADER_SIZE ? true : false;
> 
> Unless this was a stylistic choice, this might be simpler:
> 
> Suggestion:
> 
>         return headerSize <= MAX_COMBINED_CEN_HEADER_SIZE;

done

> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 268:
> 
>> 266:         // should not exceed 65,535 bytes per the PKWare APP.NOTE
>> 267:         // 4.4.10, 4.4.11, & 4.4.12.
>> 268:         int clen = e.comment == null ? 0 : e.comment.length();
> 
> If `ZipEntry.isCENHeaderValid` was package-protected, it seems you could use it from here, like:
> 
> `ZipEntry.isCENHeaderValid(e.name, e.extra, e.comment)`

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806507539
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806507648
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806509705
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806509453
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806508512
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806507936

From lancea at openjdk.org  Fri Oct 18 13:49:01 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 13:49:01 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v4]
In-Reply-To: <t-5S1HQnUbG9GpAFkuleMEj_54p8jVjlUtpujcvLsPw=.09a9410f-bafd-4a62-b8ad-cc22070b17e1@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <aD0mpwaFtwRf1Fs8sELgrjyR2NPSl8CXuzHP28lLJ84=.4b7938bd-e479-4f76-b7ee-53c29e577efc@github.com>
 <t-5S1HQnUbG9GpAFkuleMEj_54p8jVjlUtpujcvLsPw=.09a9410f-bafd-4a62-b8ad-cc22070b17e1@github.com>
Message-ID: <l-nb3YP0Dd7Raz-vqBc4-1JieuukNNw-UFT7pF3r9xo=.d3c402a7-5f6b-4d4f-960c-3e6e9fd6f53b@github.com>

On Fri, 18 Oct 2024 13:30:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Looks good. See comment about `headerSize` overflow plus some other minor comments.
Thank you
> 
> Would this change in the `ZipEntry` API description require a re-approval of the CSR, even if just a formality?

Yes the CSR will need to be approved again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21544#issuecomment-2422515005

From asemenyuk at openjdk.org  Fri Oct 18 13:49:55 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Oct 2024 13:49:55 GMT
Subject: RFR: 8342609: Bug in jpackage test helper
Message-ID: <l6DyfD0KC3hruoyIdozFp0iDlZktByR79zPG3ecxpug=.8b41340d-4e9a-4ac1-8389-f846af4e7642@github.com>

`Files.walk(root, 0)` returns the `root` itself and not the contents of the `root`.
Replaced `Files.walk(root, 0)` with `Files.list(root)` to get a non-recursive listing of the `root` directory.

-------------

Commit messages:
 - 8342609: Bug in jpackage test helper

Changes: https://git.openjdk.org/jdk/pull/21582/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21582&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342609
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21582/head:pull/21582

PR: https://git.openjdk.org/jdk/pull/21582

From asemenyuk at openjdk.org  Fri Oct 18 13:55:55 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Oct 2024 13:55:55 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v2]
In-Reply-To: <QcFfExHcJ2N9yYk3VoJA4dm7iwBx4lCEhXd3wl7T5_s=.0870394b-d748-4d58-920e-db606e67eb71@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
 <Twv2ERu5NUTO2umV40ne1GgAnlD6Mw76BAxDeA9pD88=.51fe8bfe-c888-4978-906d-787c95a2fddc@github.com>
 <QcFfExHcJ2N9yYk3VoJA4dm7iwBx4lCEhXd3wl7T5_s=.0870394b-d748-4d58-920e-db606e67eb71@github.com>
Message-ID: <DQKVjOqoW3lK2sYmio2FRaHaupSvSth4KZ73EctxZos=.33793d9c-c47b-47ea-a793-12f3522e1f83@github.com>

On Thu, 17 Oct 2024 01:59:46 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use jdk.jpackage.test.Annotations.Parameter annotation to parameterize packaging type in the test
>
> Looks good.

@sashamatveev please review again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21550#issuecomment-2422531610

From eirbjo at openjdk.org  Fri Oct 18 13:59:32 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 13:59:32 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
Message-ID: <3AnmGVaQ0FToNg2uNrw-kkc_EQ9rceGbDIDVLVDi_hw=.524f6110-c5c4-43b9-bc0c-bc4e4b7e51e7@github.com>

> Please review this PR which speeds up `JarFile::getEntry` lookup significantly for multi-release JAR files.
> 
> The changes in this PR are motivated by the following insights:
> 
> * `META-INF/versions/` is sparsely populated.
> * Most entries are not versioned
> * The number of unique versions for each versioned entry is small
> * Many JAR files are 'accidentally' multi-release; they use the feature to hide `module-info.class` from Java 8.
> 
> Instead of  performing one lookup for every version identified in the JAR, this PR narrows the version search down to an approximation of the number of versions found for the entry being looked up, which will often be zero. This speeds up lookup for non-versioned entries, and provides a more targeted search for versioned entries.
> 
> An alternative approach could be to normalize the hash code to use the none-versioned name such that versioned and non-versioned names would be resolved in the same lookup. This was quickly abandoned since the code changes were intrusive and mixed too many JAR specific concerns into `ZipFile`.
> 
> Testing: The existing `JarFileGetEntry` benchmark is updated to optionally test a multi-release JAR file with one versioned entry for `module-info.class` plus two other versioned class files for two distinct versions. Performance results in [first comment](#issuecomment-2410901754).
> 
> Running `ZipFileOpen` on a multi-release JAR did not show a significat difference between this PR and mainline. 
> 
> The JAR and ZIP tests are run locally. GHA results green. The `noreg-perf` label is added in JBS.

Eirik Bj?rsn?s has updated the pull request incrementally with four additional commits since the last revision:

 - Map versions by entry name hashcode instead of by entry name. This avoids String allocation and storage
 - Merge pull request #1 from cl4es/bitset_versions
   
   Use BitSet to streamline construction
 - Fix traversal, traverse backwards to pick latest applicable version
 - Use BitSet to streamline construction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21489/files
  - new: https://git.openjdk.org/jdk/pull/21489/files/826d78a7..771488e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21489&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21489&range=01-02

  Stats: 65 lines in 3 files changed: 13 ins; 28 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21489/head:pull/21489

PR: https://git.openjdk.org/jdk/pull/21489

From redestad at openjdk.org  Fri Oct 18 13:59:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 18 Oct 2024 13:59:33 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <3AnmGVaQ0FToNg2uNrw-kkc_EQ9rceGbDIDVLVDi_hw=.524f6110-c5c4-43b9-bc0c-bc4e4b7e51e7@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <3AnmGVaQ0FToNg2uNrw-kkc_EQ9rceGbDIDVLVDi_hw=.524f6110-c5c4-43b9-bc0c-bc4e4b7e51e7@github.com>
Message-ID: <RWQ8rI6XCdH7B_K9ZZtGtUkDO7axGN2elT5InYsplM4=.4a4a8fdd-107a-4049-a65b-44af3d741814@github.com>

On Fri, 18 Oct 2024 13:54:30 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which speeds up `JarFile::getEntry` lookup significantly for multi-release JAR files.
>> 
>> The changes in this PR are motivated by the following insights:
>> 
>> * `META-INF/versions/` is sparsely populated.
>> * Most entries are not versioned
>> * The number of unique versions for each versioned entry is small
>> * Many JAR files are 'accidentally' multi-release; they use the feature to hide `module-info.class` from Java 8.
>> 
>> Instead of  performing one lookup for every version identified in the JAR, this PR narrows the version search down to an approximation of the number of versions found for the entry being looked up, which will often be zero. This speeds up lookup for non-versioned entries, and provides a more targeted search for versioned entries.
>> 
>> An alternative approach could be to normalize the hash code to use the none-versioned name such that versioned and non-versioned names would be resolved in the same lookup. This was quickly abandoned since the code changes were intrusive and mixed too many JAR specific concerns into `ZipFile`.
>> 
>> Testing: The existing `JarFileGetEntry` benchmark is updated to optionally test a multi-release JAR file with one versioned entry for `module-info.class` plus two other versioned class files for two distinct versions. Performance results in [first comment](#issuecomment-2410901754).
>> 
>> Running `ZipFileOpen` on a multi-release JAR did not show a significat difference between this PR and mainline. 
>> 
>> The JAR and ZIP tests are run locally. GHA results green. The `noreg-perf` label is added in JBS.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Map versions by entry name hashcode instead of by entry name. This avoids String allocation and storage
>  - Merge pull request #1 from cl4es/bitset_versions
>    
>    Use BitSet to streamline construction
>  - Fix traversal, traverse backwards to pick latest applicable version
>  - Use BitSet to streamline construction

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21489#pullrequestreview-2378113773

From eirbjo at openjdk.org  Fri Oct 18 13:59:33 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 13:59:33 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <MUOLROSYFryzzf3Ttf8bU7ycBZ8JXIo92bg5vBJWoos=.5025f0b3-5226-4987-aa53-adbe1a3e83b4@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
 <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
 <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>
 <rJ5z1Z1yVMcXP1JKrybs08oBvYkjhZ-J8dF0ma-A7IY=.dbcc5fac-97f0-49f6-b168-aa1ac651bca9@github.com>
 <MUOLROSYFryzzf3Ttf8bU7ycBZ8JXIo92bg5vBJWoos=.5025f0b3-5226-4987-aa53-adbe1a3e83b4@github.com>
Message-ID: <ZEZ1896tZaQDTfXZPsiGuwz0ZmMP_aNaZ0Sk-IMbIgg=.bb88b44e-8745-43a0-a657-cfca7e8aa906@github.com>

On Fri, 18 Oct 2024 09:23:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I suspect remaining regression is mostly from the added `String` creation/processing in `initCEN`.

Yes, there is a cost with the String construction when parsing the name out of `META-INF/versions/{name}`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806191274

From redestad at openjdk.org  Fri Oct 18 13:59:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 18 Oct 2024 13:59:33 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <rJ5z1Z1yVMcXP1JKrybs08oBvYkjhZ-J8dF0ma-A7IY=.dbcc5fac-97f0-49f6-b168-aa1ac651bca9@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
 <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
 <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>
 <rJ5z1Z1yVMcXP1JKrybs08oBvYkjhZ-J8dF0ma-A7IY=.dbcc5fac-97f0-49f6-b168-aa1ac651bca9@github.com>
Message-ID: <MUOLROSYFryzzf3Ttf8bU7ycBZ8JXIo92bg5vBJWoos=.5025f0b3-5226-4987-aa53-adbe1a3e83b4@github.com>

On Thu, 17 Oct 2024 22:32:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> I guess performance leans on there being only one or a small number of versions per entry. 
>> 
>> I checked Spring Petclinic:
>> 
>> * 109 JAR dependencies
>> * 15 are multi-release enabled.
>> * The 15 MR-JARs have 9347 entries, of which 21 are versioned
>> * 9 of 15 MR JARs use the feature exclusively to hide `module-info.class` from Java 8.
>> * 3 of the 6 remaining JAR files version a single class file
>> * The remaining JARs mostly version on the 9 release.
>> * The maximum number of versioned entries in a file is 5.
>> * Zero entries have more than a single version.
>> 
>>> Which I think is a fair assumption. Still would be good to have a stress test with many entries having many versions and make sure we don't regress such cases too much, no?
>> 
>> Such a test would be somewhat speculative. If I add 5 versions of each entry in `ZipFileOpen`, then yes, this PR sees a regression over mainline:
>> 
>> Baseline:
>> 
>> Benchmark                     (size)  Mode  Cnt       Score       Error  Units
>> ZipFileOpen.openCloseZipFile    1024  avgt   15  718234.380 ? 29454.645  ns/op
>> 
>> 
>> PR:
>> 
>> Benchmark                     (size)  Mode  Cnt        Score       Error  Units
>> ZipFileOpen.openCloseZipFile    1024  avgt   15  1284944.601 ? 74919.522  ns/op
>> 
>> 
>> While `JarFileGetEntry` improves over baseline:
>> 
>> Baseline:
>> 
>> Benchmark                              (mr)  (size)  Mode  Cnt    Score   Error  Units
>> JarFileGetEntry.getEntryHit           false    1024  avgt   15   68.984 ? 2.791  ns/op
>> JarFileGetEntry.getEntryHit            true    1024  avgt   15  324.763 ? 9.690  ns/op
>> JarFileGetEntry.getEntryHitUncached   false    1024  avgt   15   95.884 ? 1.404  ns/op
>> JarFileGetEntry.getEntryHitUncached    true    1024  avgt   15  333.491 ? 3.576  ns/op
>> JarFileGetEntry.getEntryMiss          false    1024  avgt   15   37.358 ? 2.215  ns/op
>> JarFileGetEntry.getEntryMiss           true    1024  avgt   15  650.467 ? 5.116  ns/op
>> JarFileGetEntry.getEntryMissUncached  false    1024  avgt   15   61.059 ? 0.382  ns/op
>> JarFileGetEntry.getEntryMissUncached   true    1024  avgt   15  678.457 ? 4.390  ns/op
>> 
>> 
>> PR:
>> 
>> 
>> Benchmark                              (mr)  (size)  Mode  Cnt    Score    Error  Units
>> JarFileGetEntry.getEntryHit           false    1024  avgt   15   61.333 ?  3.665  ns/op
>> JarFileGetEntry.getEntryHit            true    1024  avgt   15  153.987 ?  8.889  ns/op
>> JarFileGetEntry.getEntryHitUncached   false    1024  avgt   15   90.008 ? ...
>
> I poked around with an alternative approach that uses `java.util.BitSet`. This also allows us to use the map we build up as-is, avoids sorting et.c. Performance on `JarFileGetEntry` (#21489 version) is the same in my testing, but performance on `ZipFileOpen` with your 5 versions of each entry stress test should be much improved (might beat the baseline). Can you share your local changes to that micro in a gist or e-mail so I can verify?

With this change to `ZipFileOpen`: 

diff --git a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
index 4f6ae6373ec..0e22cf7f0ab 100644
--- a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
+++ b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
@@ -73,6 +73,11 @@ public void beforeRun() throws IOException {

                 ename += entryPrefixes[i % entryPrefixes.length] + "-" + i;
                 zos.putNextEntry(new ZipEntry(ename));
+                zos.putNextEntry(new ZipEntry("META-INF/versions/9/" + ename));
+                zos.putNextEntry(new ZipEntry("META-INF/versions/11/" + ename));
+                zos.putNextEntry(new ZipEntry("META-INF/versions/17/" + ename));
+                zos.putNextEntry(new ZipEntry("META-INF/versions/21/" + ename));
+                zos.putNextEntry(new ZipEntry("META-INF/versions/24/" + ename));
             }
         }
         zipFile = tempFile;


On that modified `ZipFileOpen` micro,
https://github.com/eirbjo/jdk/pull/1 improves over #21489 but still regress compared to the baseline:


Benchmark                       (size)  Mode  Cnt        Score       Error  Units
ZipFileOpen.openCloseZipFile      1024  avgt   15   677386,387 ? 15761,989  ns/op # baseline
ZipFileOpen.openCloseZipFile      1024  avgt   15  1121127,629 ? 16716,218  ns/op # pull/21489, 0.6x
ZipFileOpen.openCloseZipFile      1024  avgt   15   968501,630 ? 28761,067  ns/op # eirbjo/jdk#1, 0.7x


I suspect remaining regression is mostly from the added `String` creation/processing in `initCEN`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806179709

From redestad at openjdk.org  Fri Oct 18 13:59:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 18 Oct 2024 13:59:33 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <ZEZ1896tZaQDTfXZPsiGuwz0ZmMP_aNaZ0Sk-IMbIgg=.bb88b44e-8745-43a0-a657-cfca7e8aa906@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
 <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
 <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>
 <rJ5z1Z1yVMcXP1JKrybs08oBvYkjhZ-J8dF0ma-A7IY=.dbcc5fac-97f0-49f6-b168-aa1ac651bca9@github.com>
 <MUOLROSYFryzzf3Ttf8bU7ycBZ8JXIo92bg5vBJWoos=.5025f0b3-5226-4987-aa53-adbe1a3e83b4@github.com>
 <ZEZ1896tZaQDTfXZPsiGuwz0ZmMP_aNaZ0S
 k-IMbIgg=.bb88b44e-8745-43a0-a657-cfca7e8aa906@github.com>
Message-ID: <RM1yuslio0y1COwtd7LpMw7hYbqMmJXspBPQCg1CuR0=.2e79fd59-2b1f-405e-8c60-501976ebaae7@github.com>

On Fri, 18 Oct 2024 09:31:45 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> With this change to `ZipFileOpen`: 
>> 
>> diff --git a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
>> index 4f6ae6373ec..0e22cf7f0ab 100644
>> --- a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
>> +++ b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
>> @@ -73,6 +73,11 @@ public void beforeRun() throws IOException {
>> 
>>                  ename += entryPrefixes[i % entryPrefixes.length] + "-" + i;
>>                  zos.putNextEntry(new ZipEntry(ename));
>> +                zos.putNextEntry(new ZipEntry("META-INF/versions/9/" + ename));
>> +                zos.putNextEntry(new ZipEntry("META-INF/versions/11/" + ename));
>> +                zos.putNextEntry(new ZipEntry("META-INF/versions/17/" + ename));
>> +                zos.putNextEntry(new ZipEntry("META-INF/versions/21/" + ename));
>> +                zos.putNextEntry(new ZipEntry("META-INF/versions/24/" + ename));
>>              }
>>          }
>>          zipFile = tempFile;
>> 
>> 
>> On that modified `ZipFileOpen` micro,
>> https://github.com/eirbjo/jdk/pull/1 improves over #21489 but still regress compared to the baseline:
>> 
>> 
>> Benchmark                       (size)  Mode  Cnt        Score       Error  Units
>> ZipFileOpen.openCloseZipFile      1024  avgt   15   677386,387 ? 15761,989  ns/op # baseline
>> ZipFileOpen.openCloseZipFile      1024  avgt   15  1121127,629 ? 16716,218  ns/op # pull/21489, 0.6x
>> ZipFileOpen.openCloseZipFile      1024  avgt   15   968501,630 ? 28761,067  ns/op # eirbjo/jdk#1, 0.7x
>> 
>> 
>> I suspect remaining regression is mostly from the added `String` creation/processing in `initCEN`.
>
>> I suspect remaining regression is mostly from the added `String` creation/processing in `initCEN`.
> 
> Yes, there is a cost with the String construction when parsing the name out of `META-INF/versions/{name}`

There are a few possible strategies for avoiding that additional parse, since the effect we're getting at here is to have a quick filter to avoid pointless lookups and not necessarily an exact mapping.

One is to store the `checkedHash` rather than the full `String`. This gets `openCloseZipFile` down to ~910000 ns/op. (`checkedHash` very hot in profiles). There's still a chance for redundant lookups on hash collisions, but this should be rare.

Another is to store a `BitSet` per name length. This gets `ZipFileOpen` down to baseline level (~670000 ns/op), but increases chance of having to do redundant lookups a lot.

Both also improves footprint (not keeping each versioned entry `String` in memory would be nice).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806242792

From eirbjo at openjdk.org  Fri Oct 18 13:59:33 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 13:59:33 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <RM1yuslio0y1COwtd7LpMw7hYbqMmJXspBPQCg1CuR0=.2e79fd59-2b1f-405e-8c60-501976ebaae7@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
 <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
 <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>
 <rJ5z1Z1yVMcXP1JKrybs08oBvYkjhZ-J8dF0ma-A7IY=.dbcc5fac-97f0-49f6-b168-aa1ac651bca9@github.com>
 <MUOLROSYFryzzf3Ttf8bU7ycBZ8JXIo92bg5vBJWoos=.5025f0b3-5226-4987-aa53-adbe1a3e83b4@github.com>
 <ZEZ1896tZaQDTfXZPsiGuwz0ZmMP_aNaZ0S
 k-IMbIgg=.bb88b44e-8745-43a0-a657-cfca7e8aa906@github.com>
 <RM1yuslio0y1COwtd7LpMw7hYbqMmJXspBPQCg1CuR0=.2e79fd59-2b1f-405e-8c60-501976ebaae7@github.com>
Message-ID: <IB_2TIkKVjsrj4g0X67ftvILfWpjfSej3CkbCorOatM=.71c84105-9db0-4120-b630-02ad2bc8351a@github.com>

On Fri, 18 Oct 2024 10:04:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> One is to store the `checkedHash` rather than the full `String`. This gets `openCloseZipFile` down to ~910000 ns/op. (`checkedHash` very hot in profiles). There's still a chance for redundant lookups on hash collisions, but this should be rare.

Seems like a resonable trade-off.  Could you take a look at the latest 771488e and see if that represents your suggestion here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806388657

From redestad at openjdk.org  Fri Oct 18 13:59:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 18 Oct 2024 13:59:33 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <IB_2TIkKVjsrj4g0X67ftvILfWpjfSej3CkbCorOatM=.71c84105-9db0-4120-b630-02ad2bc8351a@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
 <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
 <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>
 <rJ5z1Z1yVMcXP1JKrybs08oBvYkjhZ-J8dF0ma-A7IY=.dbcc5fac-97f0-49f6-b168-aa1ac651bca9@github.com>
 <MUOLROSYFryzzf3Ttf8bU7ycBZ8JXIo92bg5vBJWoos=.5025f0b3-5226-4987-aa53-adbe1a3e83b4@github.com>
 <ZEZ1896tZaQDTfXZPsiGuwz0ZmMP_aNaZ0S
 k-IMbIgg=.bb88b44e-8745-43a0-a657-cfca7e8aa906@github.com>
 <RM1yuslio0y1COwtd7LpMw7hYbqMmJXspBPQCg1CuR0=.2e79fd59-2b1f-405e-8c60-501976ebaae7@github.com>
 <IB_2TIkKVjsrj4g0X67ftvILfWpjfSej3CkbCorOatM=.71c84105-9db0-4120-b630-02ad2bc8351a@github.com>
Message-ID: <bqEveRzaIu17mNKNsluy5GDTQdaP5EDRl4sWye60jZI=.3de58578-5d18-4e22-a2c3-21ff4e0d637b@github.com>

On Fri, 18 Oct 2024 12:08:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> There are a few possible strategies for avoiding that additional parse, since the effect we're getting at here is to have a quick filter to avoid pointless lookups and not necessarily an exact mapping.
>> 
>> One is to store the `checkedHash` rather than the full `String`. This gets `openCloseZipFile` down to ~910000 ns/op. (`checkedHash` very hot in profiles). There's still a chance for redundant lookups on hash collisions, but this should be rare.
>> 
>> Another is to store a `BitSet` per name length. This gets `ZipFileOpen` down to baseline level (~670000 ns/op), but increases chance of having to do redundant lookups a lot.
>> 
>> Both also improves footprint (not keeping each versioned entry `String` in memory would be nice).
>
>> One is to store the `checkedHash` rather than the full `String`. This gets `openCloseZipFile` down to ~910000 ns/op. (`checkedHash` very hot in profiles). There's still a chance for redundant lookups on hash collisions, but this should be rare.
> 
> Seems like a resonable trade-off.  Could you take a look at the latest 771488e and see if that represents your suggestion here?

Yes, 771488e matches my quick experiment (sans some cleanups you've made). I agree this variant makes for a reasonable trade-off.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806420039

From redestad at openjdk.org  Fri Oct 18 13:59:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 18 Oct 2024 13:59:33 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <bqEveRzaIu17mNKNsluy5GDTQdaP5EDRl4sWye60jZI=.3de58578-5d18-4e22-a2c3-21ff4e0d637b@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <zMOzIZhNLCODIYU3VxDU23eBCfueKDOo8kP9l4OWOx8=.3e38351b-226d-410a-bdf8-fe164b93f3a6@github.com>
 <o65O1IMpcygBXU0BqhpAgXMaa8bKY8eKO8zWRD6QkO0=.bf12f4a7-dace-42fc-ab9a-c32a394aa6bc@github.com>
 <ry7zRC4euV1aCbA8HFLRMqfwXcdWhJhb5PCN9SAQjec=.9b7c05c7-81f5-4c86-ae09-1219595b5eec@github.com>
 <I604bLhzxr_0Pd2fh2X8HlLSPMZ0wcwgkTAWo409Io8=.16a8b332-b595-43c8-8307-1f7737e24967@github.com>
 <4K_SrPoY9cO15HOMoNMDBDyjWCCIcbzVTJeerHFQhNY=.52048bae-7471-4486-b82d-d039303badc8@github.com>
 <rp-a0JmRGlfoZY8GaTetk-399haho0ZzCseVY0ZT4Nc=.b3440eb1-c23e-496b-87b8-86c239d76157@github.com>
 <e3cQ3r0VRQZHXN0yfNguqUL6lPS10jIoYsZmD-3OS40=.4787ba65-78a8-4d4e-8960-8782b2dc12a1@github.com>
 <rJ5z1Z1yVMcXP1JKrybs08oBvYkjhZ-J8dF0ma-A7IY=.dbcc5fac-97f0-49f6-b168-aa1ac651bca9@github.com>
 <MUOLROSYFryzzf3Ttf8bU7ycBZ8JXIo92bg5vBJWoos=.5025f0b3-5226-4987-aa53-adbe1a3e83b4@github.com>
 <ZEZ1896tZaQDTfXZPsiGuwz0ZmMP_aNaZ0S
 k-IMbIgg=.bb88b44e-8745-43a0-a657-cfca7e8aa906@github.com>
 <RM1yuslio0y1COwtd7LpMw7hYbqMmJXspBPQCg1CuR0=.2e79fd59-2b1f-405e-8c60-501976ebaae7@github.com>
 <IB_2TIkKVjsrj4g0X67ftvILfWpjfSej3CkbCorOatM=.71c84105-9db0-4120-b630-02ad2bc8351a@github.com>
 <bqEveRzaIu17mNKNsluy5GDTQdaP5EDRl4sWye60jZI=.3de58578-5d18-4e22-a2c3-21ff4e0d637b@github.com>
Message-ID: <t_wiwLsymL0WCFTDgXLWOWtrrjnqmGpSS_n0-FZTP4c=.58a5b515-9127-434b-b875-9ad8da04af69@github.com>

On Fri, 18 Oct 2024 12:34:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> One is to store the `checkedHash` rather than the full `String`. This gets `openCloseZipFile` down to ~910000 ns/op. (`checkedHash` very hot in profiles). There's still a chance for redundant lookups on hash collisions, but this should be rare.
>> 
>> Seems like a resonable trade-off.  Could you take a look at the latest 771488e and see if that represents your suggestion here?
>
> Yes, 771488e matches my quick experiment (sans some cleanups you've made). I agree this variant makes for a reasonable trade-off.

Maybe there's some benefit in detecting "META-INF/versions/" in the `checkAndAddEntry` method and then calculate the two different hash values back to back. Hash calculations are fast on modern hardware with vector support, but the memory accesses might not be so we might get a general win from re-arranging some of this stuff. I think this is more suitable for a follow-up experiment, though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806512558

From lancea at openjdk.org  Fri Oct 18 14:02:09 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 14:02:09 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v5]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <tEtQyCOVbt4DwC_1JKu1jnmhODpzsouGgABFPu721Mw=.0ddec8cb-1c51-4a2e-a498-946cbde45cdc@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address PR feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/15b8c26a..68e0dcb5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=03-04

  Stats: 13 lines in 2 files changed: 1 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From alanb at openjdk.org  Fri Oct 18 14:15:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 14:15:46 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
Message-ID: <QviCbRGIh2l6AUtWZcfBcxeUAX0NjO75ZfamwT74DeM=.4b98f9b0-6b15-4799-9993-f66bdf7ccae7@github.com>

On Wed, 16 Oct 2024 14:55:34 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` launcher, 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 launcher 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:
>> 
>> $ java
>> 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 single-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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:
> 
>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'

One general comment is that it now means the java launcher has 3 usages pages, the default, --help, and -X.

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 240:

> 238: \  <MainClass>                to execute the main method of a compiled class\n\
> 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\

Did you mean to use capitals here? It will look different to the `--help` output where we consistently use all lowercase.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2422575010
PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1806566278

From asemenyuk at openjdk.org  Fri Oct 18 14:42:39 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 18 Oct 2024 14:42:39 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v4]
In-Reply-To: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
Message-ID: <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>

> Make jpackage correctly handle the output directory (`--dest`) that is:
>  - a subdirectory of the input directory;
>  - the same as the input directory.
> 
> Make jpackage correctly handle temp directory (`--temp`) that is:
>  - a subdirectory of the input directory.
> 
> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
> 
> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
> 
> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
> 
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
> 
> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Files.isSameFile() throws exception if a file doesn't exist

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21550/files
  - new: https://git.openjdk.org/jdk/pull/21550/files/3cbd2a2d..5065a3bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=02-03

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21550/head:pull/21550

PR: https://git.openjdk.org/jdk/pull/21550

From jbhateja at openjdk.org  Fri Oct 18 14:44:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Oct 2024 14:44:04 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMULUDQ instruction [v4]
In-Reply-To: <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.04582d26-8f0b-46e5-a5c0-7d6ea4164e63@github.com>
 <tSiOMGbnJu-4jK09wRa4EqanphytWnEdiZRmHGYdDdw=.eac955b6-5e32-4645-b022-07b5e4c759b6@github.com>
Message-ID: <enKflQteLdiDru7QBViRyyoIyxRQm64zW_Zq_J9cIIc=.2cefc412-c0f8-43ef-a9f3-84def1e932ee@github.com>

On Fri, 18 Oct 2024 02:03:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMULUDQ instruction for following IR pallets.
>>   
>> 
>>        MulL   ( And  SRC1,  0xFFFFFFFF)   ( And  SRC2,  0xFFFFFFFF) 
>>        MulL   (URShift SRC1 , 32) (URShift SRC2, 32)
>>        MulL   (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>        MulL   ( And  SRC1,  0xFFFFFFFF) (URShift 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.
>>  
>> VPMULUDQ 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   ...
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Review resolutions
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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-2422634178

From jbhateja at openjdk.org  Fri Oct 18 14:56:29 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 18 Oct 2024 14:56:29 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Replacing flag based checks with CPU feature checks in IR validation test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/3ee0de07..dacc9313

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=28-29

  Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From heidinga at openjdk.org  Fri Oct 18 14:59:54 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 18 Oct 2024 14:59:54 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
 <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
Message-ID: <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>

On Fri, 18 Oct 2024 04:24:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've added a comment and tightened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)
>
> (I've replied to this comment. I can see it in the mailing list but it seems to be lost on this page, so I'll add it again)
> 
> We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've updated the comment and tghtened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)

I looked at the InnerClassLambdaMetaFactory and it only generates MHs.Lookup.ClassOption::STRONG classes that live as long as their corresponding loaders.  Given that, do we want an assert here that we are only dealing with strong hidden classes?  ie: `assert(ik->is_hidden() && !ik->is_non_strong_hidden());`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1806644336

From bpb at openjdk.org  Fri Oct 18 15:07:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Oct 2024 15:07:23 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <s8rlCXNr1Y5mrQu2J-Ec6zn0SeilcN-aSv_9CMeqMh8=.997ecee3-e683-421b-ae16-73bc994264ae@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
 <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>
 <s8rlCXNr1Y5mrQu2J-Ec6zn0SeilcN-aSv_9CMeqMh8=.997ecee3-e683-421b-ae16-73bc994264ae@github.com>
Message-ID: <IfwJXJ91c8FUaA_h6Z-dSbEt4Lmy8ExglYgjAi0ot4E=.8738e5d5-e940-4cd7-844d-2d7aab1273fa@github.com>

On Fri, 18 Oct 2024 08:06:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I added test coverage for `skip` but not for `readAllBytes` nor `readNBytes`:
>> - `readAllBytes` throws before but hangs after the change;
>> - `readNBytes` hangs both before and after the change.
>
> I wonder if there is another special file that could be read to EOF to allow the methods be tested. Asking because the overrides have a code path we need to test.

I need to investigate this. I might hold off integrating even thought it's approved until this is determined.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1806654280

From eirbjo at openjdk.org  Fri Oct 18 15:08:54 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 15:08:54 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <RWQ8rI6XCdH7B_K9ZZtGtUkDO7axGN2elT5InYsplM4=.4a4a8fdd-107a-4049-a65b-44af3d741814@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <3AnmGVaQ0FToNg2uNrw-kkc_EQ9rceGbDIDVLVDi_hw=.524f6110-c5c4-43b9-bc0c-bc4e4b7e51e7@github.com>
 <RWQ8rI6XCdH7B_K9ZZtGtUkDO7axGN2elT5InYsplM4=.4a4a8fdd-107a-4049-a65b-44af3d741814@github.com>
Message-ID: <QhSTf-LUrOJFMnOflHEAjmY37Ou0atQHKZ4V8Zd77Rs=.4527a0cd-da86-433d-9143-8cb92d2db959@github.com>

On Fri, 18 Oct 2024 13:41:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Map versions by entry name hashcode instead of by entry name. This avoids String allocation and storage
>>  - Merge pull request #1 from cl4es/bitset_versions
>>    
>>    Use BitSet to streamline construction
>>  - Fix traversal, traverse backwards to pick latest applicable version
>>  - Use BitSet to streamline construction
>
> Marked as reviewed by redestad (Reviewer).

Bringing this back from draft mode after some feedback and exploration with @cl4es 

The current version of this PR now uses a BitSet to represent versions. This speeds up version tracking in `initCEN` for the unusual case that there is a large number of versioned entries in the ZIP.

To summarize the performance benefits of this PR over baseline:

* The lookup overhead of multi-release with a few versioned entries is reduced from 5X to 1.2X
* For missing entries (very common in URLClassPath!), the overhead is reduced from 10X to 1.8X

Claes has approved this PR already, but since he contributed code and ideas to this PR, I'll let this linger until early next week to allow non-Scandinavian reviewers to have a look :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21489#issuecomment-2422677947

From dl at openjdk.org  Fri Oct 18 15:18:12 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 18 Oct 2024 15:18:12 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v2]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <9kT3vT460jQ155Pldue5LwW94UyCI3nJICr32EUFpjE=.0ac299b6-36a9-4067-b222-2ad068ab739b@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:

  Better disinguish need for exhaustive scans

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/a1ad02fc..0e3e9def

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=00-01

  Stats: 60 lines in 1 file changed: 18 ins; 14 del; 28 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  Fri Oct 18 15:36:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Oct 2024 15:36:59 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
 <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
 <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>
Message-ID: <TDRbhild6qu2VnOoDiur2r1dnjBVcssG5sa5xGwdeTQ=.efff346b-62b3-411b-baf3-35f452227fe3@github.com>

On Fri, 18 Oct 2024 14:56:23 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> (I've replied to this comment. I can see it in the mailing list but it seems to be lost on this page, so I'll add it again)
>> 
>> We only resolve indys for the boot/platform/app class loaders, so there's no need to support class unloading. I've updated the comment and tghtened up the code with asserts. See version [382446d](https://github.com/openjdk/jdk/pull/21143/commits/382446d41bb79c4bd2c1dfeda656dfa2a73466b4)
>
> I looked at the InnerClassLambdaMetaFactory and it only generates MHs.Lookup.ClassOption::STRONG classes that live as long as their corresponding loaders.  Given that, do we want an assert here that we are only dealing with strong hidden classes?  ie: `assert(ik->is_hidden() && !ik->is_non_strong_hidden());`

This is correct for the LMF, but I think we are using weak hidden classes in string concatenation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1806691703

From liach at openjdk.org  Fri Oct 18 15:46:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Oct 2024 15:46:41 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <3AnmGVaQ0FToNg2uNrw-kkc_EQ9rceGbDIDVLVDi_hw=.524f6110-c5c4-43b9-bc0c-bc4e4b7e51e7@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <3AnmGVaQ0FToNg2uNrw-kkc_EQ9rceGbDIDVLVDi_hw=.524f6110-c5c4-43b9-bc0c-bc4e4b7e51e7@github.com>
Message-ID: <cINvSoS5l3VqY6Qmtgw-yg6Vs9sv7v2U22ZiaMVMlMc=.815a783a-a74d-4baf-9dc4-509d53f8ebbf@github.com>

On Fri, 18 Oct 2024 13:59:32 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which speeds up `JarFile::getEntry` lookup significantly for multi-release JAR files.
>> 
>> The changes in this PR are motivated by the following insights:
>> 
>> * `META-INF/versions/` is sparsely populated.
>> * Most entries are not versioned
>> * The number of unique versions for each versioned entry is small
>> * Many JAR files are 'accidentally' multi-release; they use the feature to hide `module-info.class` from Java 8.
>> 
>> Instead of  performing one lookup for every version identified in the JAR, this PR narrows the version search down to an approximation of the number of versions found for the entry being looked up, which will often be zero. This speeds up lookup for non-versioned entries, and provides a more targeted search for versioned entries.
>> 
>> An alternative approach could be to normalize the hash code to use the none-versioned name such that versioned and non-versioned names would be resolved in the same lookup. This was quickly abandoned since the code changes were intrusive and mixed too many JAR specific concerns into `ZipFile`.
>> 
>> Testing: The existing `JarFileGetEntry` benchmark is updated to optionally test a multi-release JAR file with one versioned entry for `module-info.class` plus two other versioned class files for two distinct versions. Performance results in [first comment](#issuecomment-2410901754).
>> 
>> Running `ZipFileOpen` on a multi-release JAR did not show a significat difference between this PR and mainline. 
>> 
>> The JAR and ZIP tests are run locally. GHA results green. The `noreg-perf` label is added in JBS.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Map versions by entry name hashcode instead of by entry name. This avoids String allocation and storage
>  - Merge pull request #1 from cl4es/bitset_versions
>    
>    Use BitSet to streamline construction
>  - Fix traversal, traverse backwards to pick latest applicable version
>  - Use BitSet to streamline construction

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/util/zip/ZipFile.java line 1796:

> 1794:                                 if (metaVersions == null)
> 1795:                                     metaVersions = new HashMap<>();
> 1796:                                 metaVersions.computeIfAbsent(hashCode, _ -> new BitSet()).set(version);

Does this hashCode ever collide? Tried reading ZipCoder and can't rule that out. If yes, we need a fallback mechanism if this `computeIfAbsent` encountered an existing entry.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21489#pullrequestreview-2378459240
PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806704397

From vklang at openjdk.org  Fri Oct 18 15:52:15 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 18 Oct 2024 15:52:15 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v2]
In-Reply-To: <9kT3vT460jQ155Pldue5LwW94UyCI3nJICr32EUFpjE=.0ac299b6-36a9-4067-b222-2ad068ab739b@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <9kT3vT460jQ155Pldue5LwW94UyCI3nJICr32EUFpjE=.0ac299b6-36a9-4067-b222-2ad068ab739b@github.com>
Message-ID: <nW1Z31_EhxURpGbD-0Y1aUHtyJR6bJNXK4yeB4hVX-w=.b7bb566d-f50c-4c15-8958-1ba5f4c892b2@github.com>

On Fri, 18 Oct 2024 15:18:12 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:
> 
>   Better disinguish need for exhaustive scans

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2006:

> 2004:                                 if ((!propagated ||
> 2005:                                      ((j & 1) == 0) && t instanceof
> 2006:                                      ForkJoinTask.InterruptibleTask) &&

It's probably premature, but given that all subclasses of InterruptibleTask are final, and that InterruptibleTask is abstract, it _might_ be cheaper to check `t.getClass().getSuperClass() == ForkJoinTask.InterruptibleTask.class`? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1806709142

From eirbjo at openjdk.org  Fri Oct 18 16:06:58 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 16:06:58 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <cINvSoS5l3VqY6Qmtgw-yg6Vs9sv7v2U22ZiaMVMlMc=.815a783a-a74d-4baf-9dc4-509d53f8ebbf@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <3AnmGVaQ0FToNg2uNrw-kkc_EQ9rceGbDIDVLVDi_hw=.524f6110-c5c4-43b9-bc0c-bc4e4b7e51e7@github.com>
 <cINvSoS5l3VqY6Qmtgw-yg6Vs9sv7v2U22ZiaMVMlMc=.815a783a-a74d-4baf-9dc4-509d53f8ebbf@github.com>
Message-ID: <XcMWXJAQDY59g8JqkZHFIP3e9Wxi4CeiTiN36HaEG5E=.1f5b3900-7e0d-419c-a936-523c55565be2@github.com>

On Fri, 18 Oct 2024 15:43:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Map versions by entry name hashcode instead of by entry name. This avoids String allocation and storage
>>  - Merge pull request #1 from cl4es/bitset_versions
>>    
>>    Use BitSet to streamline construction
>>  - Fix traversal, traverse backwards to pick latest applicable version
>>  - Use BitSet to streamline construction
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1796:
> 
>> 1794:                                 if (metaVersions == null)
>> 1795:                                     metaVersions = new HashMap<>();
>> 1796:                                 metaVersions.computeIfAbsent(hashCode, _ -> new BitSet()).set(version);
> 
> Does this hashCode ever collide? Tried reading ZipCoder and can't rule that out. If yes, we need a fallback mechanism if this `computeIfAbsent` encountered an existing entry.

Yes, this is an overapproximation, so a hash collision may result?in an extra lookup being performed for a versioned entry which?does not exist for that version. See the comment on the `metaVersions` field declaration.

This is a trade-off against the initial alternative?proposed in this PR which was to map using the entry name string. That would minimize lookups, but it would also require allocating the String name and storing those strings in the map. So we decided a few extra lookups on hash collisions was an okay trade-off for faster parsing and less memory used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1806726866

From coleenp at openjdk.org  Fri Oct 18 16:21:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 18 Oct 2024 16:21:11 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
Message-ID: <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>

On Fri, 18 Oct 2024 02:25:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused classes
>
> src/hotspot/share/classfile/classFileParser.cpp line 4098:
> 
>> 4096:       }
>> 4097:     }
>> 4098: 
> 
> This code should not be removed. The spec for this code should now be:
> 
>   // If the loader is not the boot loader then throw an exception if its
>   // superclass is in package jdk.internal.reflect 
> 
> All we need do is remove the check:
> 
> && !java_lang_ClassLoader::is_reflection_class_loader

Oh that's a good find.  Maybe we should write a test for this, if as I assume there isn't one already.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1806742713

From psandoz at openjdk.org  Fri Oct 18 16:55:05 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 18 Oct 2024 16:55:05 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v25]
In-Reply-To: <sWXg913xsqvSuL3EiMoZqRwF0Hpro4lUdhZ1tP4LyXA=.e8330ff5-57d8-40e5-afdf-a088bf63be7d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <D7Z5t9txaC3DKoICztD2LVh8KWy2lp1OjhuE34m-0vs=.d20451eb-dc78-4341-bf26-f768e9895110@github.com>
 <RH-F5EFthOgifKhqYodz1lA4yZqxCVCXcLidS4b6xH8=.71bca1a4-39d3-4cd6-bdee-33b73907a6a4@github.com>
 <XpydOjKTpx5ooYX2h8q4JZl4ssQmpKhfq8deFK0ueII=.8cf57b1e-5e78-43b0-b352-4261a41a167a@github.com>
 <Gyr4Mnfh31tP3sZ-Lapm0TOdxUx3aZzR9p1N2vlp_J0=.810e2e30-3288-4b04-8409-52f878f786ee@github.com>
 <28MMdFkPrGQkT3nD8dUA2GAx6uZyRwERWn3bVvEPSR8=.79c2b5e5-7317-47c5-8878-30c4ac3171ab@github.com>
 <sWXg913xsqvSuL3EiMoZqRwF0Hpro4lUdhZ1tP4LyXA=.e8330ff5-57d8-40e5-afdf-a088bf63be7d@github.com>
Message-ID: <xQwDLIoLtbOsbKokEYjRD4RVbj2WiTf_yF8rhlRM4ko=.52c9eebc-d760-4450-b9ce-17700c57b1da@github.com>

On Thu, 17 Oct 2024 23:35:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > I have restricted the IR validation to just newly added UMin/UMax transformations.
> 
> Even then i think it better to do so in follow on PR, otherwise it is a moving target for review and testing. This new test fails on aarch64 e.g.,
> 
> ```
> STATUS:Failed.`main' threw exception: compiler.lib.ir_framework.shared.TestFormatException: Violations (16) --------------- - Could not find VM flag "UseAVX" in @IR rule 1 at public void compiler.vectorapi.VectorUnsignedMinMaxIRTransformsTest.umin_ir_transform1_byte()
> ...
> ```
> 
> Testing tier 1 to 3 with latest PR looks good otherwise.

The updated test passes with latest changes. You will need a HotSpot re-review including the new test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2422875427

From mchung at openjdk.org  Fri Oct 18 16:58:07 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 18 Oct 2024 16:58:07 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
 <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
Message-ID: <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>

On Fri, 18 Oct 2024 16:17:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 4098:
>> 
>>> 4096:       }
>>> 4097:     }
>>> 4098: 
>> 
>> This code should not be removed. The spec for this code should now be:
>> 
>>   // If the loader is not the boot loader then throw an exception if its
>>   // superclass is in package jdk.internal.reflect 
>> 
>> All we need do is remove the check:
>> 
>> && !java_lang_ClassLoader::is_reflection_class_loader
>
> Oh that's a good find.  Maybe we should write a test for this, if as I assume there isn't one already.
> Edit: not with this RFE, just in general.

> // If the loader is not the boot loader then throw an exception if its
> // superclass is in package jdk.internal.reflect

This will never happen.   `jdk.internal.reflect` is a non-exported package in `java.base` module.  If another module `M` defines a class whose superclass is in `jdk.internal.reflect` package, `java.base` must export `jdk.internal.reflect` package to `M` for access.   Otherwise, it will fail the super access check, as done in the check below this deleted code.


Reflection::VerifyClassAccessResults vca_result =
     Reflection::verify_class_access(this_klass, InstanceKlass::cast(super), false);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1806781954

From mchung at openjdk.org  Fri Oct 18 17:00:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 18 Oct 2024 17:00:45 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <FNQ8C8DWodZYnFtwFGGP1bSb1hHwp7QijYYB1tC8vsY=.ee363dee-15f2-4f54-b744-be15d4a326ea@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <FNQ8C8DWodZYnFtwFGGP1bSb1hHwp7QijYYB1tC8vsY=.ee363dee-15f2-4f54-b744-be15d4a326ea@github.com>
Message-ID: <D5XfCbb41xGrvQdNIO8n31u9NBOfHIlnFHkq1gm7o_Q=.3541ed34-e268-4ebc-9e85-14f10893bd39@github.com>

On Fri, 18 Oct 2024 03:54:40 GMT, John R Rose <jrose at openjdk.org> wrote:

> Happily, that day has come.

Yes, feeling happy!    I have been waiting to get rid of this last piece!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21571#issuecomment-2422885117

From mchung at openjdk.org  Fri Oct 18 17:21:43 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 18 Oct 2024 17:21:43 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
 <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
 <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>
Message-ID: <7mobQmaGqJ4uzc1XAy6LK6nNvlbVtpRByiay6g538vs=.a51a975a-2dac-4685-a41e-61d28ded59ae@github.com>

On Fri, 18 Oct 2024 16:54:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Oh that's a good find.  Maybe we should write a test for this, if as I assume there isn't one already.
>> Edit: not with this RFE, just in general.
>
>> // If the loader is not the boot loader then throw an exception if its
>> // superclass is in package jdk.internal.reflect
> 
> This will never happen.   `jdk.internal.reflect` is a non-exported package in `java.base` module.  If another module `M` defines a class whose superclass is in `jdk.internal.reflect` package, `java.base` must export `jdk.internal.reflect` package to `M` for access.   Otherwise, it will fail the super access check, as done in the check below this deleted code.
> 
> 
> Reflection::VerifyClassAccessResults vca_result =
>      Reflection::verify_class_access(this_klass, InstanceKlass::cast(super), false);

`test/hotspot/jtreg/runtime/AccessCheckSuper.java` is one test that fails the super class access check.  @lfoltan may know whether there are more tests besides this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1806804666

From jlu at openjdk.org  Fri Oct 18 17:44:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 18 Oct 2024 17:44:41 GMT
Subject: Integrated: 8340488: Clarify LocaleServiceProvider deployment on
 application module path
In-Reply-To: <8_f0tTi0mlYkIlVcvmQdnvp2W8S_tgcV-ZC5sodPC1U=.b8dff2ab-b8a6-457f-901d-0bea567a65fb@github.com>
References: <8_f0tTi0mlYkIlVcvmQdnvp2W8S_tgcV-ZC5sodPC1U=.b8dff2ab-b8a6-457f-901d-0bea567a65fb@github.com>
Message-ID: <eUSRpM03YIjYopXedOfe2nf7rPsNdo0b7Ki06cIBVRU=.5aaa01bf-7993-4de1-8ade-15e4845f5b33@github.com>

On Tue, 1 Oct 2024 17:28:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8341285) which clarifies that a Locale sensitive service provider can be deployed as a module.
> 
> This mainly follows the same format as the work done for [JDK-8340404](https://bugs.openjdk.org/browse/JDK-8340404), by providing a brief example, and pointing to the Deploying Service Providers section under ServiceLoader.
> 
> There is no test added, since there already exists java.text tests that deploy SPIs as a module.

This pull request has now been integrated.

Changeset: 07840113
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/078401134a97a13a96e12aa23e3481c59f3669ed
Stats:     30 lines in 1 file changed: 17 ins; 0 del; 13 mod

8340488: Clarify LocaleServiceProvider deployment on application module path

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21294

From heidinga at openjdk.org  Fri Oct 18 17:49:49 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 18 Oct 2024 17:49:49 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <TDRbhild6qu2VnOoDiur2r1dnjBVcssG5sa5xGwdeTQ=.efff346b-62b3-411b-baf3-35f452227fe3@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
 <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
 <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>
 <TDRbhild6qu2VnOoDiur2r1dnjBVcssG5sa5xGwdeTQ=.efff346b-62b3-411b-baf3-35f452227fe3@github.com>
Message-ID: <-864yF5rSsyoQ2WvB1ftDib87vZIE7LkHodH4yYMqB4=.649be68d-c6b6-40c3-a87f-4b5f0d8f641d@github.com>

On Fri, 18 Oct 2024 15:33:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I looked at the InnerClassLambdaMetaFactory and it only generates MHs.Lookup.ClassOption::STRONG classes that live as long as their corresponding loaders.  Given that, do we want an assert here that we are only dealing with strong hidden classes?  ie: `assert(ik->is_hidden() && !ik->is_non_strong_hidden());`
>
> This is correct for the LMF, but I think we are using weak hidden classes in string concatenation.

I just confirmed - the `InlineHiddenClassStrategy` in j.l.i.StringConcatFactory uses weak hidden classes.  It looks like there are two possible strategies though, and the InlineHiddenClassStrategy is only used if the MH strategy fails (more parameters than the high arity threshold)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1806833155

From jvos at openjdk.org  Fri Oct 18 18:26:44 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 18 Oct 2024 18:26:44 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <iP9XRtTeh8wPBqtj-o6JGhHkRqZTia-qt9ghVH0E0Iw=.31a75e2b-b453-4e8f-956d-2ce6c86a39ac@github.com>

On Tue, 15 Oct 2024 20:22:52 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:
> 
>   Don't hardcode server variant

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) )

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1806868617

From mullan at openjdk.org  Fri Oct 18 19:03:30 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:03:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@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 97 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
 - Sanitize the class descriptions of DelegationPermission and ServicePermission
   by removing text that refers to granting permissions, but avoid changes that
   affect the API specification, such as the description and format of input
   parameters.
 - Restored methods in RMIConnection to throw SecurityExceptions again but
   with adjusted text that avoids the word "permission".
 - Add text to class description of MBeanServer stating that implementations
   may throw SecurityException if authorization doesn't allow access to resource.
 - Restore text about needing permissions from the desktop environment in the
   getPixelColor and createScreenCapture methods.
 - Add api note to getClassContext to use StackWalker instead and
   add DROP_METHOD_INFO option to StackWalker.
 - Change checkAccess() methods to be no-ops, rather than throwing
   SecurityException.
 - Merge
 - Merge
 - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=01
  Stats: 63792 lines in 1825 files changed: 932 ins; 59211 del; 3649 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 naoto at openjdk.org  Fri Oct 18 19:05:48 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 18 Oct 2024 19:05:48 GMT
Subject: RFR: 8340554: Improve MessageFormat readObject checks
In-Reply-To: <0hSlYistdp3kSZMl2Frm65PSONFmtwpkx0EcJb_x1-E=.8f597ec0-df3c-499b-a555-92ede1bb1cfb@github.com>
References: <0hSlYistdp3kSZMl2Frm65PSONFmtwpkx0EcJb_x1-E=.8f597ec0-df3c-499b-a555-92ede1bb1cfb@github.com>
Message-ID: <mwXfsFYut26HOyHWZ3z2qOKUF3Cric0cmTakd2FTlY8=.c7714608-1d36-46c2-ade2-bd2d102646e1@github.com>

On Thu, 17 Oct 2024 20:14:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves the readObject logic for _j.text.MessageFormat_.
> 
> No offset should be larger than the pattern length. We already ensure the offsets when consumed backwards are equal/descending. The existing first/initial check was off by 1 since it was checking against the pattern length + 1; (see L2040 and L2043).
> 
> Please see the JBS issue for further info and other test details.

LGTM

test/jdk/java/text/Format/MessageFormat/SerializationTest.java line 79:

> 77:                 new MessageFormat("X{0}"),
> 78:                 // Offset 1 under pattern length (variation)
> 79:                 new MessageFormat("X{0}X")

Nit: "(variation)" may not be needed

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21570#pullrequestreview-2378800482
PR Review Comment: https://git.openjdk.org/jdk/pull/21570#discussion_r1806915646

From eirbjo at openjdk.org  Fri Oct 18 19:07:41 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 19:07:41 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v5]
In-Reply-To: <tEtQyCOVbt4DwC_1JKu1jnmhODpzsouGgABFPu721Mw=.0ddec8cb-1c51-4a2e-a498-946cbde45cdc@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <tEtQyCOVbt4DwC_1JKu1jnmhODpzsouGgABFPu721Mw=.0ddec8cb-1c51-4a2e-a498-946cbde45cdc@github.com>
Message-ID: <cbeJK_a5BUtkoz5vbFWMdtOMT5Ib2Rjk3Aoho5Tkfq0=.6bf1c9a0-225a-453f-b184-62593320368c@github.com>

On Fri, 18 Oct 2024 14:02:09 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR feedback

A few more nits, mainly focusing on the test for ZipEntry validation.

src/java.base/share/classes/java/util/zip/ZipEntry.java line 528:

> 526:      * extra field data, the {@linkplain #getName() entry name},
> 527:      * the {@linkplain #getComment() entry comment}, and the
> 528:      * {@linkplain #CENHDR CEN Header size}, exceeds 65,535 bytes.

Is the comma before "exceeds" intentional? Question also applies to `setComment`. The constructor does not have a comma at this position.
 
Suggestion:

     * {@linkplain #CENHDR CEN Header size} exceeds 65,535 bytes.

test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 28:

> 26:  * @summary Verify that ZipEntry(String), ZipEntry::setComment, and
> 27:  * ZipEntry::setExtra throws a IllegalArgumentException when the
> 28:  * length of the field exceeds 65,489 bytes

The summary seems slightly wrong now:

Suggestion:

 * combined length of the CEN header fields exceeds 65,489 bytes

test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 93:

> 91:         boolean expectException = length > MAX_NAME_COMMENT_EXTRA_SIZE;
> 92:         ZipEntry zipEntry = new ZipEntry(ENTRY_NAME);
> 93:         String comment = new String(bytes, StandardCharsets.UTF_8);

Could this be just?


String comment = "a".repeat(length);


Applies to the name test method as well.

test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 96:

> 94:         System.out.printf("Comment Len= %s, exception: %s%n", comment.length(), expectException);
> 95:         // The comment length will trigger the IllegalArgumentException
> 96:         if (expectException) {

Should there be an `else` here which sets the comment successfully?

This applies to all three tests methods.

test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 112:

> 110:             MAX_FIELD_LEN_MINUS_ENTRY_NAME,
> 111:             MAX_FIELD_LEN_MINUS_ENTRY_NAME - 1})
> 112:     void setNameLengthTest(int length) {

Perhaps just 'nameLengthTest', as this does not test a setter.

Suggestion:

    void nameLengthTest(int length) {

test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 135:

> 133:             MAX_FIELD_LEN_MINUS_ENTRY_NAME - 1})
> 134:     void setExtraLengthTest(int length) {
> 135:         final byte[] bytes = new byte[length];

I think the purpose of this test may be clearer if the construction of the extra byte array was extracted as a separate method. (The exact contents seems irrelevant as longs as its well-formed)

-------------

PR Review: https://git.openjdk.org/jdk/pull/21544#pullrequestreview-2378758933
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806890025
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806915381
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806900459
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806899076
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806905208
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806902819

From jlu at openjdk.org  Fri Oct 18 19:39:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 18 Oct 2024 19:39:52 GMT
Subject: RFR: 8340554: Improve MessageFormat readObject checks [v2]
In-Reply-To: <0hSlYistdp3kSZMl2Frm65PSONFmtwpkx0EcJb_x1-E=.8f597ec0-df3c-499b-a555-92ede1bb1cfb@github.com>
References: <0hSlYistdp3kSZMl2Frm65PSONFmtwpkx0EcJb_x1-E=.8f597ec0-df3c-499b-a555-92ede1bb1cfb@github.com>
Message-ID: <B6ZSy_Z5YC4sCTUm5CiwA6t7dWil93bGB4dsR47ctd8=.382b49d9-23a4-4a4f-8fd9-6916cbb9eb7d@github.com>

> Please review this PR which improves the readObject logic for _j.text.MessageFormat_.
> 
> No offset should be larger than the pattern length. We already ensure the offsets when consumed backwards are equal/descending. The existing first/initial check was off by 1 since it was checking against the pattern length + 1; (see L2040 and L2043).
> 
> Please see the JBS issue for further info and other test details.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review: clarify test comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21570/files
  - new: https://git.openjdk.org/jdk/pull/21570/files/dc3e952e..3730d628

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21570&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21570&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21570/head:pull/21570

PR: https://git.openjdk.org/jdk/pull/21570

From pchilanomate at openjdk.org  Fri Oct 18 19:41:27 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 18 Oct 2024 19:41:27 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads without
 Pinning
Message-ID: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@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:
 - Add PPC64 support
 - Test changes + JFR Updates + Library code changes
 - Allow virtual threads to unmount when blocked on Object.wait()
 - Allow virtual threads to unmount when blocked on synchronized
 - Allow virtual threads to unmount while holding monitors

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: 9459 lines in 242 files changed: 6942 ins; 1400 del; 1117 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 dholmes at openjdk.org  Fri Oct 18 19:41:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Oct 2024 19:41:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
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: <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@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/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?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805616004

From pchilanomate at openjdk.org  Fri Oct 18 19:41:28 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 18 Oct 2024 19:41:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
Message-ID: <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>

On Fri, 18 Oct 2024 00:09:59 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/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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805830255

From mullan at openjdk.org  Fri Oct 18 19:46:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
 <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
 <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>
Message-ID: <WQXBnhvSCgaSLXJytauYL7d7V9avIZVl75sej33nL0o=.82c6cfc9-a4fd-4b44-84f1-0a268a501d04@github.com>

On Thu, 17 Oct 2024 05:54:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.
>
> Okay, it already has `@see StackWalker`. My guess is that anything extending SM to call getClassContext is very old code. If that old code is compiled with JDK 17+ then they should get a warning. In any case, we replaced the implementation to use StackWalker so getClassContext will continue to work until the SM class is removed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/7ea65a6febd18ad8f8fa99cfbb8687e761558594

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806946629

From mullan at openjdk.org  Fri Oct 18 19:46:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
 <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
 <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>
Message-ID: <uqSjjeE7SYkvbhHNrZhbu1LjbFxWuU7ZJDWMAjWf_g0=.801e961d-5085-48d8-9bff-0029b1459e94@github.com>

On Wed, 16 Oct 2024 20:42:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.
>
> Phil, if you have better wording for the `@throws SecurityException` of these methods, let me know; otherwise I will restore the paragraph above and below and keep the current text for `SecurityException` the same as it is now.

I restored the text in https://github.com/openjdk/jdk/pull/21498/commits/adf5ed789b0437fa57c87f29e6a4e6b6f7f0c92b. I've left the `@throws SecurityException` text the same, but let me know if you want that changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806948352

From mullan at openjdk.org  Fri Oct 18 19:46:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
 <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
 <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>
Message-ID: <YpVEi_vehntFxBVQBqfYUlJsU5xAAEphz2giQrbbHeQ=.3094111c-c59c-45b2-a13e-140c8b3d6ad3@github.com>

On Tue, 15 Oct 2024 17:01:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
>> 
>> It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.
>> 
>> These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).
>> 
>> Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.
>
> I see your point now. We have strived to preserve compatibility with libraries that follow well known code patterns as described in the JEP, so I will discuss this with others who are more familiar with the compatibility risk of making this change.

I have changed `LogManager.checkAccess`, `Thread.checkAccess`, `ThreadGroup.checkAccess` to always do nothing. See the fixes in https://github.com/openjdk/jdk/pull/21498/commits/2ebb6de50194770658462507cee28b785fb30dbd and https://github.com/openjdk/jdk/pull/21498/commits/16e17b89b3dbce4f49706c032c315977dd54c315.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806950866

From mullan at openjdk.org  Fri Oct 18 19:56:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <W8LF9xitgnrJ0GXvQ2clisM9wQDS32sfJ_1w3xFvbTo=.5391529e-f6b5-40fd-a829-9803c0fdb206@github.com>

On Tue, 15 Oct 2024 14:50:54 GMT, Daniel Fuchs <dfuchs 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 159:
> 
>> 157:      * is specified for the MBean.
>> 158:      * @throws IOException if a general communication exception occurred.
>> 159:      * @throws UnsupportedOperationException if {@code delegationSubject} is non-null.
> 
> Maybe we should revert those changes, or word them differently. AFAIU, is is still possible for a JMXConnectorServer to implement coarse grained authorization by setting up an `MBeanServerAccessController`, and in fact, the default JMX Agent does that. The JDK has a built-in implementation of `MBeanServerAccessController`,  `MBeanServerFileAccessController`, which will throw `SecurityException` if access is denied by the `MBeanServerFileAccessController`. I believe this will result in the `RMIConnection` throwing `SecurityException` if the operation is denied by the `MBeanServerAccessController`.
> 
> So I believe - in all methods here and in `RMIConnectionImpl`, we should leave the door open for `SecurityException` to get thrown.
> 
> An alternative could be to cover that use case with a blanket statement, here, in `RMIConnectionImpl`, in `MBeanServer`, and in `MBeanServerConnection`.

I restored the changes to `RMIConnection` to throw `SecurityException` but adjusted the text to say "is not authorized" instead of "does not have permission". See https://github.com/openjdk/jdk/pull/21498/commits/86ff71461ef1d695c02497626facda63c496a287.

As we discussed offline, I also added a sentence to the `MBeanServer` class description to state that it and its subclasses may throw `SecurityException`s if the implementation doesn't authorize access to the underlying resource: https://github.com/openjdk/jdk/pull/21498/commits/44432e56a91a992150ee873e81282d1fe21e69ea.

> src/java.management/share/classes/javax/management/remote/JMXAuthenticator.java line 67:
> 
>> 65:      */
>> 66:     public Subject authenticate(Object credentials);
>> 67: }
> 
> Should this be reverted? Authentication has not been removed.

Yes. See the fix in https://github.com/openjdk/jdk/pull/21498/commits/23a43e0d90aff8754909785f582ba0666046cf6c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806952922
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806953524

From mullan at openjdk.org  Fri Oct 18 19:56:18 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:18 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>
Message-ID: <hOWAuNpI0Pigr9zYPACJJ68_-Q6uBQZuDWDD322bfg8=.ffe44b98-01a9-4125-90dc-318e48fc87b1@github.com>

On Tue, 15 Oct 2024 22:14:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:
>> 
>>> 223:      */
>>> 224:     public static JMXConnector connect(JMXServiceURL serviceURL)
>>> 225:             throws IOException {
>> 
>> I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.
>
> Yes, good catches, I will revert some of these JMX methods that can also throw SecurityExceptions for non-SM reasons.

Yes, see the fix in https://github.com/openjdk/jdk/pull/21498/commits/23a43e0d90aff8754909785f582ba0666046cf6c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806953911

From mullan at openjdk.org  Fri Oct 18 19:56:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
 <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
Message-ID: <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>

On Thu, 17 Oct 2024 17:59:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> All JGSS permission classes follow the same style:
>> 
>> In `javax.security.auth.kerberos.DelegationPermission`:
>> 
>>  * This class is used to restrict the usage of the Kerberos
>>  * delegation model, ie: forwardable and proxiable tickets.
>>  ```
>> In `javax.security.auth.kerberos.ServicePermission`:
>> 
>>  * This class is used to protect Kerberos services and the
>>  * credentials necessary to access those services. There is a one to
>> 
>> (Updated)
>
> I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.

See the changes I made in https://github.com/openjdk/jdk/pull/21498/commits/9dd59a12e984c347a34a25e6fd820340b1e12505. Sometimes it is difficult to remove all text about granting the permission, which is why we added the API note in all Permission subclasses stating that the permission can no longer be used to protect resources.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806957907

From lancea at openjdk.org  Fri Oct 18 19:59:37 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 19:59:37 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v6]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <tur9qCKIcZOW3I5ae0Zfm_4r4swKlGOdVEB31EIajZE=.e0ba5c52-26a7-4da9-a4a6-85eec0283707@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Address test cleanup input

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/68e0dcb5..76b7d1ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=04-05

  Stats: 44 lines in 2 files changed: 23 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From lancea at openjdk.org  Fri Oct 18 19:59:38 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 19:59:38 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v5]
In-Reply-To: <cbeJK_a5BUtkoz5vbFWMdtOMT5Ib2Rjk3Aoho5Tkfq0=.6bf1c9a0-225a-453f-b184-62593320368c@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <tEtQyCOVbt4DwC_1JKu1jnmhODpzsouGgABFPu721Mw=.0ddec8cb-1c51-4a2e-a498-946cbde45cdc@github.com>
 <cbeJK_a5BUtkoz5vbFWMdtOMT5Ib2Rjk3Aoho5Tkfq0=.6bf1c9a0-225a-453f-b184-62593320368c@github.com>
Message-ID: <q7loadO3YF2cC7VvcZZpqg0g5RCHZjFIZB-BUYqpG8o=.ce4d45ae-b432-4fa6-a2f5-495df5f0b345@github.com>

On Fri, 18 Oct 2024 18:40:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address PR feedback
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 528:
> 
>> 526:      * extra field data, the {@linkplain #getName() entry name},
>> 527:      * the {@linkplain #getComment() entry comment}, and the
>> 528:      * {@linkplain #CENHDR CEN Header size}, exceeds 65,535 bytes.
> 
> Is the comma before "exceeds" intentional? Question also applies to `setComment`. The constructor does not have a comma at this position.
>  
> Suggestion:
> 
>      * {@linkplain #CENHDR CEN Header size} exceeds 65,535 bytes.

removed

> test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 28:
> 
>> 26:  * @summary Verify that ZipEntry(String), ZipEntry::setComment, and
>> 27:  * ZipEntry::setExtra throws a IllegalArgumentException when the
>> 28:  * length of the field exceeds 65,489 bytes
> 
> The summary seems slightly wrong now:
> 
> Suggestion:
> 
>  * combined length of the CEN header fields exceeds 65,489 bytes

updated

> test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 93:
> 
>> 91:         boolean expectException = length > MAX_NAME_COMMENT_EXTRA_SIZE;
>> 92:         ZipEntry zipEntry = new ZipEntry(ENTRY_NAME);
>> 93:         String comment = new String(bytes, StandardCharsets.UTF_8);
> 
> Could this be just?
> 
> 
> String comment = "a".repeat(length);
> 
> 
> Applies to the name test method as well.

sure done

> test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 96:
> 
>> 94:         System.out.printf("Comment Len= %s, exception: %s%n", comment.length(), expectException);
>> 95:         // The comment length will trigger the IllegalArgumentException
>> 96:         if (expectException) {
> 
> Should there be an `else` here which sets the comment successfully?
> 
> This applies to all three tests methods.

done

> test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 112:
> 
>> 110:             MAX_FIELD_LEN_MINUS_ENTRY_NAME,
>> 111:             MAX_FIELD_LEN_MINUS_ENTRY_NAME - 1})
>> 112:     void setNameLengthTest(int length) {
> 
> Perhaps just 'nameLengthTest', as this does not test a setter.
> 
> Suggestion:
> 
>     void nameLengthTest(int length) {

sure done

> test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 135:
> 
>> 133:             MAX_FIELD_LEN_MINUS_ENTRY_NAME - 1})
>> 134:     void setExtraLengthTest(int length) {
>> 135:         final byte[] bytes = new byte[length];
> 
> I think the purpose of this test may be clearer if the construction of the extra byte array was extracted as a separate method. (The exact contents seems irrelevant as longs as its well-formed)

Sure, done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806961065
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806959754
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806960501
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806960667
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806960010
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806960336

From lancea at openjdk.org  Fri Oct 18 20:06:14 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 20:06:14 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v7]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <QNklQ93k5S2smg89mT0OMplb5Xl-HT2erUloHQTLLe4=.27624f4c-0a8c-4871-bfb8-a6a38a5e3a0a@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  change field -> fields

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/76b7d1ad..028af01c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From iklam at openjdk.org  Fri Oct 18 20:09:04 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 20:09:04 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Added ClaimMetadataVisitingOopIterateClosure::assert_is_pending_aot_linked_class()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/030cac23..3f094645

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=08-09

  Stats: 96 lines in 5 files changed: 88 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Fri Oct 18 20:11:24 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 18 Oct 2024 20:11:24 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <Lt-egmoFeE5x34ODYPIT288Y43gj6mehak4PUyvgsT8=.621acc0f-5a75-4e53-ae0b-805968469f99@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
 <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>
 <Lt-egmoFeE5x34ODYPIT288Y43gj6mehak4PUyvgsT8=.621acc0f-5a75-4e53-ae0b-805968469f99@github.com>
Message-ID: <0psOa7CmTMhsD-d_8aQrWvhf6nqqN1WDW336YmXVSUQ=.b7e6a508-6d80-4c6d-a0dd-0dffcce715b9@github.com>

On Wed, 16 Oct 2024 15:58:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Here's the call stack if I remove the "if" check on line 49. It can be reproduced with test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BulkLoaderTest.java from the PR repo.
>> 
>> 
>> 10 javaSignalHandler (sig=11, info=0x7ffff428fdb0, context=0x7ffff428fc80)
>> 12 Atomic::PlatformLoad::operator() (this=0x7ffff429097f, dest=0x28)
>> 13 Atomic::LoadImpl, void>::operator() (this=0x7ffff42909af, dest=0x28)
>> 14 Atomic::load (dest=0x28)
>> 15 ClassLoaderData::try_claim (this=0x0, claim=4)
>> 16 ClassLoaderData::oops_do (this=0x0, f=0x7fff6c014c88, claim_value=4, clear_mod_oops=false)
>> 17 ClaimMetadataVisitingOopIterateClosure::do_cld (this=0x7fff6c014c88, cld=0x0)
>> 18 ClaimMetadataVisitingOopIterateClosure::do_klass (this=0x7fff6c014c88, k=0x7fff763655d8)
>> 19 call_do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
>> 20 Devirtualizer::do_klass (closure=0x7fff6c014c88, k=0x7fff763655d8)
>> 21 InstanceKlass::oop_oop_iterate (closure=0x7fff6c014c88, obj=0xfffd72a0, this=0x7fff763655d8)
>> 22 OopOopIterateDispatch::Table::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, k=0x7fff763655d8)
>> 23 OopIteratorClosureDispatch::oop_oop_iterate (cl=0x7fff6c014c88, obj=0xfffd72a0, klass=0x7fff763655d8)
>> 24 oopDesc::oop_iterate (this=0xfffd72a0, cl=0x7fff6c014c88)
>> 25 G1FullGCMarker::follow_object (this=0x7fff6c014630, obj=0xfffd72a0)
>> 26 G1FullGCMarker::publish_and_drain_oop_tasks (this=0x7fff6c014630)
>> 27 G1FullGCMarker::follow_marking_stacks (this=0x7fff6c014630)
>> 28 G1FullGCMarker::complete_marking (this=0x7fff6c014630, oop_stacks=0x7fffd445c6b8, array_stacks=0x7fffd445c6d0, terminator=0x7fffd445c190)
>> 29 G1FullGCMarkTask::work (this=0x7fffd445c030, worker_id=0)
>> 30 WorkerTaskDispatcher::worker_run_task (this=0x7ffff008b9b8)
>> 31 WorkerThread::run (this=0x7ffff008bac0)
>> 
>> 
>> This is in a GC triggered by here (with -XX:VerifyArchivedFields=2).
>> 
>> 
>> void HeapShared::init_archived_fields_for(Klass* k, 
>>      const ArchivedKlassSubGraphInfoRecord* record) {
>>   verify_the_heap(k, "before");
>> 
>> 
>> At frame 18:
>> 
>> 
>> #18 0x00007ffff58505d1 in ClaimMetadataVisitingOopIterateClosure::do_klass 
>>     (this=0x7fff6c014c88, k=0x7fff763655d8)
>>     at src/hotspot/share/memory/iterator.inline.hpp:58
>> 58	  ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
>> (gdb) psym k->_name
>> $1 = 0x7fff765430be "BulkLoaderTestApp$$Lambda+0x800000013"
>> (gdb) p k->_class_loader_data
>> $2 = (ClassLoaderData *) 0x0
>> (gdb) p SystemDictionary::_java_system_loader 
>> $3 = {_obj...
>
> I filed [JDK-8342429](https://bugs.openjdk.org/browse/JDK-8342429) "Cache classes in loaded state" to address this properly.

I added an assert to limit the cases where the GCs can see null ClassLoaderData from a klass [3f09464](https://github.com/openjdk/jdk/pull/21143/commits/3f094645aae7ba420414121d20787d6a313ed4d0)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1806971597

From duke at openjdk.org  Fri Oct 18 20:16:43 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 18 Oct 2024 20:16:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <V9F38E82rWG3ydtcBhl-buCMyD8G8VnLPMZtODTvpC0=.d084324c-f851-4bb6-98f5-a392e65baa24@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Marked as reviewed by dmlloyd at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2378900585

From eirbjo at openjdk.org  Fri Oct 18 20:34:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 20:34:19 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v7]
In-Reply-To: <QNklQ93k5S2smg89mT0OMplb5Xl-HT2erUloHQTLLe4=.27624f4c-0a8c-4871-bfb8-a6a38a5e3a0a@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <QNklQ93k5S2smg89mT0OMplb5Xl-HT2erUloHQTLLe4=.27624f4c-0a8c-4871-bfb8-a6a38a5e3a0a@github.com>
Message-ID: <DD5rTvZvxdItfhw4cUzm0yXP4C5fTgt256vtL6zDEvk=.dce7e131-46dc-42bc-b060-f9d91b5065fa@github.com>

On Fri, 18 Oct 2024 20:06:14 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change field -> fields

A couple more suggestions for the ZipEntry test.

test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 28:

> 26:  * @summary Verify that ZipEntry(String), ZipEntry::setComment, and
> 27:  * ZipEntry::setExtra throws a IllegalArgumentException when the
> 28:  * combined length of the fields, including the size of the CEN Header,

A test where the combined length exceeds the limit, but no one field alone exceeds the limit would be a nice addition.

test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 60:

> 58:     static final short UNKNOWN_ZIP_TAG = (short) 0x9902;
> 59:     // ZIP file to be used by the tests
> 60:     static final Path ZIP_FILE = Path.of("ZipEntryFieldSize.zip");

Seems unused?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21544#pullrequestreview-2378915951
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806987734
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806985521

From bpb at openjdk.org  Fri Oct 18 20:39:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Oct 2024 20:39:59 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <X16uDSTJspQ3PJG1MtMzDCZm5eq_Htp0ogTFNar1F3E=.73295114-fa93-444c-a395-448e5a8af4a0@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
 <VmoppkexsNAUbzrh1JiPxMq6BEnLf1PuBwUq57U1t2M=.887bc204-6277-4288-a646-e5d998c75a50@github.com>
 <PRTuRxv2U5mku-JnMAHkvvQsSBo6zffjIupx8q77Xmc=.be0cea42-2c1f-4538-b6b4-386762e1ef62@github.com>
 <X16uDSTJspQ3PJG1MtMzDCZm5eq_Htp0ogTFNar1F3E=.73295114-fa93-444c-a395-448e5a8af4a0@github.com>
Message-ID: <yQX8-l2h73amOFJcGfCJl_raktUen-AMVfFLN0gXwNs=.79ec1b15-a38a-4905-a7f6-c27bc54be466@github.com>

On Fri, 18 Oct 2024 11:51:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Directory junctions may be semantically close but aren't quite the same thing so I fear that this will require effort to audit every I/O operation to flush out oddities.

Probably. The constrained case of true directory junctions, where the mount point target is specified as an absolute path to a directory, is in effect identical to a symbolic link whose target is a directory. I don't think anything beyond this should be considered.

> I also fear this will leading to weasel words in the specs.

I am sure that some sort of verbiage would be needed, in particular to clarify the limited scope of support.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2423196177

From lancea at openjdk.org  Fri Oct 18 20:43:20 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 20:43:20 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v8]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <ZxLt8tNIfQkXDtrBMFnkLSYQYO_Oiba64estTqliOUA=.7e5008dd-c2f3-487e-b4ce-a5bc33a17249@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused field

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/028af01c..7f334c87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=06-07

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From lancea at openjdk.org  Fri Oct 18 20:43:21 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 20:43:21 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v7]
In-Reply-To: <DD5rTvZvxdItfhw4cUzm0yXP4C5fTgt256vtL6zDEvk=.dce7e131-46dc-42bc-b060-f9d91b5065fa@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <QNklQ93k5S2smg89mT0OMplb5Xl-HT2erUloHQTLLe4=.27624f4c-0a8c-4871-bfb8-a6a38a5e3a0a@github.com>
 <DD5rTvZvxdItfhw4cUzm0yXP4C5fTgt256vtL6zDEvk=.dce7e131-46dc-42bc-b060-f9d91b5065fa@github.com>
Message-ID: <_xA4X95i3ePSiNAFEKijUCO1l0mWinwuK8gfNtDZ1uE=.768e73d6-d0a7-49bf-9e56-32ee539ec7dc@github.com>

On Fri, 18 Oct 2024 20:29:00 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change field -> fields
>
> test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 28:
> 
>> 26:  * @summary Verify that ZipEntry(String), ZipEntry::setComment, and
>> 27:  * ZipEntry::setExtra throws a IllegalArgumentException when the
>> 28:  * combined length of the fields, including the size of the CEN Header,
> 
> A test where the combined length exceeds the limit, but no one field alone exceeds the limit would be a nice addition.

I am going to leat the comment as is

> test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 60:
> 
>> 58:     static final short UNKNOWN_ZIP_TAG = (short) 0x9902;
>> 59:     // ZIP file to be used by the tests
>> 60:     static final Path ZIP_FILE = Path.of("ZipEntryFieldSize.zip");
> 
> Seems unused?

Yes a holdover from the original version removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806995772
PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806996024

From eirbjo at openjdk.org  Fri Oct 18 20:45:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 18 Oct 2024 20:45:19 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v7]
In-Reply-To: <_xA4X95i3ePSiNAFEKijUCO1l0mWinwuK8gfNtDZ1uE=.768e73d6-d0a7-49bf-9e56-32ee539ec7dc@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <QNklQ93k5S2smg89mT0OMplb5Xl-HT2erUloHQTLLe4=.27624f4c-0a8c-4871-bfb8-a6a38a5e3a0a@github.com>
 <DD5rTvZvxdItfhw4cUzm0yXP4C5fTgt256vtL6zDEvk=.dce7e131-46dc-42bc-b060-f9d91b5065fa@github.com>
 <_xA4X95i3ePSiNAFEKijUCO1l0mWinwuK8gfNtDZ1uE=.768e73d6-d0a7-49bf-9e56-32ee539ec7dc@github.com>
Message-ID: <_AtxLH7pu7W7qQViieil4OOylZQo4fqBNEDogjnEvDw=.f5c62a77-bd4c-4000-af06-4af36d3d5960@github.com>

On Fri, 18 Oct 2024 20:38:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/util/zip/ZipEntry/MaxZipEntryFieldSizeTest.java line 28:
>> 
>>> 26:  * @summary Verify that ZipEntry(String), ZipEntry::setComment, and
>>> 27:  * ZipEntry::setExtra throws a IllegalArgumentException when the
>>> 28:  * combined length of the fields, including the size of the CEN Header,
>> 
>> A test where the combined length exceeds the limit, but no one field alone exceeds the limit would be a nice addition.
>
> I am going to leat the comment as is

Sorry, this was not to comment the summary, just pointing out that we have no test verifying the combined length exceeding the limit when each component alone does not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1806999256

From rriggs at openjdk.org  Fri Oct 18 20:48:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Oct 2024 20:48:38 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v2]
In-Reply-To: <pRwHfJTJTU64D5BdOB8ixl8W6Np6KBSnFe6uyObKRso=.1fa4b113-f5df-4db5-8dc7-ff4ae4be5f0e@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <pRwHfJTJTU64D5BdOB8ixl8W6Np6KBSnFe6uyObKRso=.1fa4b113-f5df-4db5-8dc7-ff4ae4be5f0e@github.com>
Message-ID: <4E2Bzc4y1NwpKahpKwT_k034ZLHRspzxb04n26klukA=.ae958072-bb35-443b-8afa-50d467204b7d@github.com>

On Thu, 17 Oct 2024 20:25:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit of re-org

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21569#pullrequestreview-2378940145

From kevinw at openjdk.org  Fri Oct 18 20:54:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 18 Oct 2024 20:54:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <AlbXwhSqJ6KlhPzDu_C7N1p84ZxgYsYImht8GW56D4k=.0283a056-f5ee-4650-b8c9-0df0aaee1797@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Thanks for updating the wording on the JMX/management classes, looks good.

src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java
No longer has any changes other than (C), so that should be reverted also. 8-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2423214468

From jlu at openjdk.org  Fri Oct 18 21:05:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 18 Oct 2024 21:05:18 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v4]
In-Reply-To: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
Message-ID: <7OSq5U0fGbrX7rrPjT7wMyNdWMOiKJBXDz7ld2im0Pc=.9e57fa0f-6b9e-4d2b-9b9c-f4ad60cb6b39@github.com>

> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
> 
> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  CSR review: More precise wording regarding 'this' impl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21554/files
  - new: https://git.openjdk.org/jdk/pull/21554/files/448c2453..c11344b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21554&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21554&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21554/head:pull/21554

PR: https://git.openjdk.org/jdk/pull/21554

From iris at openjdk.org  Fri Oct 18 21:10:52 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 18 Oct 2024 21:10:52 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v2]
In-Reply-To: <pRwHfJTJTU64D5BdOB8ixl8W6Np6KBSnFe6uyObKRso=.1fa4b113-f5df-4db5-8dc7-ff4ae4be5f0e@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <pRwHfJTJTU64D5BdOB8ixl8W6Np6KBSnFe6uyObKRso=.1fa4b113-f5df-4db5-8dc7-ff4ae4be5f0e@github.com>
Message-ID: <E3GrSfmZ4r7rj69pi_LR65EfXGf_O25C0PywS4FIPZo=.091218dd-508a-40dc-bec3-c233be56dc48@github.com>

On Thu, 17 Oct 2024 20:25:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit of re-org

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21569#pullrequestreview-2378968120

From bpb at openjdk.org  Fri Oct 18 21:17:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Oct 2024 21:17:53 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v2]
In-Reply-To: <IfwJXJ91c8FUaA_h6Z-dSbEt4Lmy8ExglYgjAi0ot4E=.8738e5d5-e940-4cd7-844d-2d7aab1273fa@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <WhriuVHqyLd3hhTJDrGfUSJoiP49Pj7DhRl5EBzraB4=.9d845655-67b8-45f9-9233-baab9dce533f@github.com>
 <_w2hvjFvNXQaRzeIxD30Fmcf5L2iJIVXx9fER9xtX6g=.fdfc4e09-6b9c-492e-8eec-0d13fd1e7481@github.com>
 <O6VgfF1ToPs21-OJ1suDrCgnMVXAr7BtoPNlbMwizbU=.079cb486-a4b8-423b-9db0-b546f9cdf4bd@github.com>
 <s8rlCXNr1Y5mrQu2J-Ec6zn0SeilcN-aSv_9CMeqMh8=.997ecee3-e683-421b-ae16-73bc994264ae@github.com>
 <IfwJXJ91c8FUaA_h6Z-dSbEt4Lmy8ExglYgjAi0ot4E=.8738e5d5-e940-4cd7-844d-2d7aab1273fa@github.com>
Message-ID: <feE8op1MKgKXJmy2qCLervlOeELvw-TaFogz_0KMkJA=.c825f86d-c005-488e-ada2-ccb5946e7c68@github.com>

On Fri, 18 Oct 2024 15:03:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I wonder if there is another special file that could be read to EOF to allow the methods be tested. Asking because the overrides have a code path we need to test.
>
> I need to investigate this. I might hold off integrating even thought it's approved until this is determined.

> I wonder if there is another special file that could be read to EOF to allow the methods be tested.

I think that this can done using a named pipe, at least on UNIX.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1807022434

From lancea at openjdk.org  Fri Oct 18 21:24:18 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 21:24:18 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v9]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <5WKheUkPA1lNoFQYpihqSYVVKt6sMdCy1wiCOXQfS08=.83b81451-cb11-4927-a1c8-ebec985bb786@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add Combined test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/7f334c87..a565193d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=07-08

  Stats: 25 lines in 1 file changed: 25 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From lancea at openjdk.org  Fri Oct 18 21:24:18 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 18 Oct 2024 21:24:18 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v7]
In-Reply-To: <_AtxLH7pu7W7qQViieil4OOylZQo4fqBNEDogjnEvDw=.f5c62a77-bd4c-4000-af06-4af36d3d5960@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <QNklQ93k5S2smg89mT0OMplb5Xl-HT2erUloHQTLLe4=.27624f4c-0a8c-4871-bfb8-a6a38a5e3a0a@github.com>
 <DD5rTvZvxdItfhw4cUzm0yXP4C5fTgt256vtL6zDEvk=.dce7e131-46dc-42bc-b060-f9d91b5065fa@github.com>
 <_xA4X95i3ePSiNAFEKijUCO1l0mWinwuK8gfNtDZ1uE=.768e73d6-d0a7-49bf-9e56-32ee539ec7dc@github.com>
 <_AtxLH7pu7W7qQViieil4OOylZQo4fqBNEDogjnEvDw=.f5c62a77-bd4c-4000-af06-4af36d3d5960@github.com>
Message-ID: <YS0zSmJ311zl1kq6zKCNIQwAR45DxQzuVo6CzbOZxRc=.5a7710b8-a628-42be-b889-a4dd51397734@github.com>

On Fri, 18 Oct 2024 20:42:47 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> I am going to leat the comment as is
>
> Sorry, this was not to comment the summary, just pointing out that we have no test verifying the combined length exceeding the limit when each component alone does not.

Thanks for the clarification.  Test added

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1807026034

From liach at openjdk.org  Fri Oct 18 21:30:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 18 Oct 2024 21:30:09 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <-864yF5rSsyoQ2WvB1ftDib87vZIE7LkHodH4yYMqB4=.649be68d-c6b6-40c3-a87f-4b5f0d8f641d@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
 <W05aOkr_DsZC7BUO4t36_dmsu2EAp-Qi1lc8nT4DklI=.e91a38d5-e750-44c9-a113-61c5df82905f@github.com>
 <u_F81taYnjCHp-Sbv0GzqUL-PbE8Vw3RrQ4d37vD57Y=.4c30e289-b6c0-41db-a50d-f66ccbd77804@github.com>
 <K-SnUXTTqRbwtkmZBO-j6tRXXlnGHggWKj1f-4jrotg=.75863b00-53c5-44a8-918b-52d9c8433dea@github.com>
 <TDRbhild6qu2VnOoDiur2r1dnjBVcssG5sa5xGwdeTQ=.efff346b-62b3-411b-baf3-35f452227fe3@github.com>
 <-864yF5rSsyoQ2WvB1ftDib87vZIE7LkHodH4yYMqB4=.649be68d-c6b6-40c3-a87f-4b5f0d8f641d@github.com>
Message-ID: <yLl7uO-EOSfSaMLP92N_D3fIzVvA1JXQQlTi5X6Wbqg=.57ac3948-6c40-45b1-aeff-1a15db841e1c@github.com>

On Fri, 18 Oct 2024 17:47:00 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> This is correct for the LMF, but I think we are using weak hidden classes in string concatenation.
>
> I just confirmed - the `InlineHiddenClassStrategy` in j.l.i.StringConcatFactory uses weak hidden classes.  It looks like there are two possible strategies though, and the InlineHiddenClassStrategy is only used if the MH strategy fails (more parameters than the high arity threshold)

Currently the high arity threshold is 0, meaning weak hidden classes are always used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1807029898

From darcy at openjdk.org  Fri Oct 18 21:36:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 18 Oct 2024 21:36:08 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v4]
In-Reply-To: <7OSq5U0fGbrX7rrPjT7wMyNdWMOiKJBXDz7ld2im0Pc=.9e57fa0f-6b9e-4d2b-9b9c-f4ad60cb6b39@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
 <7OSq5U0fGbrX7rrPjT7wMyNdWMOiKJBXDz7ld2im0Pc=.9e57fa0f-6b9e-4d2b-9b9c-f4ad60cb6b39@github.com>
Message-ID: <L_HJ5vnToVzZoD8-183fAcDp8Xc9oUdwMhmuzZEDuhk=.d30bd1e8-3289-451b-806e-bc95024f185c@github.com>

On Fri, 18 Oct 2024 21:05:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
>> 
>> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR review: More precise wording regarding 'this' impl

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21554#pullrequestreview-2378992573

From almatvee at openjdk.org  Fri Oct 18 21:40:50 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Oct 2024 21:40:50 GMT
Subject: RFR: 8342609: Bug in jpackage test helper
In-Reply-To: <l6DyfD0KC3hruoyIdozFp0iDlZktByR79zPG3ecxpug=.8b41340d-4e9a-4ac1-8389-f846af4e7642@github.com>
References: <l6DyfD0KC3hruoyIdozFp0iDlZktByR79zPG3ecxpug=.8b41340d-4e9a-4ac1-8389-f846af4e7642@github.com>
Message-ID: <tX06oZHMi41K6PrrlnF9LiPxSDlPlV9QBE1zijSGOdM=.bc5cd5f5-55b3-47ef-9a6a-acfb8102e06b@github.com>

On Fri, 18 Oct 2024 13:45:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> `Files.walk(root, 0)` returns the `root` itself and not the contents of the `root`.
> Replaced `Files.walk(root, 0)` with `Files.list(root)` to get a non-recursive listing of the `root` directory.

Looks good, but can you make issue title more descriptive of the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21582#issuecomment-2423266759

From naoto at openjdk.org  Fri Oct 18 21:43:49 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 18 Oct 2024 21:43:49 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v3]
In-Reply-To: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
Message-ID: <2SfZK99Gmi9-wuuAl6B4jrgc-QUeqbUaYbVmdVYibCY=.bc9fedbc-0ef1-471d-a3c0-4a8e913c4217@github.com>

> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Explicitly refer to `stdout.encoding`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21569/files
  - new: https://git.openjdk.org/jdk/pull/21569/files/581bed89..9000280b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21569/head:pull/21569

PR: https://git.openjdk.org/jdk/pull/21569

From swen at openjdk.org  Fri Oct 18 21:56:53 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Oct 2024 21:56:53 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>

> 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/2370f48a...457735c9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/ae054771..457735c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=18-19

  Stats: 90483 lines in 1658 files changed: 73190 ins; 9277 del; 8016 mod
  Patch: https://git.openjdk.org/jdk/pull/19626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19626/head:pull/19626

PR: https://git.openjdk.org/jdk/pull/19626

From almatvee at openjdk.org  Fri Oct 18 22:34:47 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 18 Oct 2024 22:34:47 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v4]
In-Reply-To: <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
 <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>
Message-ID: <eiWP2jceYwfDcNiLkjxyJJTVKJkfhf6jL78U8HxV_fs=.71542129-b823-479f-bfc8-dd62cd017e79@github.com>

On Fri, 18 Oct 2024 14:42:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make jpackage correctly handle the output directory (`--dest`) that is:
>>  - a subdirectory of the input directory;
>>  - the same as the input directory.
>> 
>> Make jpackage correctly handle temp directory (`--temp`) that is:
>>  - a subdirectory of the input directory.
>> 
>> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
>> 
>> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
>> 
>> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
>> 
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
>> 
>> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files.isSameFile() throws exception if a file doesn't exist

Maybe I am missing something, but I do not see where we handle following case:

- Make jpackage correctly handle the output directory (--dest) that is:
  - the same as the input directory.

Otherwise looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21550#issuecomment-2423325229

From iris at openjdk.org  Fri Oct 18 23:16:17 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 18 Oct 2024 23:16:17 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v4]
In-Reply-To: <7OSq5U0fGbrX7rrPjT7wMyNdWMOiKJBXDz7ld2im0Pc=.9e57fa0f-6b9e-4d2b-9b9c-f4ad60cb6b39@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
 <7OSq5U0fGbrX7rrPjT7wMyNdWMOiKJBXDz7ld2im0Pc=.9e57fa0f-6b9e-4d2b-9b9c-f4ad60cb6b39@github.com>
Message-ID: <5SvnLqTVFm7QyfQol1FfAoIWd5uks-NbnVq9tq832xQ=.be303ba9-f22d-40bb-8c56-2720f0f5a0e3@github.com>

On Fri, 18 Oct 2024 21:05:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
>> 
>> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR review: More precise wording regarding 'this' impl

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21554#pullrequestreview-2379070420

From swen at openjdk.org  Fri Oct 18 23:33:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 18 Oct 2024 23:33:17 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: <XxflQwYd-F5tMnmwozI8wHC8p5GwJisbT7zzwvP8w1o=.aea098d2-a98b-4bd7-80fd-37385fc91599@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/2cc7136e...457735c9

After PR 19970, the performance has been significantly improved. Below are the performance numbers for AMD CPU (x64)

## Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# pr 19626
git clone 58dae7888eceb1c61243f658b67c208e6c30f7f2
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"

# pr 19626 + 19970
git clone 457735c920aad822557e68e75ba1e76811c855a4
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"


## performance numbers


-Benchmark                             Mode  Cnt  Score   Error  Units (pr 19626)
-StringBuilders.appendWithNull8Latin1  avgt   15  8.316 ? 0.512  ns/op

+Benchmark                             Mode  Cnt  Score   Error  Units (pr 19626 + 19970)
+StringBuilders.appendWithNull8Latin1  avgt   15  5.891 ? 0.043  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2423368506

From swen at openjdk.org  Sat Oct 19 02:19:05 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 19 Oct 2024 02:19:05 GMT
Subject: RFR: 8342644: Optimize InvokerBytecodeGenerator for using ClassFile
 API
Message-ID: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>

Cache commonly used classDesc to avoid creating ReferenceClassDescImpl every time

-------------

Commit messages:
 - cache ClassDesc MH/BMH/DMH

Changes: https://git.openjdk.org/jdk/pull/21580/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21580&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342644
  Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21580/head:pull/21580

PR: https://git.openjdk.org/jdk/pull/21580

From liach at openjdk.org  Sat Oct 19 02:19:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 19 Oct 2024 02:19:06 GMT
Subject: RFR: 8342644: Optimize InvokerBytecodeGenerator for using
 ClassFile API
In-Reply-To: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
References: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
Message-ID: <4H1FE9CXyi0KYLRsdv4z-jZzcIv3IUhDzqRbUmHs3eI=.d8441ae8-b1bb-4c9b-82d0-c4edc3e3d287@github.com>

On Fri, 18 Oct 2024 10:01:59 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Cache commonly used classDesc to avoid creating ReferenceClassDescImpl every time

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 141:

> 139:             case "MH"  -> CD_MH;
> 140:             case "DMH" -> CD_DMH;
> 141:             case "BMH" -> CD_BMH;

I don't see where DMH and BMH are passed; only see NFI and LFI.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21580#discussion_r1806500425

From swen at openjdk.org  Sat Oct 19 02:19:06 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 19 Oct 2024 02:19:06 GMT
Subject: RFR: 8342644: Optimize InvokerBytecodeGenerator for using
 ClassFile API
In-Reply-To: <4H1FE9CXyi0KYLRsdv4z-jZzcIv3IUhDzqRbUmHs3eI=.d8441ae8-b1bb-4c9b-82d0-c4edc3e3d287@github.com>
References: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
 <4H1FE9CXyi0KYLRsdv4z-jZzcIv3IUhDzqRbUmHs3eI=.d8441ae8-b1bb-4c9b-82d0-c4edc3e3d287@github.com>
Message-ID: <SZHnbajMQU9RzQxFeLNWv9IrlWsDIabTsDUlPF6Yt9o=.411765fd-9377-428c-a5d5-3623c61c07c1@github.com>

On Fri, 18 Oct 2024 13:32:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Cache commonly used classDesc to avoid creating ReferenceClassDescImpl every time
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 141:
> 
>> 139:             case "MH"  -> CD_MH;
>> 140:             case "DMH" -> CD_DMH;
>> 141:             case "BMH" -> CD_BMH;
> 
> I don't see where DMH and BMH are passed; only see NFI and LFI.

This DMH is derived from invokerName, which comes from java.lang.invoke.LambdaForm.Kind#defaultLambdaName

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21580#discussion_r1807085957

From davidalayachew at gmail.com  Sat Oct 19 05:54:04 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 19 Oct 2024 01:54:04 -0400
Subject: Streams, parallelization, and OOME.
Message-ID: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>

Hello Core Libs Dev Team,

I have a file that I am streaming from a service, and I am trying to split
into multiple parts based on a certain attribute found on each line. I am
sending each part up to a different service.

I am using BufferedReader.lines(). However, I cannot read the whole file
into memory because it is larger than the amount of RAM that I have on the
machine. So, since I don't have access to Java 22's Preview Gatherers Fixed
Window, I used the iterator() method on my stream, wrapped that in another
iterator that can grab my batch size worth of data, then built a
spliterator from that that I then used to create a new stream. In short,
this wrapper iterator isn't Iterator<T>, it's Iterator<List<T>>.

When I ran this sequentially, everything worked well. However, my CPU was
low and we definitely have a performance problem -- our team needs this
number as fast as we can get. Plus, we had plenty of network bandwidth to
spare, so I had (imo) good reason to go use parallelism.

As soon as I turned on parallelism, the stream's behaviour changed
completely. Instead of fetching the batch and processing, it started
grabbing SEVERAL BATCHES and processing NONE OF THEM. Or at the very least,
it grabbed so many batches that it ran out of memory before it could get to
processing them.

To give some numbers, this is a 4 core machine. And we can safely hold
about 30-40 batches worth of data in memory before crashing. But again,
when running sequentially, this thing only grabs 1 batch, processes that
one batch, sends out the results, and then start the next one, all as
expected. I thought that adding parallelism would simply make it so that we
have this happening 4 or 8 times at once.

After a very long period of digging, I managed to find this link.

https://stackoverflow.com/questions/30825708/java-8-using-parallel-in-a-stream-causes-oom-error

Tagir Valeev gives an answer which doesn't go very deep into the "why" at
all. And the answer is more directed to the user's specific question as
opposed to solving this particular problem.

After digging through a bunch of other solutions (plus my own testing), it
seems that the answer is that the engine that does parallelization for
Streams tries to grab a large enough "buffer" before doing any parallel
processing. I could be wrong, and how large that buffer is? I have no idea.

Regardless, that's about where I gave up and went sequential, since the
clock was ticking.

But I still have a performance problem. How would one suggest going about
this in Java 8?

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/20241019/bf3c8cfe/attachment.htm>

From rotanolexandr842 at gmail.com  Sat Oct 19 11:12:30 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Sat, 19 Oct 2024 14:12:30 +0300
Subject: Streams, parallelization, and OOME.
In-Reply-To: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>
References: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>
Message-ID: <CAL5bRt9r3mXLHbTutSzZD6weinvm-DAV6_t8-DgfJp4FuniBWg@mail.gmail.com>

Hi David. I am not a core libs team but I guess I can have some clues :).

It is hard to tell without the code, but I assume that there are a few
layers to it.

1. Stalling. I would assume it is caused mostly by GC pauses taking too
long (forever) if GC does not have any computational powers to run on.
There is a fairly common GC-pauses related issue when database connection
interrupts with exception saying "Broken pipe", which under the hood is
caused by timeout of connection to database due to long GC pause when
running on low memory. I am not saying this is your case, but If I were to
guess I would assume that stall is caused by low memory.

2. Out of memory root cause may be too much splitting of your data source
input. You may try to limit it by modifying the behaviour of trySplit
method of your spliterator.

Alternatively, If you don't mind taking up some disk space, you can try to
stream data into file, save it, and then use memory-mapped buffers
(java.nio.MappedByteBuffer) to process accepted data. I am not sure this
will work, but memory-mapped files is a common tool to deal with operations
that cant fit into RAM.

Regards


On Sat, Oct 19, 2024 at 8:54?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Core Libs Dev Team,
>
> I have a file that I am streaming from a service, and I am trying to split
> into multiple parts based on a certain attribute found on each line. I am
> sending each part up to a different service.
>
> I am using BufferedReader.lines(). However, I cannot read the whole file
> into memory because it is larger than the amount of RAM that I have on the
> machine. So, since I don't have access to Java 22's Preview Gatherers Fixed
> Window, I used the iterator() method on my stream, wrapped that in another
> iterator that can grab my batch size worth of data, then built a
> spliterator from that that I then used to create a new stream. In short,
> this wrapper iterator isn't Iterator<T>, it's Iterator<List<T>>.
>
> When I ran this sequentially, everything worked well. However, my CPU was
> low and we definitely have a performance problem -- our team needs this
> number as fast as we can get. Plus, we had plenty of network bandwidth to
> spare, so I had (imo) good reason to go use parallelism.
>
> As soon as I turned on parallelism, the stream's behaviour changed
> completely. Instead of fetching the batch and processing, it started
> grabbing SEVERAL BATCHES and processing NONE OF THEM. Or at the very least,
> it grabbed so many batches that it ran out of memory before it could get to
> processing them.
>
> To give some numbers, this is a 4 core machine. And we can safely hold
> about 30-40 batches worth of data in memory before crashing. But again,
> when running sequentially, this thing only grabs 1 batch, processes that
> one batch, sends out the results, and then start the next one, all as
> expected. I thought that adding parallelism would simply make it so that we
> have this happening 4 or 8 times at once.
>
> After a very long period of digging, I managed to find this link.
>
>
> https://stackoverflow.com/questions/30825708/java-8-using-parallel-in-a-stream-causes-oom-error
>
> Tagir Valeev gives an answer which doesn't go very deep into the "why" at
> all. And the answer is more directed to the user's specific question as
> opposed to solving this particular problem.
>
> After digging through a bunch of other solutions (plus my own testing), it
> seems that the answer is that the engine that does parallelization for
> Streams tries to grab a large enough "buffer" before doing any parallel
> processing. I could be wrong, and how large that buffer is? I have no idea.
>
> Regardless, that's about where I gave up and went sequential, since the
> clock was ticking.
>
> But I still have a performance problem. How would one suggest going about
> this in Java 8?
>
> 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/20241019/001a6725/attachment.htm>

From alanb at openjdk.org  Sat Oct 19 11:55:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Oct 2024 11:55:52 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v3]
In-Reply-To: <2SfZK99Gmi9-wuuAl6B4jrgc-QUeqbUaYbVmdVYibCY=.bc9fedbc-0ef1-471d-a3c0-4a8e913c4217@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <2SfZK99Gmi9-wuuAl6B4jrgc-QUeqbUaYbVmdVYibCY=.bc9fedbc-0ef1-471d-a3c0-4a8e913c4217@github.com>
Message-ID: <Fdua2qIELjn-tPGA0ZR3Bob1ZM9LR2Jc3H6MPp1wJmY=.399017b6-b1af-4df2-80e5-68122dc7016b@github.com>

On Fri, 18 Oct 2024 21:43:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly refer to `stdout.encoding`

src/java.base/share/classes/java/io/Console.java line 584:

> 582:      * The returned charset corresponds to the input and output source
> 583:      * (e.g., keyboard and/or display) specified by the host environment or user,
> 584:      * which defaults to the one based on {@link System##stdout.encoding stdtout.encoding}.

In System.getProperties, this is specified for as the encoding for System.out. That may need to be expanded to say Console too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21569#discussion_r1807215667

From duke at openjdk.org  Sat Oct 19 11:55:52 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 19 Oct 2024 11:55:52 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <ogLSKo5cyl9xBx_VTqa7_2r2JjJvhC-mDC4iwyRHEVM=.402df357-94bd-43b9-b1c7-9e172e8de536@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Does?this?mean that?[JDK?4486457] will?finally be?able to?be?made?public?

[JDK?4486457]: https://bugs.openjdk.org/browse/JDK-4486457

-------------

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2379243219

From duke at openjdk.org  Sat Oct 19 11:55:52 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 19 Oct 2024 11:55:52 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <7mobQmaGqJ4uzc1XAy6LK6nNvlbVtpRByiay6g538vs=.a51a975a-2dac-4685-a41e-61d28ded59ae@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
 <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
 <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>
 <7mobQmaGqJ4uzc1XAy6LK6nNvlbVtpRByiay6g538vs=.a51a975a-2dac-4685-a41e-61d28ded59ae@github.com>
Message-ID: <ETK0SJ0qK5YYVRRyBZ4w8IZoURUghpOo88OlRNPi9mg=.612750f1-232b-49d4-8b0d-cf56a3f4049a@github.com>

On Fri, 18 Oct 2024 17:18:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> // If the loader is not the boot loader then throw an exception if its
>>> // superclass is in package jdk.internal.reflect
>> 
>> This should not be needed.   `jdk.internal.reflect` is a non-exported package in `java.base` module.  If another module `M` defines a class whose superclass is in `jdk.internal.reflect` package, `java.base` must export `jdk.internal.reflect` package to `M` for access.   Otherwise, it will fail the super access check, as done in the check below this deleted code.
>> 
>> 
>> Reflection::VerifyClassAccessResults vca_result =
>>      Reflection::verify_class_access(this_klass, InstanceKlass::cast(super), false);
>
> `test/hotspot/jtreg/runtime/AccessCheckSuper.java` is one test that fails the super class access check.  @lfoltan may know whether there are more tests besides this one.

This?code was?necessary back?when this?was the?`sun.reflect` package and?it?was not?able to?be?encapsulated (before?modules) to?prevent untrusted class?loaders from?leaking the?`MagicAccessorImpl` class?hierarchy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1807206230

From asemenyuk at openjdk.org  Sat Oct 19 11:56:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 19 Oct 2024 11:56:03 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v4]
In-Reply-To: <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
 <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>
Message-ID: <wXkZ0vHdmKWwGbsvCiCXfUX5du_gl9plfU1HNS-wCPM=.5433d6d4-4d43-4f02-b7f6-195fc80ac2f0@github.com>

On Fri, 18 Oct 2024 14:42:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make jpackage correctly handle the output directory (`--dest`) that is:
>>  - a subdirectory of the input directory;
>>  - the same as the input directory.
>> 
>> Make jpackage correctly handle temp directory (`--temp`) that is:
>>  - a subdirectory of the input directory.
>> 
>> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
>> 
>> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
>> 
>> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
>> 
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
>> 
>> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files.isSameFile() throws exception if a file doesn't exist

`InOutPathTest.outputDirSameAsInputDir()` configures jpackage to have the same value of `--dest` and `--input` parameters.
Fragment of test log:


[15:41:50.630] TRACE: exec: Execute [jpackage.exe --input .\test.096186e0\input --dest .\test.096186e0\input --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello --win-console --runtime-image .\test.096186e0\fake_runtime -J-Djlink.debug=true --verbose](18); inherit I/O...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21550#issuecomment-2423773355

From dl at openjdk.org  Sat Oct 19 11:56:29 2024
From: dl at openjdk.org (Doug Lea)
Date: Sat, 19 Oct 2024 11:56:29 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v2]
In-Reply-To: <nW1Z31_EhxURpGbD-0Y1aUHtyJR6bJNXK4yeB4hVX-w=.b7bb566d-f50c-4c15-8958-1ba5f4c892b2@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <9kT3vT460jQ155Pldue5LwW94UyCI3nJICr32EUFpjE=.0ac299b6-36a9-4067-b222-2ad068ab739b@github.com>
 <nW1Z31_EhxURpGbD-0Y1aUHtyJR6bJNXK4yeB4hVX-w=.b7bb566d-f50c-4c15-8958-1ba5f4c892b2@github.com>
Message-ID: <KX_M2Ixcf3j9Pf7zgpkaE40iOA1ENjPvXcFWEMzv0qY=.e0f333a9-5c96-4ed9-9a44-5571f147f94d@github.com>

On Fri, 18 Oct 2024 15:47:16 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Better disinguish need for exhaustive scans
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2006:
> 
>> 2004:                                 if ((!propagated ||
>> 2005:                                      ((j & 1) == 0) && t instanceof
>> 2006:                                      ForkJoinTask.InterruptibleTask) &&
> 
> It's probably premature, but given that all subclasses of InterruptibleTask are final, and that InterruptibleTask is abstract, it _might_ be cheaper to check `t.getClass().getSuperClass() == ForkJoinTask.InterruptibleTask.class`? ?

Thanks. This will probably be part of any solution, (assuming that perf on other tests improves as expected)  but requires one more idea to deal with a rare race.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1807299788

From swen at openjdk.org  Sat Oct 19 11:56:32 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 19 Oct 2024 11:56:32 GMT
Subject: RFR: 8342644: Optimize InvokerBytecodeGenerator for using
 ClassFile API [v2]
In-Reply-To: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
References: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
Message-ID: <Qi1MmYf4ds_Q5CCUVmD6ksUwDl6PvmYAWAeFYdhu72U=.00f5e220-eeac-453e-8dd7-88b91a81f2bc@github.com>

> Cache commonly used classDesc to avoid creating ReferenceClassDescImpl every time

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add LFI/NFI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21580/files
  - new: https://git.openjdk.org/jdk/pull/21580/files/c95ec47d..6aba8d1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21580&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21580&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21580.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21580/head:pull/21580

PR: https://git.openjdk.org/jdk/pull/21580

From duke at openjdk.org  Sat Oct 19 11:56:33 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 19 Oct 2024 11:56:33 GMT
Subject: RFR: 8342644: Optimize InvokerBytecodeGenerator for using
 ClassFile API [v2]
In-Reply-To: <SZHnbajMQU9RzQxFeLNWv9IrlWsDIabTsDUlPF6Yt9o=.411765fd-9377-428c-a5d5-3623c61c07c1@github.com>
References: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
 <4H1FE9CXyi0KYLRsdv4z-jZzcIv3IUhDzqRbUmHs3eI=.d8441ae8-b1bb-4c9b-82d0-c4edc3e3d287@github.com>
 <SZHnbajMQU9RzQxFeLNWv9IrlWsDIabTsDUlPF6Yt9o=.411765fd-9377-428c-a5d5-3623c61c07c1@github.com>
Message-ID: <9-HYRfPtp-QSDYv3r0rLa-S3lUz6rSh1xKMCLsp5iDc=.ebdc2e79-5a4b-41b0-adb2-2144c081930f@github.com>

On Fri, 18 Oct 2024 23:13:27 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 141:
>> 
>>> 139:             case "MH"  -> CD_MH;
>>> 140:             case "DMH" -> CD_DMH;
>>> 141:             case "BMH" -> CD_BMH;
>> 
>> I don't see where DMH and BMH are passed; only see NFI and LFI.
>
> This DMH is derived from invokerName, which comes from java.lang.invoke.LambdaForm.Kind#defaultLambdaName

`"NFI"` and?`"LFI"` should?probably also?be?added to?this?`switch`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21580#discussion_r1807207043

From eirbjo at openjdk.org  Sat Oct 19 11:56:34 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 19 Oct 2024 11:56:34 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v9]
In-Reply-To: <5WKheUkPA1lNoFQYpihqSYVVKt6sMdCy1wiCOXQfS08=.83b81451-cb11-4927-a1c8-ebec985bb786@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <5WKheUkPA1lNoFQYpihqSYVVKt6sMdCy1wiCOXQfS08=.83b81451-cb11-4927-a1c8-ebec985bb786@github.com>
Message-ID: <hxI89Au68-P3hSdwq3XtguHAwDTCXK9Vd8wsaMBfw1g=.f5717615-a73a-47e6-93a7-d65365deccb8@github.com>

On Fri, 18 Oct 2024 21:24:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Combined test

Latest version looks good. Not a Reviewer.

-------------

Marked as reviewed by eirbjo (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21544#pullrequestreview-2379257870

From alanb at openjdk.org  Sat Oct 19 11:56:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Oct 2024 11:56:53 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2423661302

From redestad at openjdk.org  Sat Oct 19 12:10:41 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 19 Oct 2024 12:10:41 GMT
Subject: RFR: 8342644: Optimize InvokerBytecodeGenerator for using
 ClassFile API [v2]
In-Reply-To: <9-HYRfPtp-QSDYv3r0rLa-S3lUz6rSh1xKMCLsp5iDc=.ebdc2e79-5a4b-41b0-adb2-2144c081930f@github.com>
References: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
 <4H1FE9CXyi0KYLRsdv4z-jZzcIv3IUhDzqRbUmHs3eI=.d8441ae8-b1bb-4c9b-82d0-c4edc3e3d287@github.com>
 <SZHnbajMQU9RzQxFeLNWv9IrlWsDIabTsDUlPF6Yt9o=.411765fd-9377-428c-a5d5-3623c61c07c1@github.com>
 <9-HYRfPtp-QSDYv3r0rLa-S3lUz6rSh1xKMCLsp5iDc=.ebdc2e79-5a4b-41b0-adb2-2144c081930f@github.com>
Message-ID: <rMQYVbTkZ3b4DJVQ_jzZUpdt6eVMJFKTR75nuL0Y13E=.f4b164ca-e618-4d0b-8bfb-43399078e834@github.com>

On Sat, 19 Oct 2024 06:39:54 GMT, ExE Boss <duke at openjdk.org> wrote:

>> This DMH is derived from invokerName, which comes from java.lang.invoke.LambdaForm.Kind#defaultLambdaName
>
> `"NFI"` and?`"LFI"` should?probably also?be?added to?this?`switch`.

No: I believe these names are used for invokers spun exclusively for the LF interpreter, which is only used for debugging (and as a development aide) these days. Micro-optimizing those code paths only add complexity for no gain in practice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21580#discussion_r1807306046

From davidalayachew at gmail.com  Sat Oct 19 13:36:36 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 19 Oct 2024 09:36:36 -0400
Subject: Streams, parallelization, and OOME.
In-Reply-To: <CAL5bRt9r3mXLHbTutSzZD6weinvm-DAV6_t8-DgfJp4FuniBWg@mail.gmail.com>
References: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>
 <CAL5bRt9r3mXLHbTutSzZD6weinvm-DAV6_t8-DgfJp4FuniBWg@mail.gmail.com>
Message-ID: <CAA9v-_Mz_HE2XFBczryo01vq0_H0cVrv9+y_1kTJBg5eNyTQqw@mail.gmail.com>

So to be clear, I added a logger to my BufferedReader. So I know for a fact
that it is reading data.

And as for the code, it is a very simple parallel forEach.

someStream.parallel().forEach(**work**);

I only wanted to change the execution from sequential to parallel.

So I have millions and millions of lines being read from the source (1
million lines is several batches alone) and none of it is entering the
forEach loop. And I know this because the very first thing my forEach loop
does is print logs.

As for the iterator, it is literally just a hand rolled iterator (that I
copied from StackOverflow) where there is an instance field holding a list
of elements, sized to match my batch size. hasNext() prepares the next
batch and stores it into that instance field, then returns true/false if
there is data to send, then next() returns that instance field's prepared
batch. Preparing is just making a new list, and storing a batch size's
worth of elements in it.

So this means that it is just grabbing batches and batches, but letting any
of them through into the forEach loop. And when I turn off parallelism,
they suddenly are going through just fine, one after the other.

On Sat, Oct 19, 2024, 7:12?AM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> Hi David. I am not a core libs team but I guess I can have some clues :).
>
> It is hard to tell without the code, but I assume that there are a few
> layers to it.
>
> 1. Stalling. I would assume it is caused mostly by GC pauses taking too
> long (forever) if GC does not have any computational powers to run on.
> There is a fairly common GC-pauses related issue when database connection
> interrupts with exception saying "Broken pipe", which under the hood is
> caused by timeout of connection to database due to long GC pause when
> running on low memory. I am not saying this is your case, but If I were to
> guess I would assume that stall is caused by low memory.
>
> 2. Out of memory root cause may be too much splitting of your data source
> input. You may try to limit it by modifying the behaviour of trySplit
> method of your spliterator.
>
> Alternatively, If you don't mind taking up some disk space, you can try to
> stream data into file, save it, and then use memory-mapped buffers
> (java.nio.MappedByteBuffer) to process accepted data. I am not sure this
> will work, but memory-mapped files is a common tool to deal with operations
> that cant fit into RAM.
>
> Regards
>
>
> On Sat, Oct 19, 2024 at 8:54?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Hello Core Libs Dev Team,
>>
>> I have a file that I am streaming from a service, and I am trying to
>> split into multiple parts based on a certain attribute found on each line.
>> I am sending each part up to a different service.
>>
>> I am using BufferedReader.lines(). However, I cannot read the whole file
>> into memory because it is larger than the amount of RAM that I have on the
>> machine. So, since I don't have access to Java 22's Preview Gatherers Fixed
>> Window, I used the iterator() method on my stream, wrapped that in another
>> iterator that can grab my batch size worth of data, then built a
>> spliterator from that that I then used to create a new stream. In short,
>> this wrapper iterator isn't Iterator<T>, it's Iterator<List<T>>.
>>
>> When I ran this sequentially, everything worked well. However, my CPU was
>> low and we definitely have a performance problem -- our team needs this
>> number as fast as we can get. Plus, we had plenty of network bandwidth to
>> spare, so I had (imo) good reason to go use parallelism.
>>
>> As soon as I turned on parallelism, the stream's behaviour changed
>> completely. Instead of fetching the batch and processing, it started
>> grabbing SEVERAL BATCHES and processing NONE OF THEM. Or at the very least,
>> it grabbed so many batches that it ran out of memory before it could get to
>> processing them.
>>
>> To give some numbers, this is a 4 core machine. And we can safely hold
>> about 30-40 batches worth of data in memory before crashing. But again,
>> when running sequentially, this thing only grabs 1 batch, processes that
>> one batch, sends out the results, and then start the next one, all as
>> expected. I thought that adding parallelism would simply make it so that we
>> have this happening 4 or 8 times at once.
>>
>> After a very long period of digging, I managed to find this link.
>>
>>
>> https://stackoverflow.com/questions/30825708/java-8-using-parallel-in-a-stream-causes-oom-error
>>
>> Tagir Valeev gives an answer which doesn't go very deep into the "why" at
>> all. And the answer is more directed to the user's specific question as
>> opposed to solving this particular problem.
>>
>> After digging through a bunch of other solutions (plus my own testing),
>> it seems that the answer is that the engine that does parallelization for
>> Streams tries to grab a large enough "buffer" before doing any parallel
>> processing. I could be wrong, and how large that buffer is? I have no idea.
>>
>> Regardless, that's about where I gave up and went sequential, since the
>> clock was ticking.
>>
>> But I still have a performance problem. How would one suggest going about
>> this in Java 8?
>>
>> 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/20241019/4b63001f/attachment.htm>

From davidalayachew at gmail.com  Sat Oct 19 13:37:50 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 19 Oct 2024 09:37:50 -0400
Subject: Streams, parallelization, and OOME.
In-Reply-To: <CAA9v-_Mz_HE2XFBczryo01vq0_H0cVrv9+y_1kTJBg5eNyTQqw@mail.gmail.com>
References: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>
 <CAL5bRt9r3mXLHbTutSzZD6weinvm-DAV6_t8-DgfJp4FuniBWg@mail.gmail.com>
 <CAA9v-_Mz_HE2XFBczryo01vq0_H0cVrv9+y_1kTJBg5eNyTQqw@mail.gmail.com>
Message-ID: <CAA9v-_PmB4A=PeR=8u0SgB2iVYWhZ368YT-0C49bOtsgNS_9AA@mail.gmail.com>

But *not letting any of them through into the forEach loop.

On Sat, Oct 19, 2024, 9:36?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> So to be clear, I added a logger to my BufferedReader. So I know for a
> fact that it is reading data.
>
> And as for the code, it is a very simple parallel forEach.
>
> someStream.parallel().forEach(**work**);
>
> I only wanted to change the execution from sequential to parallel.
>
> So I have millions and millions of lines being read from the source (1
> million lines is several batches alone) and none of it is entering the
> forEach loop. And I know this because the very first thing my forEach loop
> does is print logs.
>
> As for the iterator, it is literally just a hand rolled iterator (that I
> copied from StackOverflow) where there is an instance field holding a list
> of elements, sized to match my batch size. hasNext() prepares the next
> batch and stores it into that instance field, then returns true/false if
> there is data to send, then next() returns that instance field's prepared
> batch. Preparing is just making a new list, and storing a batch size's
> worth of elements in it.
>
> So this means that it is just grabbing batches and batches, but letting
> any of them through into the forEach loop. And when I turn off parallelism,
> they suddenly are going through just fine, one after the other.
>
> On Sat, Oct 19, 2024, 7:12?AM Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
>
>> Hi David. I am not a core libs team but I guess I can have some clues :).
>>
>> It is hard to tell without the code, but I assume that there are a few
>> layers to it.
>>
>> 1. Stalling. I would assume it is caused mostly by GC pauses taking too
>> long (forever) if GC does not have any computational powers to run on.
>> There is a fairly common GC-pauses related issue when database connection
>> interrupts with exception saying "Broken pipe", which under the hood is
>> caused by timeout of connection to database due to long GC pause when
>> running on low memory. I am not saying this is your case, but If I were to
>> guess I would assume that stall is caused by low memory.
>>
>> 2. Out of memory root cause may be too much splitting of your data source
>> input. You may try to limit it by modifying the behaviour of trySplit
>> method of your spliterator.
>>
>> Alternatively, If you don't mind taking up some disk space, you can try
>> to stream data into file, save it, and then use memory-mapped buffers
>> (java.nio.MappedByteBuffer) to process accepted data. I am not sure this
>> will work, but memory-mapped files is a common tool to deal with operations
>> that cant fit into RAM.
>>
>> Regards
>>
>>
>> On Sat, Oct 19, 2024 at 8:54?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> Hello Core Libs Dev Team,
>>>
>>> I have a file that I am streaming from a service, and I am trying to
>>> split into multiple parts based on a certain attribute found on each line.
>>> I am sending each part up to a different service.
>>>
>>> I am using BufferedReader.lines(). However, I cannot read the whole file
>>> into memory because it is larger than the amount of RAM that I have on the
>>> machine. So, since I don't have access to Java 22's Preview Gatherers Fixed
>>> Window, I used the iterator() method on my stream, wrapped that in another
>>> iterator that can grab my batch size worth of data, then built a
>>> spliterator from that that I then used to create a new stream. In short,
>>> this wrapper iterator isn't Iterator<T>, it's Iterator<List<T>>.
>>>
>>> When I ran this sequentially, everything worked well. However, my CPU
>>> was low and we definitely have a performance problem -- our team needs this
>>> number as fast as we can get. Plus, we had plenty of network bandwidth to
>>> spare, so I had (imo) good reason to go use parallelism.
>>>
>>> As soon as I turned on parallelism, the stream's behaviour changed
>>> completely. Instead of fetching the batch and processing, it started
>>> grabbing SEVERAL BATCHES and processing NONE OF THEM. Or at the very least,
>>> it grabbed so many batches that it ran out of memory before it could get to
>>> processing them.
>>>
>>> To give some numbers, this is a 4 core machine. And we can safely hold
>>> about 30-40 batches worth of data in memory before crashing. But again,
>>> when running sequentially, this thing only grabs 1 batch, processes that
>>> one batch, sends out the results, and then start the next one, all as
>>> expected. I thought that adding parallelism would simply make it so that we
>>> have this happening 4 or 8 times at once.
>>>
>>> After a very long period of digging, I managed to find this link.
>>>
>>>
>>> https://stackoverflow.com/questions/30825708/java-8-using-parallel-in-a-stream-causes-oom-error
>>>
>>> Tagir Valeev gives an answer which doesn't go very deep into the "why"
>>> at all. And the answer is more directed to the user's specific question as
>>> opposed to solving this particular problem.
>>>
>>> After digging through a bunch of other solutions (plus my own testing),
>>> it seems that the answer is that the engine that does parallelization for
>>> Streams tries to grab a large enough "buffer" before doing any parallel
>>> processing. I could be wrong, and how large that buffer is? I have no idea.
>>>
>>> Regardless, that's about where I gave up and went sequential, since the
>>> clock was ticking.
>>>
>>> But I still have a performance problem. How would one suggest going
>>> about this in Java 8?
>>>
>>> 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/20241019/2c8225ba/attachment-0001.htm>

From redestad at openjdk.org  Sat Oct 19 15:41:48 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 19 Oct 2024 15:41:48 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v9]
In-Reply-To: <5WKheUkPA1lNoFQYpihqSYVVKt6sMdCy1wiCOXQfS08=.83b81451-cb11-4927-a1c8-ebec985bb786@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <5WKheUkPA1lNoFQYpihqSYVVKt6sMdCy1wiCOXQfS08=.83b81451-cb11-4927-a1c8-ebec985bb786@github.com>
Message-ID: <6YSG7BfxpqrgD96_5F8LtkDUyoN70iOtx7ZJA7sFpjU=.68d207bc-34b1-4f29-ac4b-a28867a877a3@github.com>

On Fri, 18 Oct 2024 21:24:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Combined test

src/java.base/share/classes/java/util/zip/ZipEntry.java line 723:

> 721:      * @return true if valid CEN Header size; false otherwise
> 722:      */
> 723:      static boolean isCENHeaderValid(String name, byte[] extra, String comment) {

I think it should be spelled out better that `isCENHeaderValid` can give false positives since both `name` and `comment` may turn into more than `String::length` bytes after conversion. So while it's a reasonable sanity check to fail-fast you still need an exact check after conversion like in `ZipOutputStream::writeCEN`. Or we could consider converting `name` and `comment` to bytes eagerly and get an exact check up front?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1807388643

From lancea at openjdk.org  Sat Oct 19 15:55:01 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 19 Oct 2024 15:55:01 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v9]
In-Reply-To: <6YSG7BfxpqrgD96_5F8LtkDUyoN70iOtx7ZJA7sFpjU=.68d207bc-34b1-4f29-ac4b-a28867a877a3@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <5WKheUkPA1lNoFQYpihqSYVVKt6sMdCy1wiCOXQfS08=.83b81451-cb11-4927-a1c8-ebec985bb786@github.com>
 <6YSG7BfxpqrgD96_5F8LtkDUyoN70iOtx7ZJA7sFpjU=.68d207bc-34b1-4f29-ac4b-a28867a877a3@github.com>
Message-ID: <RTPRvne7SdJO7d2MaFO9jVeLQ2j7hEx1H2wlUkiDibw=.2aae2213-76ab-43de-b417-75a90d58a15d@github.com>

On Sat, 19 Oct 2024 15:38:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add Combined test
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 723:
> 
>> 721:      * @return true if valid CEN Header size; false otherwise
>> 722:      */
>> 723:      static boolean isCENHeaderValid(String name, byte[] extra, String comment) {
> 
> I think it should be spelled out better that `isCENHeaderValid` can give false positives since both `name` and `comment` may turn into more than `String::length` bytes after conversion. So while it's a reasonable sanity check to fail-fast you still need an exact check after conversion like in `ZipOutputStream::writeCEN`. Or we could consider converting `name` and `comment` to bytes eagerly and get an exact check up front?

Sure, I can add an additional comment here if you like for future maintainers.  I don't want to consider converting name/comments earlier than needed as part of this PR as that start to creep out of the scope of the original issue being addressed, especially given this is a corner case(a corpus search of 90K+ jars only found 520 Zip entries with a header size between 500 - 1000 bytes and everything else  < 500 bytes).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1807391884

From lancea at openjdk.org  Sat Oct 19 16:28:34 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 19 Oct 2024 16:28:34 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v10]
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <haJq-wKDxMtbmKMxCQ6DtUWNfF6WfOLo-g3EPLRGafI=.54106d14-5630-4248-baf3-cf9dd5198c62@github.com>

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Added additional clarifiction to isCENHeaderValid comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21544/files
  - new: https://git.openjdk.org/jdk/pull/21544/files/a565193d..68ed98a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21544&range=08-09

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21544.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21544/head:pull/21544

PR: https://git.openjdk.org/jdk/pull/21544

From redestad at openjdk.org  Sat Oct 19 16:40:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 19 Oct 2024 16:40:20 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v10]
In-Reply-To: <haJq-wKDxMtbmKMxCQ6DtUWNfF6WfOLo-g3EPLRGafI=.54106d14-5630-4248-baf3-cf9dd5198c62@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <haJq-wKDxMtbmKMxCQ6DtUWNfF6WfOLo-g3EPLRGafI=.54106d14-5630-4248-baf3-cf9dd5198c62@github.com>
Message-ID: <-zi8KBhfXUYl9oKo7JilpoXMcNQtaohA-UMycvaeDIE=.b3a363df-765f-417a-b675-fe8ed35f8cf5@github.com>

On Sat, 19 Oct 2024 16:28:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added additional clarifiction to isCENHeaderValid comment

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21544#pullrequestreview-2379623525

From redestad at openjdk.org  Sat Oct 19 16:40:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 19 Oct 2024 16:40:21 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v9]
In-Reply-To: <RTPRvne7SdJO7d2MaFO9jVeLQ2j7hEx1H2wlUkiDibw=.2aae2213-76ab-43de-b417-75a90d58a15d@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <5WKheUkPA1lNoFQYpihqSYVVKt6sMdCy1wiCOXQfS08=.83b81451-cb11-4927-a1c8-ebec985bb786@github.com>
 <6YSG7BfxpqrgD96_5F8LtkDUyoN70iOtx7ZJA7sFpjU=.68d207bc-34b1-4f29-ac4b-a28867a877a3@github.com>
 <RTPRvne7SdJO7d2MaFO9jVeLQ2j7hEx1H2wlUkiDibw=.2aae2213-76ab-43de-b417-75a90d58a15d@github.com>
Message-ID: <6YTQiHgkr9ETreHo5e7Fq0KEIY0oNuqnf_fw06GBF9s=.ef018d85-77e2-4be4-a63d-c57cc1c5a30d@github.com>

On Sat, 19 Oct 2024 15:52:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipEntry.java line 723:
>> 
>>> 721:      * @return true if valid CEN Header size; false otherwise
>>> 722:      */
>>> 723:      static boolean isCENHeaderValid(String name, byte[] extra, String comment) {
>> 
>> I think it should be spelled out better that `isCENHeaderValid` can give false positives since both `name` and `comment` may turn into more than `String::length` bytes after conversion. So while it's a reasonable sanity check to fail-fast you still need an exact check after conversion like in `ZipOutputStream::writeCEN`. Or we could consider converting `name` and `comment` to bytes eagerly and get an exact check up front?
>
> Sure, I can add an additional comment here if you like for future maintainers.  I don't want to consider converting name/comments earlier than needed as part of this PR as that start to creep out of the scope of the original issue being addressed, especially given this is a corner case(a corpus search of 90K+ jars only found 520 Zip entries with a header size between 500 - 1000 bytes and everything else  < 500 bytes).

Good

Yes, converting early might have other compatibility concerns, too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21544#discussion_r1807417503

From redestad at openjdk.org  Sat Oct 19 20:45:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 19 Oct 2024 20:45:40 GMT
Subject: RFR: 8341776: Remove unused enum values from LambdaForm$Kind
Message-ID: <S-8nTDQCfllBLb5dcMSgzEFNxu0KrdBqy5UDwSbp1Vo=.ea38962f-9dbb-463f-a429-a0670df13657@github.com>

Trivially removing some unused left-over `LambdaForm$Kind` enums. 

- Last use of `COLLECT` and `SPREAD` was removed by fac39fe9
- `FIELD` was added by 8d5f5b9a but had no usage from the start
- Last use of `CONVERT` was removed by eda5f090

-------------

Commit messages:
 - 8341776: Remove unused enum values from LambdaForm

Changes: https://git.openjdk.org/jdk/pull/21592/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21592&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341776
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21592/head:pull/21592

PR: https://git.openjdk.org/jdk/pull/21592

From darcy at openjdk.org  Sat Oct 19 21:02:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 19 Oct 2024 21:02:53 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector
Message-ID: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>

Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.

-------------

Commit messages:
 - Update with changes from lworld+fp16 Float16.
 - Merge branch 'master' into JDK-8341260
 - Add support for BigDecimal -> Float16 conversion.
 - JDK-8341260: Add Float16 to jdk.incubator.vector

Changes: https://git.openjdk.org/jdk/pull/21574/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341260
  Stats: 2355 lines in 4 files changed: 2350 ins; 0 del; 5 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  Sat Oct 19 21:02:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 19 Oct 2024 21:02:53 GMT
Subject: RFR: 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: <SRvxUfn3v8MtH1uZii5alE-Tiadg4zydxMSlpoB57vo=.9274c217-2005-4e49-b88a-9cf909745453@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.

Add as contributors other engineers who worked on Float16 on the lworld+fp16 branch in Valhalla.

To ease review, diffs of corresponding files from the current, at time of writing, state of files in lworld+fp16 vs a port to jdk.incubator.vector, starting with Float16:


$ diff src/java.base/share/classes/java/lang/Float16.java  ~/jdk24/open/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java 
26c26
< package java.lang;
---
> package jdk.incubator.vector;
28a29
> import java.math.BigInteger;
30,31c31,32
< import jdk.internal.math.*;
< import jdk.internal.vm.annotation.IntrinsicCandidate;
---
> // import jdk.internal.math.*;
> // import jdk.internal.vm.annotation.IntrinsicCandidate;
37c38
<  * The {@code Float16} is a primitive value class holding 16-bit data
---
>  * The {@code Float16} is a class holding 16-bit data
46,48d46
<  * <p>This is a <a href="https://openjdk.org/jeps/401">primitive value class</a> and its objects are
<  * identity-less non-nullable value objects.
<  *
52a51,56
>  * <p>This is a <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>
>  * class; programmers should treat instances that are
>  * {@linkplain #equals(Object) equal} as interchangeable and should not
>  * use instances for synchronization, or unpredictable behavior may
>  * occur. For example, in a future release, synchronization may fail.
>  *
62,64d65
<  *
<  * @author Jatin Bhateja
<  * @since 20.00
69,70c70,71
< @jdk.internal.MigratedValueClass
< @jdk.internal.ValueBased
---
> // @jdk.internal.MigratedValueClass
> //@jdk.internal.ValueBased
213c214,215
<         return FloatToDecimal.toString(f16.floatValue());
---
>         return Float.toString(f16.floatValue());
>         // return FloatToDecimal.toString(f16.floatValue());
420d421
<      * @see BigDecimal#float16Value()
423c424,539
<         return v.float16Value();
---
>         return BigDecimalConversion.float16Value(v);
>     }
> 
>     private class BigDecimalConversion {
>         /*
>          * Let l = log_2(10).
>          * Then, L < l < L + ulp(L) / 2, that is, L = roundTiesToEven(l).
>          */
>         private static final double L = 3.321928094887362;
> 
>         private static final int P_F16 = PRECISION;  // 11
>         private static final int Q_MIN_F16 = MIN_EXPONENT - (P_F16 - 1);  // -24
>         private static final int Q_MAX_F16 = MAX_EXPONENT - (P_F16 - 1);  // 5
> 
>         /**
>          * Powers of 10 which can be represented exactly in {@code
>          * Float16}.
>          */
>         private static final Float16[] FLOAT16_10_POW = {
>             Float16.valueOf(1), Float16.valueOf(10), Float16.valueOf(100),
>             Float16.valueOf(1_000), Float16.valueOf(10_000)
>         };
> 
>         public static Float16 float16Value(BigDecimal bd) {
> //             int scale = bd.scale();
> //             BigInteger unscaledValue = bd.unscaledValue();
> 
> //              if (unscaledValue.abs().compareTo(BigInteger.valueOf(Long.MAX_VALUE)) <= 0) {
> //                 long intCompact = bd.longValue();
> //                 Float16 v = Float16.valueOf(intCompact);
> //                 if (scale == 0) {
> //                     return v;
> //                 }
> //                 /*
> //                  * The discussion for the double case also applies here. That is,
> //                  * the following test is precise for all long values, but here
> //                  * Long.MAX_VALUE is not an issue.
> //                  */
> //                 if (v.longValue() == intCompact) {
> //                     if (0 < scale && scale < FLOAT16_10_POW.length) {
> //                         return Float16.divide(v, FLOAT16_10_POW[scale]);
> //                     }
> //                     if (0 > scale && scale > -FLOAT16_10_POW.length) {
> //                         return Float16.multiply(v, FLOAT16_10_POW[-scale]);
> //                     }
> //                 }
> //             }
>             return fullFloat16Value(bd);
>         }
> 
>         private static BigInteger bigTenToThe(int scale) {
>             return BigInteger.TEN.pow(scale);
>         }
> 
>         private static Float16 fullFloat16Value(BigDecimal bd) {
>             if (BigDecimal.ZERO.compareTo(bd) == 0) {
>                 return Float16.valueOf(0);
>             }
>             BigInteger w = bd.unscaledValue().abs();
>             int scale = bd.scale();
>             long qb = w.bitLength() - (long) Math.ceil(scale * L);
>             Float16 signum = Float16.valueOf(bd.signum());
>             if (qb < Q_MIN_F16 - 2) {  // qb < -26
>                 return Float16.multiply(signum, Float16.valueOf(0));
>             }
>             if (qb > Q_MAX_F16 + P_F16 + 1) {  // qb > 17
>                 return Float16.multiply(signum, Float16.POSITIVE_INFINITY);
>             }
>             if (scale < 0) {
>                 return Float16.multiply(signum, valueOf(w.multiply(bigTenToThe(-scale))));
>             }
>             if (scale == 0) {
>                 return Float16.multiply(signum, valueOf(w));
>             }
>             int ql = (int) qb - (P_F16 + 3);
>             BigInteger pow10 =  bigTenToThe(scale);
>             BigInteger m, n;
>             if (ql <= 0) {
>                 m = w.shiftLeft(-ql);
>                 n = pow10;
>             } else {
>                 m = w;
>                 n = pow10.shiftLeft(ql);
>             }
>             BigInteger[] qr = m.divideAndRemainder(n);
>             /*
>              * We have
>              *      2^12 = 2^{P+1} <= i < 2^{P+5} = 2^16
>              * Contrary to the double and float cases, where we use long and int, resp.,
>              * here we cannot simply declare i as short, because P + 5 < Short.SIZE
>              * fails to hold.
>              * Using int is safe, though.
>              *
>              * Further, as Math.scalb(Float16) does not exists, we fall back to
>              * Math.scalb(double).
>              */
>             int i = qr[0].intValue();
>             int sb = qr[1].signum();
>             int dq = (Integer.SIZE - (P_F16 + 2)) - Integer.numberOfLeadingZeros(i);
>             int eq = (Q_MIN_F16 - 2) - ql;
>             if (dq >= eq) {
>                 return Float16.valueOf(bd.signum() * Math.scalb((double) (i | sb), ql));
>             }
>             int mask = (1 << eq) - 1;
>             int j = i >> eq | (Integer.signum(i & mask)) | sb;
>             return Float16.valueOf(bd.signum() * Math.scalb((double) j, Q_MIN_F16 - 2));
>         }
> 
>         public static Float16 valueOf(BigInteger bi) {
>             int signum = bi.signum();
>             return (signum == 0 || bi.bitLength() <= 31)
>                 ? Float16.valueOf(bi.longValue())  // might return infinities
>                 : signum > 0
>                 ? Float16.POSITIVE_INFINITY
>                 : Float16.NEGATIVE_INFINITY;
>         }
577,578c693
<      * according to the IEEE 754 floating-point binary16 bit layout,
<      * preserving Not-a-Number (NaN) values.
---
>      * according to the IEEE 754 floating-point binary16 bit layout.
591,607d705
<      * Returns a representation of the specified floating-point value
<      * according to the IEEE 754 floating-point binary16 bit layout.
<      *
<      * @param   fp16   a {@code Float16} floating-point number.
<      * @return the bits that represent the floating-point number.
<      *
<      * @see Float#floatToIntBits(float)
<      * @see Double#doubleToLongBits(double)
<      */
<     public static short float16ToShortBits(Float16 fp16) {
<         if (!isNaN(fp16)) {
<             return float16ToRawShortBits(fp16);
<         }
<         return 0x7e00;
<     }
< 
<     /**
694c792
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
714c812
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
783c881
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
806c904
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
829c927
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
852c950
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
873c971
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
907c1005
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
1109c1207
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
1131c1229
<     @IntrinsicCandidate
---
>     // @IntrinsicCandidate
1319a1418
>         int DoubleConsts_EXP_BIAS = 1023;
1328c1427
<                 * Double.longBitsToDouble((long) (scaleFactor + DoubleConsts.EXP_BIAS) << Double.PRECISION - 1));
---
>                 * Double.longBitsToDouble((long) (scaleFactor + DoubleConsts_EXP_BIAS) << Double.PRECISION - 1));
1330d1428
< 
1374d1471
<

$ diff src/java.base/share/classes/jdk/internal/math/Float16Consts.java  ~/jdk24/open/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Consts.java 
26c26
< package jdk.internal.math;
---
> package jdk.incubator.vector;
28,30c28,30
< import static java.lang.Float16.MIN_EXPONENT;
< import static java.lang.Float16.PRECISION;
< import static java.lang.Float16.SIZE;
---
> import static jdk.incubator.vector.Float16.MIN_EXPONENT;
> import static jdk.incubator.vector.Float16.PRECISION;
> import static jdk.incubator.vector.Float16.SIZE;
37c37
< public class Float16Consts {
---
> class Float16Consts {

$ diff test/jdk/java/lang/Float16/BasicFloat16ArithTests.java  ~/jdk24/test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java 
26c26,27
<  * @bug 8329817 8334432 8339076
---
>  * @bug 8329817 8334432 8339076 8341260
>  * @modules jdk.incubator.vector
30c31,32
< import static java.lang.Float16.*;
---
> import jdk.incubator.vector.Float16;
> import static jdk.incubator.vector.Float16.*;

$ diff test/jdk/java/math/BigDecimal/DoubleFloatValueTests.java  ~/jdk24/test/jdk/java/math/BigDecimal/DoubleFloatValueTests.java 
26c26
<  * @bug 8205592 8339252
---
>  * @bug 8205592 8339252 8341260
27a28
>  * @modules jdk.incubator.vector
37a39
> import jdk.incubator.vector.Float16;
110c112
<         Float16 res = bv.float16Value();
---
>         Float16 res =  Float16.valueOf(bv); // bv.float16Value();

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2420835843
PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2420843492
PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2420846567
PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2420850283

From darcy at openjdk.org  Sat Oct 19 21:02:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 19 Oct 2024 21:02:54 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector
In-Reply-To: <SRvxUfn3v8MtH1uZii5alE-Tiadg4zydxMSlpoB57vo=.9274c217-2005-4e49-b88a-9cf909745453@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <SRvxUfn3v8MtH1uZii5alE-Tiadg4zydxMSlpoB57vo=.9274c217-2005-4e49-b88a-9cf909745453@github.com>
Message-ID: <M2IsbBp79pZPoeiMhUq50Xj0u1OZXW72S8AhDPe8E0Y=.5fb75f91-cbd8-454b-b6d2-1bbcdbeedaaf@github.com>

On Thu, 17 Oct 2024 23:37:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> ```
> $ diff test/jdk/java/lang/Float16/BasicFloat16ArithTests.java  ~/jdk24/test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java 
> 26c26,27
> <  * @bug 8329817 8334432 8339076
> ---
> >  * @bug 8329817 8334432 8339076 8341260
> >  * @modules jdk.incubator.vector
> 30c31,32
> < import static java.lang.Float16.*;
> ---
> > import jdk.incubator.vector.Float16;
> > import static jdk.incubator.vector.Float16.*;
> 
> $ diff test/jdk/java/math/BigDecimal/DoubleFloatValueTests.java  ~/jdk24/test/jdk/java/math/BigDecimal/DoubleFloatValueTests.java 
> 26c26
> <  * @bug 8205592 8339252
> ---
> >  * @bug 8205592 8339252 8341260
> 27a28
> >  * @modules jdk.incubator.vector
> 37a39
> > import jdk.incubator.vector.Float16;
> 110c112
> <         Float16 res = bv.float16Value();
> ---
> >         Float16 res =  Float16.valueOf(bv); // bv.float16Value();
> ```

Initially, I left the tests for the BigDecimal -> Float16 conversion in the tests for the base module to ease review compared to their location in the Valhalla branch. The tests can be extracted and moved to a jdk.incubator.vector area subsequently.

> To ease review, diffs of corresponding files from the current, at time of writing, state of files in lworld+fp16 vs a port to jdk.incubator.vector, starting with Float16:
> 
> ```
> $ diff src/java.base/share/classes/java/lang/Float16.java  ~/jdk24/open/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java 
> 26c26
> < package java.lang;
> ---
> > package jdk.incubator.vector;
> 28a29
> > import java.math.BigInteger;
> 30,31c31,32
> < import jdk.internal.math.*;
> < import jdk.internal.vm.annotation.IntrinsicCandidate;
> ---
> > // import jdk.internal.math.*;
> > // import jdk.internal.vm.annotation.IntrinsicCandidate;
> 37c38
> <  * The {@code Float16} is a primitive value class holding 16-bit data
> ---
> >  * The {@code Float16} is a class holding 16-bit data
> 46,48d46
> <  * <p>This is a <a href="https://openjdk.org/jeps/401">primitive value class</a> and its objects are
> <  * identity-less non-nullable value objects.
> <  *
> 52a51,56
> >  * <p>This is a <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>
> >  * class; programmers should treat instances that are
> >  * {@linkplain #equals(Object) equal} as interchangeable and should not
> >  * use instances for synchronization, or unpredictable behavior may
> >  * occur. For example, in a future release, synchronization may fail.
> >  *
> 62,64d65
> <  *
> <  * @author Jatin Bhateja
> <  * @since 20.00
> 69,70c70,71
> < @jdk.internal.MigratedValueClass
> < @jdk.internal.ValueBased
> ---
> > // @jdk.internal.MigratedValueClass
> > //@jdk.internal.ValueBased
> 213c214,215
> <         return FloatToDecimal.toString(f16.floatValue());
> ---
> >         return Float.toString(f16.floatValue());
> >         // return FloatToDecimal.toString(f16.floatValue());
> 420d421
> <      * @see BigDecimal#float16Value()
> 423c424,539
> <         return v.float16Value();
> ---
> >         return BigDecimalConversion.float16Value(v);
> >     }
> > 
> >     private class BigDecimalConversion {
> >         /*
> >          * Let l = log_2(10).
> >          * Then, L < l < L + ulp(L) / 2, that is, L = roundTiesToEven(l).
> >          */
> >         private static final double L = 3.321928094887362;
> > 
> >         private static final int P_F16 = PRECISION;  // 11
> >         private static final int Q_MIN_F16 = MIN_EXPONENT - (P_F16 - 1);  // -24
> >         private static final int Q_MAX_F16 = MAX_EXPONENT - (P_F16 - 1);  // 5
> > 
> >         /**
> >          * Powers of 10 which can be represented exactly in {@code
> >          * Float16}.
> >          */
> >         private static final Float16[] FLOAT16_10_POW = {
> >             Float16.valueOf(1), Float16.valueOf(10), Float16.valueOf(100),
> >             Float16.valueOf(1_000), Float16.valueOf(10_000)
> >         };
> > 
> >         public static Float16 float16Value(BigDecimal bd) {
> > //             int scale = bd.scale();
> > //             BigInteger unscaledValue = bd.unscaledValue();
> > 
> > //              if (unscaledValue.abs().compareTo(BigInteger.valueOf(Long.MAX_VALUE)) <= 0) {
> > //                 long intCompact = bd.longValue();
> > //                 Float16 v = Float16.valueOf(intCompact);
> > //                 if (scale == 0) {
> > //                     return v;
> > //                 }
> > //                 /*
> > //                  * The discussion for the double case also applies here. That is,
> > //                  * the following test is precise for all long values, but here
> > //                  * Long.MAX_VALUE is not an issue.
> > //                  */
> > //                 if (v.longValue() == intCompact) {
> > //                     if (0 < scale && scale < FLOAT16_10_POW.length) {
> > //                         return Float16.divide(v, FLOAT16_10_POW[scale]);
> > //                     }
> > //                     if (0 > scale && scale > -FLOAT16_10_POW.length) {
> > //                         return Float16.multiply(v, FLOAT16_10_POW[-scale]);
> > //                     }
> > //                 }
> > //             }
> >             return fullFloat16Value(bd);
> >         }
> > 
> >         private static BigInteger bigTenToThe(int scale) {
> >             return BigInteger.TEN.pow(scale);
> >         }
> > 
> >         private static Float16 fullFloat16Value(BigDecimal bd) {
> >             if (BigDecimal.ZERO.compareTo(bd) == 0) {
> >                 return Float16.valueOf(0);
> >             }
> >             BigInteger w = bd.unscaledValue().abs();
> >             int scale = bd.scale();
> >             long qb = w.bitLength() - (long) Math.ceil(scale * L);
> >             Float16 signum = Float16.valueOf(bd.signum());
> >             if (qb < Q_MIN_F16 - 2) {  // qb < -26
> >                 return Float16.multiply(signum, Float16.valueOf(0));
> >             }
> >             if (qb > Q_MAX_F16 + P_F16 + 1) {  // qb > 17
> >                 return Float16.multiply(signum, Float16.POSITIVE_INFINITY);
> >             }
> >             if (scale < 0) {
> >                 return Float16.multiply(signum, valueOf(w.multiply(bigTenToThe(-scale))));
> >             }
> >             if (scale == 0) {
> >                 return Float16.multiply(signum, valueOf(w));
> >             }
> >             int ql = (int) qb - (P_F16 + 3);
> >             BigInteger pow10 =  bigTenToThe(scale);
> >             BigInteger m, n;
> >             if (ql <= 0) {
> >                 m = w.shiftLeft(-ql);
> >                 n = pow10;
> >             } else {
> >                 m = w;
> >                 n = pow10.shiftLeft(ql);
> >             }
> >             BigInteger[] qr = m.divideAndRemainder(n);
> >             /*
> >              * We have
> >              *      2^12 = 2^{P+1} <= i < 2^{P+5} = 2^16
> >              * Contrary to the double and float cases, where we use long and int, resp.,
> >              * here we cannot simply declare i as short, because P + 5 < Short.SIZE
> >              * fails to hold.
> >              * Using int is safe, though.
> >              *
> >              * Further, as Math.scalb(Float16) does not exists, we fall back to
> >              * Math.scalb(double).
> >              */
> >             int i = qr[0].intValue();
> >             int sb = qr[1].signum();
> >             int dq = (Integer.SIZE - (P_F16 + 2)) - Integer.numberOfLeadingZeros(i);
> >             int eq = (Q_MIN_F16 - 2) - ql;
> >             if (dq >= eq) {
> >                 return Float16.valueOf(bd.signum() * Math.scalb((double) (i | sb), ql));
> >             }
> >             int mask = (1 << eq) - 1;
> >             int j = i >> eq | (Integer.signum(i & mask)) | sb;
> >             return Float16.valueOf(bd.signum() * Math.scalb((double) j, Q_MIN_F16 - 2));
> >         }
> > 
> >         public static Float16 valueOf(BigInteger bi) {
> >             int signum = bi.signum();
> >             return (signum == 0 || bi.bitLength() <= 31)
> >                 ? Float16.valueOf(bi.longValue())  // might return infinities
> >                 : signum > 0
> >                 ? Float16.POSITIVE_INFINITY
> >                 : Float16.NEGATIVE_INFINITY;
> >         }
> 577,578c693
> <      * according to the IEEE 754 floating-point binary16 bit layout,
> <      * preserving Not-a-Number (NaN) values.
> ---
> >      * according to the IEEE 754 floating-point binary16 bit layout.
> 591,607d705
> <      * Returns a representation of the specified floating-point value
> <      * according to the IEEE 754 floating-point binary16 bit layout.
> <      *
> <      * @param   fp16   a {@code Float16} floating-point number.
> <      * @return the bits that represent the floating-point number.
> <      *
> <      * @see Float#floatToIntBits(float)
> <      * @see Double#doubleToLongBits(double)
> <      */
> <     public static short float16ToShortBits(Float16 fp16) {
> <         if (!isNaN(fp16)) {
> <             return float16ToRawShortBits(fp16);
> <         }
> <         return 0x7e00;
> <     }
> < 
> <     /**
> 694c792
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 714c812
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 783c881
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 806c904
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 829c927
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 852c950
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 873c971
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 907c1005
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 1109c1207
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 1131c1229
> <     @IntrinsicCandidate
> ---
> >     // @IntrinsicCandidate
> 1319a1418
> >         int DoubleConsts_EXP_BIAS = 1023;
> 1328c1427
> <                 * Double.longBitsToDouble((long) (scaleFactor + DoubleConsts.EXP_BIAS) << Double.PRECISION - 1));
> ---
> >                 * Double.longBitsToDouble((long) (scaleFactor + DoubleConsts_EXP_BIAS) << Double.PRECISION - 1));
> 1330d1428
> < 
> 1374d1471
> < 
> ```

As initially done here, the port of Float16 omits any VM intrinsification; that would need to be done by subsequent work. Subsequent work may also adapt the Java implementations to be more amenable to being intrinsified.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2420858962
PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2420867094

From jrose at openjdk.org  Sat Oct 19 22:58:04 2024
From: jrose at openjdk.org (John R Rose)
Date: Sat, 19 Oct 2024 22:58:04 GMT
Subject: RFR: 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: <HqfC4POkKD5e8UV8ixN2VMTQF6H6FhLU8R2ITjlN6RY=.0080635c-61f0-4720-a9c7-6f33659a1ac4@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.

Joe, our revised and now-current thinking about JIT support for the Float16 (both as a pre-Valhalla VBC and Valhalla value class) is that there should be zero need for any `@IntrinsicCandidate` markers in `Float16.java`.

The two existing intrinsics in `Float.java` should be fully sufficient to cue the JIT to introduce FP16 types and operations in its IR.  There is no need to help the JIT either recognize Float16 objects as special types, nor recognize the special interpretation of the `short` value field inside.  It is very routine in the Valhalla JIT to strip off the boxing (i.e., the VBC-like Float16 details) and just deal directly with the payload (i.e., the `short` value).  And it is also routine to change perspective on live values in the IR, depending on how they are used (i.e, via the two `Float` intrinsics), so that the IR ends up storing FP16 temps in whatever register class the CPU likes best.

So, unless there is some reason I am not aware of, there does not need to be any intrinsic definition in `Float16.java`, nor even a comment that gestures at the possible existence of an intrinsic.]

Note the economy of the resulting design:  Two intrinsics at the Java level provide the JIT with ample opportunity (if it so desires) to organize an IR with a full FP16 type and all its typed operations.  There is no need to surface such complexity in the Java source code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2424264803

From jrose at openjdk.org  Sat Oct 19 23:07:05 2024
From: jrose at openjdk.org (John R Rose)
Date: Sat, 19 Oct 2024 23:07:05 GMT
Subject: RFR: 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: <LGeYTsDae_5SLo9HMi0TyeORYy_dKZZmopwxP5s_naw=.49645603-2c0d-4964-be98-405fcbb2e157@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.

Somebody might ask as a followup, "But what about calling sequences?  Without intrinsics, how does the JIT know to store Float16 values in the correct type of argument register?"   Presumably some platforms may wish to store arguments (and return values) in floating point registers, not in the integer registers used by a typical value class (such as Float16, containing a single `short` value).

That question might be motivated by the observation that, while FP16 stored in temps might well be stored in FPU registers, simply due to proximity to decode/encode intrinsics, changing the calling sequence requires that we give the Float16 class a little extra magic.  (More detail:  There are fundamentally 3 different places that FP16 values might need type-specific storage:  IR temps, argument/return registers, and heap variables.  The first can often be FPU regs.  The last can be untyped memory words and a `short` is just fine.  The middle are driven by the type of the value field, but can also take the field container Float16 into account.)

In any case, getting those details right does not require any `@IntrinsicCandidate` annotation, or any other source-level annotation.  It just requires the VM to know about Float16 and treat it a little bit specially.  Wholesale marking of methods is overkill.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2424274895

From redestad at openjdk.org  Sat Oct 19 23:24:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 19 Oct 2024 23:24:40 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <XxflQwYd-F5tMnmwozI8wHC8p5GwJisbT7zzwvP8w1o=.aea098d2-a98b-4bd7-80fd-37385fc91599@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
 <XxflQwYd-F5tMnmwozI8wHC8p5GwJisbT7zzwvP8w1o=.aea098d2-a98b-4bd7-80fd-37385fc91599@github.com>
Message-ID: <5gmz0_Piseb_o1SzBeDw0nYJVYlpitOLTcZJTC_xr5I=.e85f6998-68de-4f36-95da-d5c12566d8fa@github.com>

On Fri, 18 Oct 2024 23:29:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> After PR 19970, the performance has been significantly improved. Below are the performance numbers for AMD CPU (x64)

It'd be interesting to check performance on this micro with #19970 alone

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2424281717

From jrose at openjdk.org  Sun Oct 20 00:45:10 2024
From: jrose at openjdk.org (John R Rose)
Date: Sun, 20 Oct 2024 00:45:10 GMT
Subject: RFR: 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: <miRUMDCCQxFLE-Bn0xhy-nJcES_mRE3QFAY58VFwMPQ=.ae349858-8a6b-4120-a1e4-274fb2e33915@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.

Comparing with https://github.com/openjdk/jdk/pull/21490 we can see that there are more than minimum number of intrinsics I recommended above, but (crucially) the intrinsics are decoupled from the box type, and refactored into `Float16Math.java`.

https://github.com/openjdk/jdk/pull/21490/files#diff-105a2bf4929174c594b5bcc54f749e93d9fca1b5371ca301fff02badd0e8da5a

For example, see the max intrinsics line 53.  These intrinsics are better structured for the JIT, because there is no extraneous boxing to deal with.  (Boxes involve null checks and heap allocation and other details which are just extra overhead.)

Apart from intrinsic classification, a simpler thing to do that may help the box methods to fold up correctly would be a `@ForceInline` annotation.  But for the simple methods in this PR that is usually overkill.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2424347511

From jpai at openjdk.org  Sun Oct 20 06:45:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 20 Oct 2024 06:45:44 GMT
Subject: RFR: 8342647: [macosx] Clean up the NSInvocation based call to
 NSProcessInfo.operatingSystemVersion
Message-ID: <SzZICb-aR_RUOor8aydA6hvQ0GbxEUquGvtTk1joe-Y=.91179760-d934-471e-bf2d-9af6466c1502@github.com>

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.

-------------

Commit messages:
 - 8342647: [macosx] Clean up the NSInvocation based call to NSProcessInfo.operatingSystemVersion

Changes: https://git.openjdk.org/jdk/pull/21595/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21595&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342647
  Stats: 42 lines in 1 file changed: 3 ins; 22 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/21595.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21595/head:pull/21595

PR: https://git.openjdk.org/jdk/pull/21595

From jpai at openjdk.org  Sun Oct 20 06:50:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 20 Oct 2024 06:50:45 GMT
Subject: RFR: 8342647: [macosx] Clean up the NSInvocation based call to
 NSProcessInfo.operatingSystemVersion [v2]
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: <y8fcGtIVCFmPu7LCf0xrA2-cUTEXQxuZztust_zlWk4=.ff2142e8-db17-4084-9297-d8f5494a0937@github.com>

> 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.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  minor code comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21595/files
  - new: https://git.openjdk.org/jdk/pull/21595/files/a824d059..7c402540

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21595&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21595&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21595.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21595/head:pull/21595

PR: https://git.openjdk.org/jdk/pull/21595

From swen at openjdk.org  Sun Oct 20 07:54:43 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 20 Oct 2024 07:54:43 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: <qflWXQL7eXzX2yGuv6qM8ePsK4hNxBsDq4BPqVh14Jg=.d749b01a-bfdd-49b1-8f9f-56dd65797a48@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/9d5a1c38...457735c9

I ran performance tests on MaxBook M1 (aarch64) and aliyun c8a (AMD CPU x64). There was no significant performance difference between pr #19970 and master, but pr #19626 combined with #19970 significantly improved performance.

## Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# master
git checkout 85582d7a88bd5f79f5991ce22bc3bc75e514aec9
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"

# pr 19970
git checkout 3b89956957085e134a05c05876f40b85d949227e
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"

# pr 19626 + 19970
git checkout 58dae7888eceb1c61243f658b67c208e6c30f7f2
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"



## MacBook M1 Max Performance Numbers

# master
Benchmark                             Mode  Cnt  Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  6.950 ? 0.027  ns/op

# pr 19970
Benchmark                             Mode  Cnt  Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  6.945 ? 0.008  ns/op

# pr 19626 + 19970
Benchmark                             Mode  Cnt  Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  6.441 ? 0.059  ns/op



## AMD x64 Performance Numbers

# master
Benchmark                             Mode  Cnt   Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  17.522 ? 8.113  ns/op

# pr 19970
Benchmark                             Mode  Cnt   Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  17.487 ? 8.127  ns/op

# pr 19626 + 19970
Benchmark                             Mode  Cnt  Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  5.983 ? 0.113  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2424709734

From swen at openjdk.org  Sun Oct 20 07:57:19 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 20 Oct 2024 07:57:19 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits
Message-ID: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@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

-------------

Commit messages:
 - fix Helper
 - fix Helper
 - fix Helper
 - unsafe putByte
 - remove digitPair
 - fix import
 - remove JLA
 - remove unused code
 - add comments
 - move getChars to DecimalDigits & deduplicate

Changes: https://git.openjdk.org/jdk/pull/21593/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342650
  Stats: 710 lines in 11 files changed: 334 ins; 352 del; 24 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 Oct 20 10:20:57 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 20 Oct 2024 10:20:57 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v12]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <6WRrQ0EaANr0ODPbcf05ZOipBzW9RyOGRMjBFL0ED7g=.f7d02823-dc4f-46d1-b96f-a056f5ad5828@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Removed redundant JavaDoc section (see CSR discussion)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/487b9386..8b70ac83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=10-11

  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From jpai at openjdk.org  Sun Oct 20 12:12:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 20 Oct 2024 12:12:01 GMT
Subject: RFR: 8340553: ZipEntry field validation does not take into account
 the size of a CEN header [v10]
In-Reply-To: <haJq-wKDxMtbmKMxCQ6DtUWNfF6WfOLo-g3EPLRGafI=.54106d14-5630-4248-baf3-cf9dd5198c62@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
 <haJq-wKDxMtbmKMxCQ6DtUWNfF6WfOLo-g3EPLRGafI=.54106d14-5630-4248-baf3-cf9dd5198c62@github.com>
Message-ID: <H6BTYJczq0QZHlpcAsnPEECKTwijCJEu41CKmCFuuIU=.b9c3ad32-630a-419f-982f-191ab90835d8@github.com>

On Sat, 19 Oct 2024 16:28:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
>> 
>> - ZipEntry(String)
>> - ZipEntry::setComment
>> - ZipEntry::setExtra
>> 
>> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
>> 
>> The CSR has been approved.
>> Mach5 tiers1-3 run clean as do the relevant JCK tests
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added additional clarifiction to isCENHeaderValid comment

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21544#pullrequestreview-2380420089

From duke at openjdk.org  Sun Oct 20 17:36:45 2024
From: duke at openjdk.org (j3graham)
Date: Sun, 20 Oct 2024 17:36:45 GMT
Subject: RFR: 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: <nMwt4NmpoiDF_klnQ099aJNdpPTBv8nFME-HRa6_MHU=.a40e0f1a-f5d3-40b9-b8f0-17317904a94a@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

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[])`, some extra code duplication could be removed. The `offset` could then also be removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21593#discussion_r1807902456

From darcy at openjdk.org  Sun Oct 20 18:59:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 20 Oct 2024 18:59:36 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v2]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <JorANqf8Isn88HntNISamxOrUftRZOckx-hdttzUrlo=.c67e0456-18f9-4f71-b878-7b6b1e9308b1@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:

  Remove comments for intrinsics per review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/c2888ead..18c986db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=00-01

  Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 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  Sun Oct 20 18:59:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 20 Oct 2024 18:59:36 GMT
Subject: RFR: 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: <mJhUb6K8dmMJy9WmWAwA3cINz93AroAefvfEb1CVdEc=.a8a8e91c-5ce6-4114-b522-368279b00517@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.

> Comparing with #21490 we can see that there are more than minimum number of intrinsics I recommended above, but (crucially) the intrinsics are decoupled from the box type, and refactored into `Float16Math.java`.
> 
> https://github.com/openjdk/jdk/pull/21490/files#diff-105a2bf4929174c594b5bcc54f749e93d9fca1b5371ca301fff02badd0e8da5a
> 
> For example, see the max intrinsics line 53. These intrinsics are better structured for the JIT, because there is no extraneous boxing to deal with. (Boxes involve null checks and heap allocation and other details which are just extra overhead.)
> 
> Apart from intrinsic classification, a simpler thing to do that may help the box methods to fold up correctly would be a `@ForceInline` annotation. But for the simple methods in this PR that is usually overkill.

I'm agnostic toward how the intrinsification of Float16 is implemented. I've removed the commented-out intrinsics annotations in a subsequent push. As noted, for review purposes I wanted to have a least one iteration of Float16 in the incubator that was as close as possible to the version of Float16 that has been in use in the lworld+fp16 branch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2425177653

From swen at openjdk.org  Sun Oct 20 19:33:42 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 20 Oct 2024 19:33:42 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits
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: <_2fN85a9qwbM4GKro9_TJ3p1NFvtEPJjW3eU1eu1EtY=.5d759fbe-8643-46a4-afed-a76b6ea19acd@github.com>

On Sun, 20 Oct 2024 17:33:09 GMT, j3graham <duke 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
>
> 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.

If this PR can be merged, we can continue to complete PR #16006, which can also remove DecimalDigits.getChars(? char[])

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21593#discussion_r1807927643

From redestad at openjdk.org  Sun Oct 20 20:22:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 20 Oct 2024 20:22:37 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: <WyjqKR_-RlnicdGJU_DSof0jM0kD4l2JDsSpSzxMWuI=.f22109ef-c318-429e-bd14-2d661381ed41@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/ea332e42...457735c9

Hmm, I would have hoped for `appendNull` the pre-existing code would have allowed for merging stores with #19970. Can you run with `+TraceMergeStores` on the #19970 branch? 

Perhaps we'd need to minimally change from `count++` increments to constant offsets:

            val[count] = 'n';
            val[count + 1] = 'u';
            val[count + 2] = 'l';
            val[count + 3] = 'l';


(I think it would be good to explore if we can to trigger the optimization without resorting to `Unsafe`. Any ideas, @eme64?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2425202938

From darcy at openjdk.org  Sun Oct 20 22:22:34 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 20 Oct 2024 22:22:34 GMT
Subject: RFR: 8342653: Fix minor doc issues in AnnotatedElement
Message-ID: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>

Fix typo and remove redundant `@since` tags.

-------------

Commit messages:
 - JDK-8342653: Fix minor doc issues in AnnotatedElement

Changes: https://git.openjdk.org/jdk/pull/21597/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21597&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342653
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21597.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21597/head:pull/21597

PR: https://git.openjdk.org/jdk/pull/21597

From swen at openjdk.org  Sun Oct 20 22:50:23 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 20 Oct 2024 22:50:23 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: <jZo6Bn4TdF5gHwjA028BvaWUt9Yu6nBS0h-qteJj304=.4c275635-3920-4195-9bcc-e1a1b35dc314@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/d6725bc9...457735c9

Simplifying the implementation of appendNull can improve performance, but it is still not as good as using Unsafe.putByte.


git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# master
git checkout 85582d7a88bd5f79f5991ce22bc3bc75e514aec9
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"

# pr 19970
git checkout 3b89956957085e134a05c05876f40b85d949227e
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"


# pr 19970 + simplify append null
git checkout a43be33a6cc67ac72058d1819ee3008fb6f76211
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"

# pr 19626 + 19970
git checkout 58dae7888eceb1c61243f658b67c208e6c30f7f2
make test TEST="micro:java.lang.StringBuilders.appendWithNull8Latin1"



## MacBook M1 Max Performance Numbers

# master
Benchmark                             Mode  Cnt  Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  6.950 ? 0.027  ns/op

# pr 19970
Benchmark                             Mode  Cnt  Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  6.945 ? 0.008  ns/op

# pr 19970 + simplify append null
Benchmark                             Mode  Cnt  Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  6.766 ? 0.012  ns/op

# pr 19626 + 19970
Benchmark                             Mode  Cnt  Score   Error  Units
StringBuilders.appendWithNull8Latin1  avgt   15  6.441 ? 0.059  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2425269311

From tprinzing at openjdk.org  Mon Oct 21 00:37:38 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 21 Oct 2024 00:37:38 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <a8xRcn4tvBOT00c8_rigs1mMhOIqwnuiDOkZ2Kfsuyo=.b22600ec-a923-4701-877c-355f3e7adfbc@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <a8xRcn4tvBOT00c8_rigs1mMhOIqwnuiDOkZ2Kfsuyo=.b22600ec-a923-4701-877c-355f3e7adfbc@github.com>
Message-ID: <oYshu6aNeS70WC76sPLrLlBIfHt89ZSCW_5EUgvcksU=.573084d8-c07c-4411-8c96-61517b7d8026@github.com>

On Wed, 16 Oct 2024 06:40:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 624:
> 
>> 622:                 SocketConnectEvent.commit(start, duration, isa.getHostString(), address.getHostAddress(), port, connected);
>> 623:             }
>> 624:         }
> 
> Would it be possible to update the JBS or PR description to indicate if the intent is to record an event when the connection cannot be established? I'm asking because the change will only record an event when a connection is successfully established ("connected" is always true here).
> 
> JFR will record exceptions already of course but I think for troubleshooting purposes, recording an event when "connect" hangs and eventually fails is very useful to have.

Capturing all calls even if they threw an exception does seem pretty useful.  I'll update the JBS

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1807983535

From tprinzing at openjdk.org  Mon Oct 21 00:42:39 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 21 Oct 2024 00:42:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <DwZiHEl8KUqlDc4EX2W4ZqPRGF9oJ0iDLNhiRgD1dgI=.191ff669-c0e9-4b67-a38c-101d5d92be27@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <DwZiHEl8KUqlDc4EX2W4ZqPRGF9oJ0iDLNhiRgD1dgI=.191ff669-c0e9-4b67-a38c-101d5d92be27@github.com>
Message-ID: <Rfdwy0-of6TPZh140Hgcwt4Bcn4WEoEYbq40yIIsNQA=.f64a0d69-bae6-4b3f-aaaf-e84cb9842803@github.com>

On Wed, 16 Oct 2024 06:46:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1006:
> 
>> 1004:         boolean connected = implConnect(sa);
>> 1005:         SocketConnectEvent.offer(start, connected, sa);
>> 1006:         return connected;
> 
> It would be useful if the JBS or PR could say what the intent it for SocketChannels that are configured non-blocking. I assume that implConnect will execute in <20ms (the threshold in the JFR config) so no event will be ever be recorded when configured non-blocking. It would be possible to save the timestamp when connecting, and then use in finishConnect but that does depend on timely usage.

The non-blocking case is poorly handled.  I'll update the JBS.  The untimely use of finishConnect would cause an artificially bad looking event duration which might be a bit misleading.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1807984988

From swen at openjdk.org  Mon Oct 21 01:33:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Oct 2024 01:33:50 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: <QBVabrpkxMntc54Nv3aPktxWFl0s9QD93CJZkLVR38c=.be763585-b641-474e-9f44-51a51549532a@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/a86af3e4...457735c9

There is no array out-of-bounds check when using Unsafe. In the appendNull method, there is already a call to ensureCapacityInternal. It is also safe to use Unsafe in this scenario.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2425373747

From jpai at openjdk.org  Mon Oct 21 02:38:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Oct 2024 02:38:13 GMT
Subject: RFR: 8342653: Fix minor doc issues in AnnotatedElement
In-Reply-To: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>
References: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>
Message-ID: <zF9Sv40_WbeGvJR8Eon4xw7pAFMfEv17HUtwfL5e0Pc=.13d49e08-d0ab-4c3a-a7af-f1814ed69e55@github.com>

On Sun, 20 Oct 2024 22:17:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typo and remove redundant `@since` tags.

This looks OK to me. The class itself is commented with `@since 1.5`, so removing it from methods which were introduced in the same release looks correct.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21597#pullrequestreview-2380789181

From iris at openjdk.org  Mon Oct 21 03:04:21 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 21 Oct 2024 03:04:21 GMT
Subject: RFR: 8342653: Fix minor doc issues in AnnotatedElement
In-Reply-To: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>
References: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>
Message-ID: <R1KirOANSWTQI-hs6-hEkks25NKAgWAxkWHDV4rLRI8=.d1700f36-5bc2-4799-a4b5-3d5a185db8af@github.com>

On Sun, 20 Oct 2024 22:17:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typo and remove redundant `@since` tags.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21597#pullrequestreview-2380806433

From ccheung at openjdk.org  Mon Oct 21 05:19:19 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Oct 2024 05:19:19 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option [v2]
In-Reply-To: <4nH8pVUf8BoCEwWAC3RunrTlXCSd5GHDPJg6IIw43R8=.a2826545-e806-4040-869e-25addf4e5967@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
 <MEXuMA7PWvze61-JglQK2hAASioMTgHz59zXFUJQNT0=.a07d3fdb-ced1-44a7-9a21-d29fd7c88c7c@github.com>
 <4nH8pVUf8BoCEwWAC3RunrTlXCSd5GHDPJg6IIw43R8=.a2826545-e806-4040-869e-25addf4e5967@github.com>
Message-ID: <XrXj8FniaIuTgsltC7dZN1q8CbfQph7HZD4T2C6w5Rc=.1a7ca347-0f6d-4254-be0a-6ccb6180b1c5@github.com>

On Fri, 18 Oct 2024 11:26:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @rose00 comment
>
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 467:
> 
>> 465:         if (CDS.isDumpingStaticArchive()
>> 466:                 && !haveUpgradeModulePath
>> 467:                 && (addModules.isEmpty() || addModulesFromRuntimeImage(addModules))
> 
> I think it would be better to check the modules in the Configuration as that is what will be archived. Can you try this, calling addJrt(cf, addModules) where this method is below (it's similar to allJrtOrModularJar that we added recently, not tested btw).
> 
> 
>     /**
>      * Returns true if all modules named in the given set are in the Configuration and
>      * the run-time image.
>      */
>     private static boolean allJrt(Configuration cf, Set<String> moduleNames) {
>         return !moduleNames.stream()
>                 .map(mn -> cf.findModule(mn).orElseThrow())
>                 .map(m -> m.reference().location().orElseThrow())
>                 .anyMatch(uri -> !uri.getScheme().equalsIgnoreCase("jrt"));
>     }

Hi Alan,
I tried your suggestion but it can't handle the `ALL-SYSTEM` case.
I made some slight adjustments to your patch as follows:


    /**
     * Returns true if all modules named in the given set are in the Configuration and
     * the run-time image.
     */
    private static boolean allJrt(Configuration cf, Set<String> moduleNames) {
        if (moduleNames.size() == 1 && moduleNames.contains(ALL_SYSTEM)) {
            return true;
        }
        return !moduleNames.stream()
                .filter(mn -> !mn.equals(ALL_SYSTEM))
                .map(mn -> cf.findModule(mn).orElseThrow())
                .map(m -> m.reference().location().orElseThrow())
                .anyMatch(uri -> !uri.getScheme().equalsIgnoreCase("jrt"));
    }

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21553#discussion_r1808114239

From duke at openjdk.org  Mon Oct 21 05:50:03 2024
From: duke at openjdk.org (Markus KARG)
Date: Mon, 21 Oct 2024 05:50:03 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v12]
In-Reply-To: <6WRrQ0EaANr0ODPbcf05ZOipBzW9RyOGRMjBFL0ED7g=.f7d02823-dc4f-46d1-b96f-a056f5ad5828@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <6WRrQ0EaANr0ODPbcf05ZOipBzW9RyOGRMjBFL0ED7g=.f7d02823-dc4f-46d1-b96f-a056f5ad5828@github.com>
Message-ID: <XrPUUBLFE1_cnJNqGfSrvP4g8UyV9nBrltqM7hZwiW0=.c82d3d18-0f01-4d00-8ee8-75c89c37f763@github.com>

On Sun, 20 Oct 2024 10:20:57 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed redundant JavaDoc section (see CSR discussion)

I have aligned this PR with the latest CSR proposal. Kindly asking for reviews. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2425644337

From alanb at openjdk.org  Mon Oct 21 06:06:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Oct 2024 06:06:01 GMT
Subject: RFR: 8310996: Add JFR event for connect operations
In-Reply-To: <Rfdwy0-of6TPZh140Hgcwt4Bcn4WEoEYbq40yIIsNQA=.f64a0d69-bae6-4b3f-aaaf-e84cb9842803@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <DwZiHEl8KUqlDc4EX2W4ZqPRGF9oJ0iDLNhiRgD1dgI=.191ff669-c0e9-4b67-a38c-101d5d92be27@github.com>
 <Rfdwy0-of6TPZh140Hgcwt4Bcn4WEoEYbq40yIIsNQA=.f64a0d69-bae6-4b3f-aaaf-e84cb9842803@github.com>
Message-ID: <IpFVnaFTZzBwQiXA3Ba9Snur3JdksKvke3eBwlXJXQ0=.436d59c5-25db-4ceb-b83a-b2e186fd9fb7@github.com>

On Mon, 21 Oct 2024 00:39:27 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The non-blocking case is poorly handled. I'll update the JBS. The untimely use of finishConnect would cause an artificially bad looking event duration which might be a bit misleading.

My preference for now would be to focus on the blocking case. Why did my application pause for 30s? The other part to this will be the lookup methods in InetAddress as sometimes the apparent hang isn't establishing the connection but the DNS lookup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1808149416

From jbhateja at openjdk.org  Mon Oct 21 06:26:14 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Oct 2024 06:26:14 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v2]
In-Reply-To: <JorANqf8Isn88HntNISamxOrUftRZOckx-hdttzUrlo=.c67e0456-18f9-4f71-b878-7b6b1e9308b1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <JorANqf8Isn88HntNISamxOrUftRZOckx-hdttzUrlo=.c67e0456-18f9-4f71-b878-7b6b1e9308b1@github.com>
Message-ID: <UUzg4SXRG1jQJr4-VLxm1vsoLjueKiX20SS7ncP2AbY=.319b5b54-6084-420d-8af0-d841cbd2684b@github.com>

On Sun, 20 Oct 2024 18:59:36 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:
> 
>   Remove comments for intrinsics per review feedback.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 970:

> 968:         // of the double -> Float16 conversion also benefits from the
> 969:         // 2p+2 property of IEEE 754 arithmetic.
> 970:         return valueOf(Math.sqrt(radicand.doubleValue()));

Kindly also add a reference to link you shared on lworld+fp16 branch.
https://dl.acm.org/doi/pdf/10.1145/221332.221334

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1808165639

From jbhateja at openjdk.org  Mon Oct 21 06:30:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Oct 2024 06:30:24 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v2]
In-Reply-To: <JorANqf8Isn88HntNISamxOrUftRZOckx-hdttzUrlo=.c67e0456-18f9-4f71-b878-7b6b1e9308b1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <JorANqf8Isn88HntNISamxOrUftRZOckx-hdttzUrlo=.c67e0456-18f9-4f71-b878-7b6b1e9308b1@github.com>
Message-ID: <1scHEaS-_PVk0RWipXMia0KI-AgHyNRK_cyBj5mcff0=.f2f3ccdd-f253-48c6-bd18-3e0000299992@github.com>

On Sun, 20 Oct 2024 18:59:36 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:
> 
>   Remove comments for intrinsics per review feedback.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 968:

> 966:         // for preserving the correct final value. The conversion
> 967:         // Float16 -> double preserves the exact numerical value. The
> 968:         // of the double -> Float16 conversion also benefits from the

Suggestion:

        // Float16 -> double preserves the exact numerical value. The
        // conversion of the double -> Float16 also benefits from the

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1808171758

From asotona at openjdk.org  Mon Oct 21 06:34:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 21 Oct 2024 06:34:03 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v7]
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: <9o9mcedTfNNbKd8QvsUVwIFAYC3-y5gPTlGMSYAt4Fk=.ff44e4fb-33d6-404c-8148-21d094f26615@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 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/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=06
  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 stefank at openjdk.org  Mon Oct 21 07:07:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 07:07:53 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
Message-ID: <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>

On Fri, 18 Oct 2024 20:09:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
>> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
>> 
>> **Review Notes:**
>> 
>> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
>> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
>> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
>> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
>> 
>> **Rough Edges:**
>> 
>> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
>> - If the identity is significant for a static field in a complex class, but not a...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added ClaimMetadataVisitingOopIterateClosure::assert_is_pending_aot_linked_class()

src/hotspot/share/memory/iterator.hpp line 177:

> 175: class ClaimMetadataVisitingOopIterateClosure : public OopIterateClosure {
> 176:  private:
> 177:   static void assert_is_pending_aot_linked_class(Klass* k) NOT_DEBUG_RETURN;

Suggestion:

 private:
  static void assert_is_pending_aot_linked_class(Klass* k) NOT_DEBUG_RETURN;

src/hotspot/share/memory/iterator.inline.hpp line 57:

> 55:     ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
> 56:   } else {
> 57:     assert_is_pending_aot_linked_class(k);

Would there be a drawback to just adding `assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity");` here and skip the changes the both .hpp and .cpp files?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1808211577
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1808213774

From stefank at openjdk.org  Mon Oct 21 07:07:53 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 07:07:53 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <0psOa7CmTMhsD-d_8aQrWvhf6nqqN1WDW336YmXVSUQ=.b7e6a508-6d80-4c6d-a0dd-0dffcce715b9@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <wwJhnPLJIFz4TPtFb6VzjwkKYcHJbrISrjr7UBpmclk=.0c7f010c-4ebe-4264-89c6-c882fcd5d6c4@github.com>
 <cl32fxCpd42uXuouaZHAn6UQ5e9ZsDjiv7DWlxUJHMA=.ba999b6f-2a0a-4e45-923e-80464b6513ff@github.com>
 <Lt-egmoFeE5x34ODYPIT288Y43gj6mehak4PUyvgsT8=.621acc0f-5a75-4e53-ae0b-805968469f99@github.com>
 <0psOa7CmTMhsD-d_8aQrWvhf6nqqN1WDW336YmXVSUQ=.b7e6a508-6d80-4c6d-a0dd-0dffcce715b9@github.com>
Message-ID: <maqAtEmA0mfT3PQyq-wC5ZdM9HcuFStx_lDMF4SQkic=.7daa8474-036e-498c-bfd0-374601649fe5@github.com>

On Fri, 18 Oct 2024 20:09:15 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I filed [JDK-8342429](https://bugs.openjdk.org/browse/JDK-8342429) "Cache classes in loaded state" to address this properly.
>
> I added an assert to limit the cases where the GCs can see null ClassLoaderData from a klass [3f09464](https://github.com/openjdk/jdk/pull/21143/commits/3f094645aae7ba420414121d20787d6a313ed4d0)

Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1808214635

From jlahoda at openjdk.org  Mon Oct 21 07:12:59 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Oct 2024 07:12:59 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <SJjuzK26-rhCkMC5gzPJS92YFHwPmocKzJE47NdWX5w=.0385c992-adfc-4033-ada1-54e54381a479@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <SJjuzK26-rhCkMC5gzPJS92YFHwPmocKzJE47NdWX5w=.0385c992-adfc-4033-ada1-54e54381a479@github.com>
Message-ID: <8l6S_cmWYI9JCVb1QHs0akv_ZPrbqDsZWMUxXp_XuUM=.a2abab13-e2dd-462e-a92c-35328c33bddc@github.com>

On Thu, 17 Oct 2024 00:03:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 49:
> 
>> 47: \    -classpath <class search path of directories and zip/jar files>\n\
>> 48: \    --class-path <class search path of directories and zip/jar files>\n\
>> 49: \                  A "{0}"-separated list of directories, JAR archives,\n\
> 
> The usual way to express this is with the word i.e. comma-separated, semi-colon-separated and colon-separated. Not sure if that is possible given the way substitution happens here. Though you could do what the manpage does i.e.
> 
> Specifies a list of directories, JAR files, and ZIP archives to search for class files.
> On Windows, semicolons (;) separate entities in this list; on other platforms it is a colon (:).

I was looking into this. I don't like the "On windows <this>, otherwise <that>" - the launcher knows where it is running, and should provide the appropriate answer. That's not that big problem, as I think we could inject the platform-specific text in a way that is localizable (basically have keys like `java.launcher.opt.concise.header.classpath.windows` and `java.launcher.opt.concise.header.classpath`, which would contain the whole text for `--class-path`, and inject the localized result into the (concise) help).

I also like a bit to show the symbol, not only say its name. So that non-native speakers don't need to think about the name to symbol mapping. That is also not that big problem - we could say `colon (":")`, or something like that.

But if I try to do this, the lines tend to get longer, and they are already quite long. The current line for the class-path in the concise help has already ~85 characters, and adjusting the line to say "semicolon" is 9 characters just for the word. I am a bit worried the lines may start to wrap in the terminal. (And I don't want to introduce new lines, as that undermines the very purpose of this change: make the concise help short.)

Moreover, the standard help in JDK 23 is printing things like:

    --module-path <module path>...
                  A : separated list of elements, each element is a file path
                  to a module or a directory containing modules. Each module is either
                  a modular JAR or an exploded-module directory.


So, overall, I would say that using the symbol is least problematic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1808220518

From epeter at openjdk.org  Mon Oct 21 07:16:49 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 21 Oct 2024 07:16:49 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <QBVabrpkxMntc54Nv3aPktxWFl0s9QD93CJZkLVR38c=.be763585-b641-474e-9f44-51a51549532a@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
 <QBVabrpkxMntc54Nv3aPktxWFl0s9QD93CJZkLVR38c=.be763585-b641-474e-9f44-51a51549532a@github.com>
Message-ID: <FCc7l-pAMIHHs5nE4ngCVkqofW0R4EjImgtClIxRh74=.da3e668d-ef56-48bc-96ae-6afe89ece325@github.com>

On Mon, 21 Oct 2024 01:29:16 GMT, Shaojin Wen <swen 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 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/25212971...457735c9
>
> There is no array out-of-bounds check when using Unsafe. In the appendNull method, there is already a call to ensureCapacityInternal. It is also safe to use Unsafe in this scenario.

@wenshao @cl4es I've investigated a little with the benchmark.

RangeCheck smearing could be the issue here.

![image](https://github.com/user-attachments/assets/776e8464-3e6d-4725-a6ee-3bcd772ee4e0)

It turns out that RangeChecks are smeared (a kind of elimination in straight-line code) in the same phase as the MergeStores happens (`post_loop_opts_phase`). So it seems to depend on the order of processing in the worklist, if we first remove the RC or try to merge the stores. If a RC is somewhere still stuck between stores, then merging does not quite work as hoped.

Of course if you do it all with `Unsafe`, then those RC are not there any more.

Maybe I can somehow delay the MergeStores a little more. But I have nice solution in mind - only hacks so far ? .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2425810572

From jlahoda at openjdk.org  Mon Oct 21 07:24:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Oct 2024 07:24:57 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <JtMJYJYik7htgVKpeG-FBriWyUfun3OGJ-Sgvxzt3yA=.fe635d22-6455-4e6f-a8dd-ee36c64166e0@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <JtMJYJYik7htgVKpeG-FBriWyUfun3OGJ-Sgvxzt3yA=.fe635d22-6455-4e6f-a8dd-ee36c64166e0@github.com>
Message-ID: <7_G2FUJH6XZYwVugDm7vGpXWeq82UHz1PnnzS0vohvc=.1b41e871-8623-4550-ba8c-659dc5c95332@github.com>

On Thu, 17 Oct 2024 06:02:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 247:
> 
>> 245: \  --module-path <module path>\n\
>> 246: \      a "{0}"-separated list of directories and JAR archives to search for modules\n\n\
>> 247: \For more details about this launcher:   java --help\n\
> 
> Hello Jan, perhaps we should avoid the use of "launcher" here and instead reword it as:
> 
> For additional help on usage: java --help\n\

Sorry, but it feels a bit incomplete - it does not say usage of what. I don't quite see the issue with the word "launcher". The `java` command is a launcher for user programs, is it not?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1808234314

From aturbanov at openjdk.org  Mon Oct 21 07:59:16 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 21 Oct 2024 07:59:16 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v2]
In-Reply-To: <JorANqf8Isn88HntNISamxOrUftRZOckx-hdttzUrlo=.c67e0456-18f9-4f71-b878-7b6b1e9308b1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <JorANqf8Isn88HntNISamxOrUftRZOckx-hdttzUrlo=.c67e0456-18f9-4f71-b878-7b6b1e9308b1@github.com>
Message-ID: <b58NE_Gc9fGLB_IUeSCBAMdds4hu6XbZbO1yXAiFzwE=.b1e03f5f-4cbf-4d4d-aed4-986ecb450498@github.com>

On Sun, 20 Oct 2024 18:59:36 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:
> 
>   Remove comments for intrinsics per review feedback.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 498:

> 496:             }
> 497:             int ql = (int) qb - (P_F16 + 3);
> 498:             BigInteger pow10 =  bigTenToThe(scale);

Suggestion:

            BigInteger pow10 = bigTenToThe(scale);

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1257:

> 1255:     /*package*/ static int getExponent0(short bits) {
> 1256:         // package private to be usable in java.lang.Float.
> 1257:         int bin16ExpBits     = 0x0000_7c00 & bits;     // Five exponent bits.

Suggestion:

        int bin16ExpBits = 0x0000_7c00 & bits;     // Five exponent bits.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1285:

> 1283:         int exp = getExponent(f16);
> 1284: 
> 1285:         return switch(exp) {

Suggestion:

        return switch (exp) {

test/jdk/java/math/BigDecimal/DoubleFloatValueTests.java line 112:

> 110: 
> 111:     private static void checkFloat16(BigDecimal bv, Float16 exp) {
> 112:         Float16 res =  Float16.valueOf(bv); // bv.float16Value();

Suggestion:

        Float16 res = Float16.valueOf(bv); // bv.float16Value();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1808279099
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1808280470
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1808280939
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1808281322

From epeter at openjdk.org  Mon Oct 21 08:01:26 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 21 Oct 2024 08:01:26 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: <sCVIZLCZXFfh4j9e9Sb872iiI-_Urm9flujp6SNN8Rs=.78c69dcc-2816-470a-8f3b-42ecd8367bef@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/a3ecf480...457735c9

Not sure why the RangeCheck smearing issue only appreas here now. Maybe because the graph is bigger? Maybe because of other things in the graph that change the order of things? IDK yet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2425905714

From aturbanov at openjdk.org  Mon Oct 21 08:05:12 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 21 Oct 2024 08:05:12 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
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: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@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 redestad at openjdk.org  Mon Oct 21 08:06:46 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 21 Oct 2024 08:06:46 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <sCVIZLCZXFfh4j9e9Sb872iiI-_Urm9flujp6SNN8Rs=.78c69dcc-2816-470a-8f3b-42ecd8367bef@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
 <sCVIZLCZXFfh4j9e9Sb872iiI-_Urm9flujp6SNN8Rs=.78c69dcc-2816-470a-8f3b-42ecd8367bef@github.com>
Message-ID: <u81QfUraM7jNrJA955pAzCvz8l9Fpvsg0P2orq7IJPk=.54f3e75e-47c3-4e87-9b3f-fca9f35c7be6@github.com>

On Mon, 21 Oct 2024 07:58:42 GMT, Emanuel Peter <epeter 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 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/a510a929...457735c9
>
> Not sure why the RangeCheck smearing issue only appreas here now. Maybe because the graph is bigger? Maybe because of other things in the graph that change the order of things? IDK yet.

Thanks for checking @eme64 - up to you if and when you want to try and tackle such an improvement, if it can be done in a clean way. And as you say there might be other factors at play here. Perhaps things are confounded by how the code is structured before and after; this PR outlines the array stores to a separate method which might affect loop optimization passes if that method is first compiled separately then inlined.

While I don't think the point fix in this PR is all that urgent this has been lingering for a while and I'm sure @wenshao wants to integrate and move on. We can always integrate then back out the `Unsafe` stuff once/if the phases have been disentangled. Or we keep experimenting to try and see if we can get it to behave ideally without `Unsafe` here and now. WDYT? @liach?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2425916432

From duke at openjdk.org  Mon Oct 21 08:29:54 2024
From: duke at openjdk.org (Markus KARG)
Date: Mon, 21 Oct 2024 08:29:54 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v13]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <4SxrVb9ygLjIxUMmxxYXEJm6yx2zzHhx_CYPwYPrNjo=.cb6db295-a1da-4780-aa03-61083c19890f@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Added wording provided by Alan Bateman in CSR discussion: 'The reader is initially opened and reading starts at the first character in the sequence.'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/8b70ac83..6666f02d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=11-12

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From jbhateja at openjdk.org  Mon Oct 21 08:45:59 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Oct 2024 08:45:59 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v13]
In-Reply-To: <rYakfFq4-q_24ENg0rzIfrkGNGaB9QfWj7_EkPe-weQ=.25d650ef-fed3-4c7c-90d8-2bfabad0c96b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <rJQP7QuteRqAUs2l3jyfoO7fmM5HTeEzmKsJv2S941E=.c9ac736a-ccdb-45da-91a7-ba41ce61bb42@github.com>
 <ItJivQ-L-Qu2_iXAqs8dyB4TxJUcVrkjh9-6I2ODvVc=.36010172-a70e-40de-9323-d151529e2a8c@github.com>
 <Z1U-FnuIZ5lKA5az5OWlhzspF6TvVH_MNoGmCGc6qmM=.878ae363-6731-4b05-9045-0ebe0cd6dbf8@github.com>
 <oYCGy2zI6DxuRcl10rcNlnBa-gBQn3ESJtSNq71UHTw=.be2c925d-5c91-4914-bacc-d3c1beddda6d@github.com>
 <rHYOu1rSW3Iy9CNsYpRuD7hrvUGLmpi0Rutk9GZ9R4A=.750e81f8-c9e3-4746-a958-1f21f32f0805@github.com>
 <rYakfFq4-q_24ENg0rzIfrkGNGaB9QfWj7_EkPe-weQ=.25d650ef-fed3-4c7c-90d8-2bfabad0c96b@github.com>
Message-ID: <C9JDS0SmaOLW7jUCOzMyG2LaK0S_Vw2T5iR6BgG-0AY=.a27b7b69-b9e4-466e-bca6-e0894ec3a756@github.com>

On Thu, 19 Sep 2024 06:28:35 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
>>> > 
>>> > 
>>> > Nomenclature is suggested by Paul.
>>> 
>>> @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
>>> 
>> 
>> It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.
>> 
>> 
>> /**
>>  * The class {@code VectorMath} contains methods for performing
>>  * scalar numeric operations in support of vector numeric operations.
>>  */
>> public final class VectorMath {
>> 
>> 
>> These are referenced by the vector operators e.g.,
>> 
>> 
>>     /** Produce saturating {@code a+b}.  Integral only.
>>      * @see VectorMath#addSaturating(int, int)
>>      */
>>     public static final Binary SADD = binary("SADD", "+", VectorSupport.VECTOR_OP_SADD, VO_NOFP);
>> 
>> 
>> And in addition these methods would be used by any tail computation (and the fallback code).
>> 
>> At the moment we are uncertain whether such operations should reside elsewhere and we did not want to block progress. I am not beholden to the name, but so far i cannot think of a concise alternative.`VectorOperatorMath` is arguably more precise but more verbose.
>
>> > > > Why is this even called `VectorMath`? Because those ops are not at all restricted to vectorization, right?
>> > > 
>> > > 
>> > > Nomenclature is suggested by Paul.
>> > 
>> > 
>> > @PaulSandoz Do you want to limit these **scalar** operations to a class name that implies **vector** use?
>> 
>> It's whatever math functions are required to in support of vector operations (as the JavaDoc indicates) that are not provided by other classes such as the boxed primitives or `java.lang.Math`.
> 
> Ok. I suppose these methods could eventually be moved to `java.lang.Math` or some other `java.lang` class, when the VectorAPI goes out of incubator mode?
> 
> I feel like these saturating operations, and also the unsigned ops could find a more wider use, away from (explicit) vector usage. For example, the saturating operations are nice because they prevent overflows, and in some cases that would be very nice to have readily available.

Hi @eme64 , 

Can you kindly review following changes, rest of the portions are already reviewed and approved.

https://github.com/openjdk/jdk/pull/20507/commits/2b0fa01633875926595656d8dcfd539c334f23a3

https://github.com/openjdk/jdk/pull/20507/commits/c56508899b000b8b1eb6755c901798a2a3685ef5

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2426005754

From epeter at openjdk.org  Mon Oct 21 08:52:20 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 21 Oct 2024 08:52:20 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: <IByj3cPht1FL32x4sr4YpNJPN3g40rwMa5_f5kOfPSg=.bb416a28-4261-4aa0-959a-40ce25c73431@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/f6d711b7...457735c9

I'm not the library guy, so I'm not going to block this PR.
But having good tests and benchmarks are crucial, and very time-consuming to come up with for us compiler engineers. So these examples here are very valuable, and I think the time is not wasted working more on it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2426020938

From epeter at openjdk.org  Mon Oct 21 09:14:34 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 21 Oct 2024 09:14:34 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
Message-ID: <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>

On Fri, 18 Oct 2024 14:56:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replacing flag based checks with CPU feature checks in IR validation test.

Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.

I think these optimizations should be done in a separate PR. I see no reason why they need to be mixed in.

https://github.com/openjdk/jdk/commit/c56508899b000b8b1eb6755c901798a2a3685ef5 The `UMinVNode::Ideal` etc changes with IR rules.

I also cannot easily review just such a diff, it does not let me make comments - so I still have to go find the relevant code in the whole PR.

Some comments on this section:


Node* UMinVNode::Ideal(PhaseGVN* phase, bool can_reshape) {
  bool match1 = in(1)->Opcode() == Op_UMinV || in(1)->Opcode() == Op_UMaxV;
  bool match2 = in(2)->Opcode() == Op_UMinV || in(2)->Opcode() == Op_UMaxV;
  // UMin (UMin(a, b), UMax(a, b))  => UMin(a, b)
  // UMin (UMin(a, b), UMax(b, a))  => UMin(a, b)
  if (match1 && match2) {
    if ((in(1)->in(1) == in(2)->in(1) && in(1)->in(2) == in(2)->in(2)) ||
         (in(1)->in(2) == in(2)->in(1) && in(1)->in(1) == in(2)->in(2))) {
      return new UMinVNode(in(1)->in(1), in(1)->in(2), vect_type());
    }
  }
  return nullptr;
}


What about the reverse case `min(max, min)`? And are we sure we do not need to verify any types in all of these cases? Maybe not - but I'd rather be super sure - not that things get misinterpreted and then folded the wrong way.

I mean if I now approve only that diff, then I still need to approve the whole PR, which means I need to spend a lot of time on everything again. Otherwise, in theory people could smuggle anything in.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2426080652

From jlahoda at openjdk.org  Mon Oct 21 09:41:50 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Oct 2024 09:41:50 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v4]
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: <L44X1jEVDW-Gh-pTRUggRW7OsES4JiXtza7ok9O6JL0=.b3fdef72-eeef-4005-8287-6b7a5d88179f@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` launcher, 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 launcher 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:
> 
> $ java
> 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 single-file program
> 
> Where key java options include:
>   --class-path <class path>
>       a ":"-separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>       a ":"-separated list of directories and JAR archives to search for modules
> 
> For more details about this launcher:   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 two additional commits since the last revision:

 - 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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21411/files
  - new: https://git.openjdk.org/jdk/pull/21411/files/1791840b..5d82312f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=02-03

  Stats: 76 lines in 2 files changed: 14 ins; 2 del; 60 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 rgiulietti at openjdk.org  Mon Oct 21 09:53:57 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Oct 2024 09:53:57 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v48]
In-Reply-To: <8_eviT-0AZjEDucZSR2WfvWHCZRULKOVHlcN0ec5ekA=.c40fc44b-c0fb-4037-ba96-b181d4178a60@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <8_eviT-0AZjEDucZSR2WfvWHCZRULKOVHlcN0ec5ekA=.c40fc44b-c0fb-4037-ba96-b181d4178a60@github.com>
Message-ID: <8R3pQwHoYGfKoiN7dM7bEGiHodua09-wXDRh9-mIJPo=.6e3d7232-c333-457c-8060-5194010181c0@github.com>

On Fri, 18 Oct 2024 08:36:30 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine comments to point out the substructure of the method's contract better

Looks good.
Thanks

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21323#pullrequestreview-2381509381

From duke at openjdk.org  Mon Oct 21 10:02:11 2024
From: duke at openjdk.org (duke)
Date: Mon, 21 Oct 2024 10:02:11 GMT
Subject: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v48]
In-Reply-To: <8_eviT-0AZjEDucZSR2WfvWHCZRULKOVHlcN0ec5ekA=.c40fc44b-c0fb-4037-ba96-b181d4178a60@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
 <8_eviT-0AZjEDucZSR2WfvWHCZRULKOVHlcN0ec5ekA=.c40fc44b-c0fb-4037-ba96-b181d4178a60@github.com>
Message-ID: <7Jo1o95fRrgU4Y9LuddvEw5VH4-pvFH9eI9W5_9pYno=.5dcba651-d406-4418-839f-fc313d9067d6@github.com>

On Fri, 18 Oct 2024 08:36:30 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine comments to point out the substructure of the method's contract better

@fabioromano1 
Your change (at version ae40145e74dfd5f108c53feb0fe986c530bdfaeb) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21323#issuecomment-2426201440

From jlahoda at openjdk.org  Mon Oct 21 10:06:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Oct 2024 10:06:57 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <vLgjIZArIyHJzFREWzeXpRDsefvXFe332RvT9S5Qqio=.aaea196b-155d-41f9-b4f6-02f40d0e9e34@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <vLgjIZArIyHJzFREWzeXpRDsefvXFe332RvT9S5Qqio=.aaea196b-155d-41f9-b4f6-02f40d0e9e34@github.com>
Message-ID: <FCm1X8F64HBoSRE33R9p9LjgvAG9qwkI4IdQHZZSNcY=.504ccff1-66d7-403f-946b-cfa46ed59d42@github.com>

On Thu, 17 Oct 2024 11:48:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `<SourceFile>.java to compile and execute a single-file program`
> 
> This is no more precise since we have [JEP 458: Launch Multi-File Source-Code Programs](https://openjdk.org/jeps/458).

Thanks, using "source-file program":
https://github.com/openjdk/jdk/pull/21411/commits/5d82312f794359aeb34d76a0ce036facf353a5ef

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2426213488

From jlahoda at openjdk.org  Mon Oct 21 10:06:58 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Oct 2024 10:06:58 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <wXJ6T4CGlgh73I5uOA82yLVrDzFmF27uZLKOItV4rT4=.3cabb4f1-4372-48bd-95aa-bba96676e0d0@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <wXJ6T4CGlgh73I5uOA82yLVrDzFmF27uZLKOItV4rT4=.3cabb4f1-4372-48bd-95aa-bba96676e0d0@github.com>
Message-ID: <OSQl54tkPi7j1Ov5J1lGubBrYxicX0sYpkwdjmrZuoo=.a42d492a-ebe0-4c6a-98df-518080f9ecd9@github.com>

On Wed, 16 Oct 2024 18:01:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>
> src/java.base/share/native/libjli/java.c line 1924:
> 
>> 1922:  */
>> 1923: static void
>> 1924: PrintUsage(JNIEnv* env, jboolean doXUsage, jboolean conciseUsage)
> 
> This would be cleaner to replace the booleans with an enum (concise, X, full).
> Since conciseUsage overrides doXusage, then it should preceed Xusage in the argument list.

Thanks. I've attempt to do that here:
https://github.com/openjdk/jdk/pull/21411/commits/1fe578185e5c8f575dabef5c5fb869e93f218c72

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1808470949

From jlahoda at openjdk.org  Mon Oct 21 10:06:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Oct 2024 10:06:57 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <QviCbRGIh2l6AUtWZcfBcxeUAX0NjO75ZfamwT74DeM=.4b98f9b0-6b15-4799-9993-f66bdf7ccae7@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <QviCbRGIh2l6AUtWZcfBcxeUAX0NjO75ZfamwT74DeM=.4b98f9b0-6b15-4799-9993-f66bdf7ccae7@github.com>
Message-ID: <8qmi8V6I-adrt1h1PdblhWhAqvOxqIC-2ZBgpPq1XuU=.b6a8209d-d490-425a-8997-758986db6889@github.com>

On Fri, 18 Oct 2024 14:11:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 240:
> 
>> 238: \  <MainClass>                to execute the main method of a compiled class\n\
>> 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\
> 
> Did you mean to use capitals here? It will look different to the `--help` output where we consistently use all lowercase.

Thanks, using lower case here:
https://github.com/openjdk/jdk/pull/21411/commits/5d82312f794359aeb34d76a0ce036facf353a5ef

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1808471450

From duke at openjdk.org  Mon Oct 21 10:18:38 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 10:18:38 GMT
Subject: Integrated: 8341470: BigDecimal.stripTrailingZeros() optimization
In-Reply-To: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
References: <v1avtKRo_pSF6GV8GMg_l4YT8_6fM69W6EG4_Qn7wzQ=.58881804-222f-412b-8d88-a76466198146@github.com>
Message-ID: <631agswdfZy5EKcAgDvfIKYmVLwOhkKiqJ1stUnTk7c=.a5c9f3c2-81a9-42ea-8a5e-ee7e48ac9000@github.com>

On Thu, 3 Oct 2024 12:29:44 GMT, fabioromano1 <duke at openjdk.org> wrote:

> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses repeated squares trick.

This pull request has now been integrated.

Changeset: 27ef6c9d
Author:    fabioromano1 <51378941+fabioromano1 at users.noreply.github.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27ef6c9df47326508ee9b2b29f2ff4cec6e38377
Stats:     223 lines in 3 files changed: 191 ins; 9 del; 23 mod

8341470: BigDecimal.stripTrailingZeros() optimization

Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/21323

From dholmes at openjdk.org  Mon Oct 21 10:25:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Oct 2024 10:25:45 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <_RnMPEisGbYYRP2gHhMaPFtWTwJWEyVPug509aGhS4A=.96345083-fe0e-44eb-b04a-80c31509ca1c@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2381587767

From dholmes at openjdk.org  Mon Oct 21 10:25:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Oct 2024 10:25:45 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <ETK0SJ0qK5YYVRRyBZ4w8IZoURUghpOo88OlRNPi9mg=.612750f1-232b-49d4-8b0d-cf56a3f4049a@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
 <PXri_GMlMrFJPXuJa76mjVuwfQUoi8TqzewBLZ2pttY=.6ebe227f-4a23-448b-b3fe-efd4e6757122@github.com>
 <eQMsjVsp1REYIeLcv4XF_aHfvf1Qd96Egkmiwdc0Sv4=.2bdb8323-b00d-4311-b753-95023e64aa5b@github.com>
 <UbDUZB2TRPz8PfyLBC62Cn9uXFOtcBdE-pqMnE8MIwk=.82d88d41-79c5-4223-af2b-899d5824d8b2@github.com>
 <7mobQmaGqJ4uzc1XAy6LK6nNvlbVtpRByiay6g538vs=.a51a975a-2dac-4685-a41e-61d28ded59ae@github.com>
 <ETK0SJ0qK5YYVRRyBZ4w8IZoURUghpOo88OlRNPi9mg=.612750f1-232b-49d4-8b0d-cf56a3f4049a@github.com>
Message-ID: <EHHPl1nAVKMJTqi8MdDBg12k4wyV-O0xLvRI_QFc8L8=.f54da6e2-c647-49fd-9a77-b6ada0954af8@github.com>

On Sat, 19 Oct 2024 06:33:01 GMT, ExE Boss <duke at openjdk.org> wrote:

>> `test/hotspot/jtreg/runtime/AccessCheckSuper.java` is one test that fails the super class access check.  @lfoltan may know whether there are more tests besides this one.
>
> This?code was?necessary back?when this?was the?`sun.reflect` package and?it?was not?able to?be?encapsulated (before?modules) to?prevent untrusted class?loaders from?leaking the?`MagicAccessorImpl` class?hierarchy.

Okay ... so such subclass was and remains illegal and is now detected slightly later. That suggests to me this special case was in the wrong place and should have been inside `Reflection::verify_class_access`.

Anyway thanks for clarifying full removal is in fact what we want.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21571#discussion_r1808498120

From viktor.klang at oracle.com  Mon Oct 21 10:54:21 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 21 Oct 2024 10:54:21 +0000
Subject: Streams, parallelization, and OOME.
In-Reply-To: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>
References: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>
Message-ID: <MW4PR10MB5774C64231E4C0A5CE971AF2FF432@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi David,

Stream::spliterator() and Stream::iterator() suffer from inherent limitations (see https://bugs.openjdk.org/browse/JDK-8268483 ) because they attempt to convert push-style streams into pull-style constructs (Iterator, Spliterator). Since the only way to know if there's something to pull is for something to get pushed, but who's doing to pushing (answer: the same one who tries to do the pulling)?

For sequential Streams this is often as problematic, but for parallel streams it's not the caller which evaluates the stream but rather a task-tree submitted to a ForkJoinPool. You can see the implementation here: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/StreamSpliterators.java#L272

As an example, Stream::flatMap(?) had corner cases where its use of Stream::spliterator() would end up not terminating, which was fixed in Java 23: https://github.com/openjdk/jdk/pull/18625
[https://opengraph.githubassets.com/0c04ee3059849e8b8dd4ac103bc00db5b08ff8b3bd56c826c9e7ea86105f4824/openjdk/jdk/pull/18625]<https://github.com/openjdk/jdk/pull/18625>
8196106: Support nested infinite or recursive flat mapped streams by viktorklang-ora ? Pull Request #18625 ? openjdk/jdk<https://github.com/openjdk/jdk/pull/18625>
This PR implements Gatherer-inspired encoding of flatMap that shows that it is both competitive performance-wise as well as improve correctness. Below is the performance of Stream::flatMap (for ref...
github.com




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: Saturday, 19 October 2024 07:54
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Streams, parallelization, and OOME.

Hello Core Libs Dev Team,

I have a file that I am streaming from a service, and I am trying to split into multiple parts based on a certain attribute found on each line. I am sending each part up to a different service.

I am using BufferedReader.lines(). However, I cannot read the whole file into memory because it is larger than the amount of RAM that I have on the machine. So, since I don't have access to Java 22's Preview Gatherers Fixed Window, I used the iterator() method on my stream, wrapped that in another iterator that can grab my batch size worth of data, then built a spliterator from that that I then used to create a new stream. In short, this wrapper iterator isn't Iterator<T>, it's Iterator<List<T>>.

When I ran this sequentially, everything worked well. However, my CPU was low and we definitely have a performance problem -- our team needs this number as fast as we can get. Plus, we had plenty of network bandwidth to spare, so I had (imo) good reason to go use parallelism.

As soon as I turned on parallelism, the stream's behaviour changed completely. Instead of fetching the batch and processing, it started grabbing SEVERAL BATCHES and processing NONE OF THEM. Or at the very least, it grabbed so many batches that it ran out of memory before it could get to processing them.

To give some numbers, this is a 4 core machine. And we can safely hold about 30-40 batches worth of data in memory before crashing. But again, when running sequentially, this thing only grabs 1 batch, processes that one batch, sends out the results, and then start the next one, all as expected. I thought that adding parallelism would simply make it so that we have this happening 4 or 8 times at once.

After a very long period of digging, I managed to find this link.

https://stackoverflow.com/questions/30825708/java-8-using-parallel-in-a-stream-causes-oom-error

Tagir Valeev gives an answer which doesn't go very deep into the "why" at all. And the answer is more directed to the user's specific question as opposed to solving this particular problem.

After digging through a bunch of other solutions (plus my own testing), it seems that the answer is that the engine that does parallelization for Streams tries to grab a large enough "buffer" before doing any parallel processing. I could be wrong, and how large that buffer is? I have no idea.

Regardless, that's about where I gave up and went sequential, since the clock was ticking.

But I still have a performance problem. How would one suggest going about this in Java 8?

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/20241021/10df115b/attachment-0001.htm>

From mcimadamore at openjdk.org  Mon Oct 21 11:06:31 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Oct 2024 11:06:31 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <6t6044s7pqcy0dM-zUTzDTXjd1IVwMoge7ckm9WpvSs=.0f4027e4-f0c3-43cc-9f62-97d51fa446a6@github.com>

On Mon, 14 Oct 2024 12:46:29 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 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 1141:

> 1139:             return true;
> 1140:         } else if (sym.kind == TYP && toplevel != null) {
> 1141:             for (Scope scope : new Scope[] {toplevel.namedImportScope,

I wonder if we could deal with this with a compound scope? (and avoid the loop)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1808556685

From mcimadamore at openjdk.org  Mon Oct 21 11:10:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Oct 2024 11:10:13 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <uD112ODmoRFV9yjnbRButsddn0PrLVQpPACxoSsI604=.d0b48602-d286-4832-9c3e-17428f7fa5d4@github.com>

On Mon, 14 Oct 2024 12:46:29 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 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 454:

> 452:                 // Import on demand.
> 453:                 chk.checkCanonical(imp.selected);
> 454:                 if (tree.staticImport) {

I note a discrepancy here - static imports are reflected in the AST, but module import aren't. This is why we need to pass an extra parameter to this method, I believe. Should we generalize the import tree node to have a bunch of flags?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1808564862

From mcimadamore at openjdk.org  Mon Oct 21 11:15:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Oct 2024 11:15:14 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <uD112ODmoRFV9yjnbRButsddn0PrLVQpPACxoSsI604=.d0b48602-d286-4832-9c3e-17428f7fa5d4@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
 <uD112ODmoRFV9yjnbRButsddn0PrLVQpPACxoSsI604=.d0b48602-d286-4832-9c3e-17428f7fa5d4@github.com>
Message-ID: <zcZ2U7dbPKEM_HMfiu3Ssw_Yqamzy6WpAAgsPdpcM30=.7dd453f1-7811-428c-b49d-ace27ebad1f2@github.com>

On Mon, 21 Oct 2024 11:07:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - Make very sure java.base is completed.
>>  - Keep jdk.internal.javac qualified export from java.base.
>>  - Adding forgotten change.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 454:
> 
>> 452:                 // Import on demand.
>> 453:                 chk.checkCanonical(imp.selected);
>> 454:                 if (tree.staticImport) {
> 
> I note a discrepancy here - static imports are reflected in the AST, but module import aren't. This is why we need to pass an extra parameter to this method, I believe. Should we generalize the import tree node to have a bunch of flags?

Nevermind, I see why you need the flag - the code is building synthetic import statements on the fly, based on the packages exported by a module - and then you need to import these synthetic imports, but remember that they originated from an import module...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1808573586

From mcimadamore at openjdk.org  Mon Oct 21 11:19:50 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 21 Oct 2024 11:19:50 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
Message-ID: <bRfaQwnJwA5RA0qRoBKrXPZpXk2b4tx4Ibwb7CV40Yg=.323e59ca-20e0-4b87-97c7-5f3d75bb6fbd@github.com>

On Mon, 14 Oct 2024 12:46:29 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 15 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - Fixing tests
>  - Adding a separate scope for module imports.
>  - Cleanup.
>  - Make very sure java.base is completed.
>  - Keep jdk.internal.javac qualified export from java.base.
>  - Adding forgotten change.
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a

The changes in the import machinery look good (TypeEnter/Resolve).

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2381722159

From abimpoudis at openjdk.org  Mon Oct 21 11:29:14 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Oct 2024 11:29:14 GMT
Subject: RFR: 8342679: Cleanup PreviewFeature.Feature
Message-ID: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>

After doing a build + bootcycle build confirms that these constants can be removed.

-------------

Commit messages:
 - 8342679: Cleanup PreviewFeature.Feature

Changes: https://git.openjdk.org/jdk/pull/21605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21605&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342679
  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21605/head:pull/21605

PR: https://git.openjdk.org/jdk/pull/21605

From duke at openjdk.org  Mon Oct 21 11:35:02 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 11:35:02 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v5]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <G3lvnk1cd1lV3GtareQzMz9g9mJ7CJwEoxV_BgXjJVo=.4f81c3e7-1d72-46b1-a9f4-ae11256f3be5@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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into patchBigDecimalSqrt
 - Avoid check for null value of this.intVal
 - Demand overflow checks to checkScale()
 - Removed stripZerosToEvenScale to simplify the code
 - Merge branch 'openjdk:master' into patchBigDecimalSqrt
 - Change BigDecimal.sqrt() implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/acbe9927..e7a225be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=03-04

  Stats: 64282 lines in 1266 files changed: 53046 ins; 5940 del; 5296 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 duke at openjdk.org  Mon Oct 21 12:03:24 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 12:03:24 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v6]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <rjhXmV5XtGO-5HQAFa8U2-exdfICASCxHlZAU1MYvvc=.dbf2fe2d-950b-46e1-9553-deb69b7365b3@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:

  Compute sqrt remainder only if needed to round

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/e7a225be..b8a5fe25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=04-05

  Stats: 38 lines in 1 file changed: 12 ins; 7 del; 19 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 ihse at openjdk.org  Mon Oct 21 12:06:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 12:06:07 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v4]
In-Reply-To: <L44X1jEVDW-Gh-pTRUggRW7OsES4JiXtza7ok9O6JL0=.b3fdef72-eeef-4005-8287-6b7a5d88179f@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <L44X1jEVDW-Gh-pTRUggRW7OsES4JiXtza7ok9O6JL0=.b3fdef72-eeef-4005-8287-6b7a5d88179f@github.com>
Message-ID: <HTI_5Inj2lJ53L1BwZnIkzeOlOzbJS-mJj8qj6RgA6s=.5be463e3-d064-4086-8132-a6837b8ef95e@github.com>

On Mon, 21 Oct 2024 09:41:50 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` launcher, 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 launcher 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>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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 two additional commits since the last revision:
> 
>  - 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.

So what does the current output look like now after all adjustments?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2426469910

From jlahoda at openjdk.org  Mon Oct 21 12:06:08 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 21 Oct 2024 12:06:08 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v4]
In-Reply-To: <HTI_5Inj2lJ53L1BwZnIkzeOlOzbJS-mJj8qj6RgA6s=.5be463e3-d064-4086-8132-a6837b8ef95e@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <L44X1jEVDW-Gh-pTRUggRW7OsES4JiXtza7ok9O6JL0=.b3fdef72-eeef-4005-8287-6b7a5d88179f@github.com>
 <HTI_5Inj2lJ53L1BwZnIkzeOlOzbJS-mJj8qj6RgA6s=.5be463e3-d064-4086-8132-a6837b8ef95e@github.com>
Message-ID: <2shjMLQEUQ8_pS813ZEtWfUomWr5P7ZWWSyM1OqvPFY=.d1dec8c8-6d4f-4c5e-b891-337f2f14f971@github.com>

On Mon, 21 Oct 2024 11:59:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> So what does the current output look like now after all adjustments?

Uh, right. Now updated in the description.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2426476144

From duke at openjdk.org  Mon Oct 21 12:10:26 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 12:10:26 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v7]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <nh9fY5WrNrzZCaeIDbVctKvv26C5CODG3x-hP5UUSQY=.2b1de44f-1ff6-4af7-8f50-7f9ac2ceec2b@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:

  Removed trailing whitespaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/b8a5fe25..2731a724

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=05-06

  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 liach at openjdk.org  Mon Oct 21 12:11:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 12:11:19 GMT
Subject: RFR: 8342679: Cleanup PreviewFeature.Feature
In-Reply-To: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
Message-ID: <Zi0T9xSr7vy7CknAu2Vi4rqNMyYvbuFRn_5lyHbeRuM=.59c0800c-13e7-4bc6-9b10-bbff8f14df9a@github.com>

On Mon, 21 Oct 2024 11:23:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> After doing a build + bootcycle build confirms that these constants can be removed.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 67:

> 65:      */
> 66:     public enum Feature {
> 67:         // not used, but required for interim javac to not warn.

Maybe we should update this comment to note their removal depends on the boot JDK version?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21605#discussion_r1808669294

From liach at openjdk.org  Mon Oct 21 12:22:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 12:22:04 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: <WbdFb4tI5nR_o0z5KINmZVdkj9xiRs7y9Ag3wXHgg5k=.883c20fd-7e4c-4a5d-bee5-7f73c995fcbf@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/492ea9a6...457735c9

Thanks for the evaluations. I think we can use this unsafe version for now, and use direct writes once JIT can reliably eliminate bound checks.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19626#pullrequestreview-2381888080

From jbhateja at openjdk.org  Mon Oct 21 12:25:37 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Oct 2024 12:25:37 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Factor out IR tests and Transforms to follow-up PRs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/dacc9313..7506ac14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=29-30

  Stats: 595 lines in 4 files changed: 0 ins; 595 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Mon Oct 21 12:29:03 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 21 Oct 2024 12:29:03 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
Message-ID: <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>

On Mon, 21 Oct 2024 09:12:25 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replacing flag based checks with CPU feature checks in IR validation test.
>
> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.
> 
> I think these optimizations should be done in a separate PR. I see no reason why they need to be mixed in.
> 
> https://github.com/openjdk/jdk/commit/c56508899b000b8b1eb6755c901798a2a3685ef5 The `UMinVNode::Ideal` etc changes with IR rules.
> 
> I also cannot easily review just such a diff, it does not let me make comments - so I still have to go find the relevant code in the whole PR.
> 
> Some comments on this section:
> 
> 
> Node* UMinVNode::Ideal(PhaseGVN* phase, bool can_reshape) {
>   bool match1 = in(1)->Opcode() == Op_UMinV || in(1)->Opcode() == Op_UMaxV;
>   bool match2 = in(2)->Opcode() == Op_UMinV || in(2)->Opcode() == Op_UMaxV;
>   // UMin (UMin(a, b), UMax(a, b))  => UMin(a, b)
>   // UMin (UMin(a, b), UMax(b, a))  => UMin(a, b)
>   if (match1 && match2) {
>     if ((in(1)->in(1) == in(2)->in(1) && in(1)->in(2) == in(2)->in(2)) ||
>          (in(1)->in(2) == in(2)->in(1) && in(1)->in(1) == in(2)->in(2))) {
>       return new UMinVNode(in(1)->in(1), in(1)->in(2), vect_type());
>     }
>   }
>   return nullptr;
> }
> 
> 
> Are we sure we do not need to verify any types in all of these cases? Maybe not - but I'd rather be super sure - not that things get misinterpreted and then folded the wrong way.
> 
> I mean if I now approve only that diff, then I still need to approve the whole PR, which means I need to spend a lot of time on everything again. Otherwise, in theory people could smuggle anything in.

Hey @eme64 ,

> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.

I understand reviewer's pain, which is why I mentioned about last two changes specifically. Vector API related PRs generally looks bulky due to script generated sources and tests. Barring that it may not demand much of your time.

But, to keep you motivated :-) and following @PaulSandoz and yours suggestions, I have moved out IR validations and Min / Max transforms to following follow up PRs.
   
   - https://bugs.openjdk.org/browse/JDK-8342676 (https://github.com/openjdk/jdk/pull/21604)
   - https://bugs.openjdk.org/browse/JDK-8342677 (https://github.com/openjdk/jdk/pull/21603)

Can you kindly run this though your test infrastructure and approve if it goes fine ?

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2426527459

From swen at openjdk.org  Mon Oct 21 12:51:04 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Oct 2024 12:51:04 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: <Ui0vDxbOcfvRb_6I0SnlUAJTZMLM99mDr9wiFKERzRQ=.27133128-c04e-4037-a3bf-677212fec0bd@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/02b43061...457735c9

This PR requires PR #19970 to support Unsafe.putByte MergeStore for better performance. I will add more test scenarios to TestMergeStores.java or MergeStoreBench later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2426575966

From liach at openjdk.org  Mon Oct 21 13:00:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 13:00:11 GMT
Subject: RFR: 8342653: Fix minor doc issues in AnnotatedElement
In-Reply-To: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>
References: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>
Message-ID: <HeIR2nnuNn5XGHCkyTc35rYgNcjIgCt58_IH7TR0PCg=.9901a2fe-b851-42d2-ae35-37d099c2aa66@github.com>

On Sun, 20 Oct 2024 22:17:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typo and remove redundant `@since` tags.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21597#pullrequestreview-2382003608

From ihse at openjdk.org  Mon Oct 21 13:03:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:03:20 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v4]
In-Reply-To: <L44X1jEVDW-Gh-pTRUggRW7OsES4JiXtza7ok9O6JL0=.b3fdef72-eeef-4005-8287-6b7a5d88179f@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <L44X1jEVDW-Gh-pTRUggRW7OsES4JiXtza7ok9O6JL0=.b3fdef72-eeef-4005-8287-6b7a5d88179f@github.com>
Message-ID: <jCbaH4dezspmHfML6OpSjxibVhxHOV_64mvaUXiIwkM=.67f86792-f09b-4769-bbc8-6dcb04e96377@github.com>

On Mon, 21 Oct 2024 09:41:50 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` launcher, 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 launcher 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>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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 two additional commits since the last revision:
> 
>  - 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.

I think this looks really good.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21411#pullrequestreview-2382023377

From ihse at openjdk.org  Mon Oct 21 13:10:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:10:29 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <iP9XRtTeh8wPBqtj-o6JGhHkRqZTia-qt9ghVH0E0Iw=.31a75e2b-b453-4e8f-956d-2ce6c86a39ac@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>
Message-ID: <PcJxaNFB6UcGSbywAdz0OLCnSp_tYi_zBJdd4gtUQ78=.f56e03b4-3984-4f3c-a4b5-a1cd12847ff7@github.com>

On Fri, 18 Oct 2024 18:23:13 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
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1808787882

From alanb at openjdk.org  Mon Oct 21 13:20:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Oct 2024 13:20:17 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option [v2]
In-Reply-To: <XrXj8FniaIuTgsltC7dZN1q8CbfQph7HZD4T2C6w5Rc=.1a7ca347-0f6d-4254-be0a-6ccb6180b1c5@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
 <MEXuMA7PWvze61-JglQK2hAASioMTgHz59zXFUJQNT0=.a07d3fdb-ced1-44a7-9a21-d29fd7c88c7c@github.com>
 <4nH8pVUf8BoCEwWAC3RunrTlXCSd5GHDPJg6IIw43R8=.a2826545-e806-4040-869e-25addf4e5967@github.com>
 <XrXj8FniaIuTgsltC7dZN1q8CbfQph7HZD4T2C6w5Rc=.1a7ca347-0f6d-4254-be0a-6ccb6180b1c5@github.com>
Message-ID: <IcYaZzoR8TI1bDbVt_S_axnK6hxtnhYpG-pP1qYgQPg=.7f915220-4f8b-4c80-a486-ccc0ad0d14b7@github.com>

On Mon, 21 Oct 2024 05:15:50 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 467:
>> 
>>> 465:         if (CDS.isDumpingStaticArchive()
>>> 466:                 && !haveUpgradeModulePath
>>> 467:                 && (addModules.isEmpty() || addModulesFromRuntimeImage(addModules))
>> 
>> I think it would be better to check the modules in the Configuration as that is what will be archived. Can you try this, calling addJrt(cf, addModules) where this method is below (it's similar to allJrtOrModularJar that we added recently, not tested btw).
>> 
>> 
>>     /**
>>      * Returns true if all modules named in the given set are in the Configuration and
>>      * the run-time image.
>>      */
>>     private static boolean allJrt(Configuration cf, Set<String> moduleNames) {
>>         return !moduleNames.stream()
>>                 .map(mn -> cf.findModule(mn).orElseThrow())
>>                 .map(m -> m.reference().location().orElseThrow())
>>                 .anyMatch(uri -> !uri.getScheme().equalsIgnoreCase("jrt"));
>>     }
>
> Hi Alan,
> I tried your suggestion but it can't handle the `ALL-SYSTEM` case.
> I made some slight adjustments to your patch as follows:
> 
> 
>     /**
>      * Returns true if all modules named in the given set are in the Configuration and
>      * the run-time image.
>      */
>     private static boolean allJrt(Configuration cf, Set<String> moduleNames) {
>         if (moduleNames.size() == 1 && moduleNames.contains(ALL_SYSTEM)) {
>             return true;
>         }
>         return !moduleNames.stream()
>                 .filter(mn -> !mn.equals(ALL_SYSTEM))
>                 .map(mn -> cf.findModule(mn).orElseThrow())
>                 .map(m -> m.reference().location().orElseThrow())
>                 .anyMatch(uri -> !uri.getScheme().equalsIgnoreCase("jrt"));
>     }
> 
> What do you think?

Good point as ALL-SYSTEM and ALL-MODULE-PATH are allowed in the value. I assume you don't need to special case the single value case as this is dump time so not performance critical.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21553#discussion_r1808807468

From ihse at openjdk.org  Mon Oct 21 13:20:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:20:21 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <HqG0Q7lavlhlPNp6BJKIori-X7CHK7hfbZ5TPyMCsa0=.b19903ef-b490-4909-8142-37da8d5b9ffc@github.com>

On Tue, 15 Oct 2024 20:22:52 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:
> 
>   Don't hardcode server variant

When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.

I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.

@jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2426658524

From dfuchs at openjdk.org  Mon Oct 21 13:32:28 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 13:32:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <RR8acwmQK7Tsg7HTc70yDPcGNetx4ATXhqTt3W0A_kA=.73aff4cf-e9f3-4846-87d8-1866a60c4c74@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Thanks for the changes in JMX and java.logging. Looks good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2382119997

From weijun at openjdk.org  Mon Oct 21 13:40:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Oct 2024 13:40:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
 <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
 <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>
Message-ID: <-Bc_cBbnZLLWUhNTjFI_T-LLSRXSnDUS-EnV0DTQwVc=.460efd25-1595-4ff6-a262-3c1c90c7ebd0@github.com>

On Fri, 18 Oct 2024 19:52:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.
>
> See the changes I made in https://github.com/openjdk/jdk/pull/21498/commits/9dd59a12e984c347a34a25e6fd820340b1e12505. Sometimes it is difficult to remove all text about granting the permission, which is why we added the API note in all Permission subclasses stating that the permission can no longer be used to protect resources.

I see. I was wondering why some files are modified and some are not. The new text looks fine to me. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1808841888

From hannesw at openjdk.org  Mon Oct 21 13:50:33 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 21 Oct 2024 13:50:33 GMT
Subject: RFR: 8342698: Fix order of @param tags in module java.base
Message-ID: <87VIj4OcE0lx0zDcCOaY9VOm8iM7IGpNY-263N1VR8g=.cc5c7935-a1ac-4348-836b-9fdebb867816@github.com>

Please review a doc-only change to fix the order of javadoc `@param` tags in module java.base.

We are working on a javadoc feature to add an opt-in doclint warning for `@param` tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the `@param` tag, i.e. parameters of executable elements, type parameters, and record components.

-------------

Commit messages:
 - JDK-8342698: Fix order of @param tags in module java.base

Changes: https://git.openjdk.org/jdk/pull/21611/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21611&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342698
  Stats: 33 lines in 6 files changed: 15 ins; 15 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21611/head:pull/21611

PR: https://git.openjdk.org/jdk/pull/21611

From duke at openjdk.org  Mon Oct 21 13:54:34 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 21 Oct 2024 13:54:34 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v7]
In-Reply-To: <eetIJK_Hp8RLbJZV26k5xzoFDw74CNGojMUi8hYP42o=.3b489cf6-ba06-4f39-acae-5e05f11aaa5a@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <eetIJK_Hp8RLbJZV26k5xzoFDw74CNGojMUi8hYP42o=.3b489cf6-ba06-4f39-acae-5e05f11aaa5a@github.com>
Message-ID: <-QwWd8iR7BNDfeM0YZ3hRC5t5uwb21ZUov4oNiCKYwE=.28ed175f-604d-4289-96cf-75acf853e696@github.com>

On Fri, 18 Oct 2024 12:37:10 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:
> 
>   Move `serialPersistentFields` for a degree of method order consistency

The test failures seem unrelated, if I'm reading these logs correctly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2426747861

From swen at openjdk.org  Mon Oct 21 13:56:24 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Oct 2024 13:56:24 GMT
Subject: RFR: 8342700: Set the default value of DirectCodeBuilder::handlers to
 Null
Message-ID: <UixH_h-vr-2b7ehqzcGwjHzEkmWt8A3K4BElRV79CtY=.8067cb40-cfad-4cfa-9f34-642e1d8d0031@github.com>

Set the default value of DirectCodeBuilder::handlers to Null to reduce overhead in scenarios where there is no handler.

-------------

Commit messages:
 - handlers default null

Changes: https://git.openjdk.org/jdk/pull/21598/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21598&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342700
  Stats: 19 lines in 3 files changed: 14 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21598/head:pull/21598

PR: https://git.openjdk.org/jdk/pull/21598

From duke at openjdk.org  Mon Oct 21 14:13:35 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 21 Oct 2024 14:13:35 GMT
Subject: RFR: 8341028: Do not use lambdas or method refs for
 verifyConstantPool [v3]
In-Reply-To: <FsTP-X06HUL3eDlMFrhuUmhDqTE8tDHVs-SQmAYxLoI=.c4ac6459-2f0f-4726-9c99-a0213a9b88d1@github.com>
References: <FsTP-X06HUL3eDlMFrhuUmhDqTE8tDHVs-SQmAYxLoI=.c4ac6459-2f0f-4726-9c99-a0213a9b88d1@github.com>
Message-ID: <M4I_dOoOKmXMU75CFHc8ergIE4otv4SY3O2rfVDiGiY=.b14a486b-9a1e-47c2-96cc-888ac8b5ec79@github.com>

> Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a `Runnable`, which is consumed by a `Consumer<Runnable>` (instantiated within a loop) which runs the task inside if a `try`/`catch`. We can eliminate a number of lambdas and method references, plus some allocation pressure, in this code by simplifying it so that the `switch` is itself run directly within the `try`/`catch`.

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 two commits:

 - Make sure that we record every error instead of stopping at the first error in a particular CPE
 - 8341028: Do not use lambdas or method refs for verifyConstantPool
   
   Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a `Runnable`, which is consumed by a `Consumer<Runnable>` (instantiated within a loop) which runs the task inside if a `try`/`catch`. We can eliminate a number of lambdas and method references, plus some allocation pressure, in this code by simplifying it so that the `switch` is itself run directly within the `try`/`catch`.

-------------

Changes: https://git.openjdk.org/jdk/pull/21209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21209&range=02
  Stats: 80 lines in 1 file changed: 38 ins; 10 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/21209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21209/head:pull/21209

PR: https://git.openjdk.org/jdk/pull/21209

From abimpoudis at openjdk.org  Mon Oct 21 14:22:39 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Oct 2024 14:22:39 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v2]
In-Reply-To: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
Message-ID: <fiIkJ4OMRZYDJj01pLrONG5khI0rg-0hUfIi3XX9jsM=.697c65cb-5879-437b-b9cb-902ecc6084b7@github.com>

> After doing a build + bootcycle build confirms that these constants can be removed.

Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - Update comment
 - 8342679: Clean up PreviewFeature.Feature

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21605/files
  - new: https://git.openjdk.org/jdk/pull/21605/files/8c948d22..0ff12dac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21605&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21605&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21605/head:pull/21605

PR: https://git.openjdk.org/jdk/pull/21605

From liach at openjdk.org  Mon Oct 21 14:24:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 14:24:14 GMT
Subject: RFR: 8342700: Set the default value of DirectCodeBuilder::handlers
 to Null
In-Reply-To: <UixH_h-vr-2b7ehqzcGwjHzEkmWt8A3K4BElRV79CtY=.8067cb40-cfad-4cfa-9f34-642e1d8d0031@github.com>
References: <UixH_h-vr-2b7ehqzcGwjHzEkmWt8A3K4BElRV79CtY=.8067cb40-cfad-4cfa-9f34-642e1d8d0031@github.com>
Message-ID: <UbMUuYIGscsIosI9DKlbMbwqi5u7t3vXNwZXjJdEqsw=.35dee433-e1a8-4a3c-940e-6755f46eb601@github.com>

On Sun, 20 Oct 2024 23:15:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Set the default value of DirectCodeBuilder::handlers to Null to reduce overhead in scenarios where there is no handler.

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 805:

> 803:     public List<AbstractPseudoInstruction.ExceptionCatchImpl> getHandlers() {
> 804:         if (handlers == null) {
> 805:             return Collections.emptyList();

We prefer using `List.of()` now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21598#discussion_r1808923520

From liach at openjdk.org  Mon Oct 21 14:28:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 14:28:11 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v2]
In-Reply-To: <fiIkJ4OMRZYDJj01pLrONG5khI0rg-0hUfIi3XX9jsM=.697c65cb-5879-437b-b9cb-902ecc6084b7@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
 <fiIkJ4OMRZYDJj01pLrONG5khI0rg-0hUfIi3XX9jsM=.697c65cb-5879-437b-b9cb-902ecc6084b7@github.com>
Message-ID: <9mU4A27EpOH-_Bw16No2S1TfjTBxxnTpwtYQ3xWalWg=.8216b367-e142-452e-847b-d6f39b64fd2c@github.com>

On Mon, 21 Oct 2024 14:22:39 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After doing a build + bootcycle build confirms that these constants can be removed.
>
> Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:
> 
>  - Update comment
>  - 8342679: Clean up PreviewFeature.Feature

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 70:

> 68:         // keeping the constant of a feature that has been integrated or dropped, serves the purpose of muting such warnings.
> 69: 
> 70:         ////

Suggestion:

        //---

Don't accidentally write markdown javadoc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21605#discussion_r1808928576

From rgiulietti at openjdk.org  Mon Oct 21 14:30:55 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Oct 2024 14:30:55 GMT
Subject: RFR: 8342693: Use byte[] as parameter in a FDBigInteger constructor
 and as field
Message-ID: <gzOKfNXTQsz4DJbzP-0egyolmftcZ7zurKuy7eEjzfE=.c2251e8d-0496-4946-8c9c-22b88d5132dd@github.com>

This helps in reducing memory consumption, especially for long inputs.

-------------

Commit messages:
 - Adjusted test to make use of byte[].
 - 8342693: Use byte[] as parameter in a FDBigInteger constructor and as field

Changes: https://git.openjdk.org/jdk/pull/21614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342693
  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21614/head:pull/21614

PR: https://git.openjdk.org/jdk/pull/21614

From rgiulietti at openjdk.org  Mon Oct 21 14:30:55 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Oct 2024 14:30:55 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: <vUkkt886MvChGBYoNhzAVAv8QD22Yw3PzVb4EzSb6Rs=.32a039e9-b21e-4daf-b9df-0695f3317923@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 is the first PR of a series aimed at reducing overall CPU and memory consumption in string->floating-point conversions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21614#issuecomment-2426844226

From jwaters at openjdk.org  Mon Oct 21 14:40:23 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 21 Oct 2024 14:40:23 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120
Message-ID: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@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. This will require reviews from core-libs, awt, security, accessibility, jpackage, and whatever team is responsible for HotSpot debugging.

This fix requires C++17, so it will have to wait for the switch to C++17. I will be working towards that in the meantime and addressing the issues that come with changing the language standard elsewhere. This will only go in once the JDK actually starts using C++17

-------------

Commit messages:
 - Compile as C++17
 - 8342682

Changes: https://git.openjdk.org/jdk/pull/21616/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342682
  Stats: 72 lines in 25 files changed: 25 ins; 1 del; 46 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 Oct 21 14:40:24 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 21 Oct 2024 14:40:24 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <LZtYVTd3u1froQc3jZweznA55vX035SkX99tP0sR4Lk=.dd2f388b-b79c-4a01-a7ec-f86370221779@github.com>

On Mon, 21 Oct 2024 14:34:30 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. This will require reviews from core-libs, awt, security, accessibility, jpackage, and whatever team is responsible for HotSpot debugging.
> 
> This fix requires C++17, so it will have to wait for the switch to C++17. I will be working towards that in the meantime and addressing the issues that come with changing the language standard elsewhere. This will only go in once the JDK actually starts using C++17

src/java.desktop/share/native/common/awt/debug/debug_trace.h line 66:

> 64: /* each file includes this flag indicating module trace status */
> 65: #ifdef __cplusplus
> 66: [[maybe_unused]]

I don't particularly like this one, but I haven't managed to find a cleaner solution. This is because a static global in a header is not great to begin with. It's practically begging for an unused-variable error to happen

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1808952439

From abimpoudis at openjdk.org  Mon Oct 21 14:49:34 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 21 Oct 2024 14:49:34 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v3]
In-Reply-To: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
Message-ID: <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>

> After doing a build + bootcycle build confirms that these constants can be removed.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21605/files
  - new: https://git.openjdk.org/jdk/pull/21605/files/0ff12dac..8b778aff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21605&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21605&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21605/head:pull/21605

PR: https://git.openjdk.org/jdk/pull/21605

From swen at openjdk.org  Mon Oct 21 14:52:55 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 21 Oct 2024 14:52:55 GMT
Subject: RFR: 8342700: Set the default value of DirectCodeBuilder::handlers
 to Null [v2]
In-Reply-To: <UixH_h-vr-2b7ehqzcGwjHzEkmWt8A3K4BElRV79CtY=.8067cb40-cfad-4cfa-9f34-642e1d8d0031@github.com>
References: <UixH_h-vr-2b7ehqzcGwjHzEkmWt8A3K4BElRV79CtY=.8067cb40-cfad-4cfa-9f34-642e1d8d0031@github.com>
Message-ID: <JqvpTBjqIUSxpSFCw8mHA8PrymHRGxbpX0M1Xkz5zMw=.54e7ed6c-d1e9-4b13-b738-540bb870da5a@github.com>

> Set the default value of DirectCodeBuilder::handlers to Null to reduce overhead in scenarios where there is no handler.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  List.of

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21598/files
  - new: https://git.openjdk.org/jdk/pull/21598/files/a4ef57af..f9114bd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21598&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21598&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21598/head:pull/21598

PR: https://git.openjdk.org/jdk/pull/21598

From liach at openjdk.org  Mon Oct 21 14:57:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 14:57:24 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v3]
In-Reply-To: <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
 <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>
Message-ID: <CWwLkCyGuMhGg0p07nfGUk5mxzbpQDgEWi--u7RTeTA=.9f922c23-e557-479c-95d4-9ee247687133@github.com>

On Mon, 21 Oct 2024 14:49:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After doing a build + bootcycle build confirms that these constants can be removed.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Thanks Aggelos, this change looks good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21605#pullrequestreview-2382376964

From weijun at openjdk.org  Mon Oct 21 14:57:39 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Oct 2024 14:57:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <ytYO_77QWIG71O6PlwBm-HJ_k6VqU2-p3Gg56o98SPI=.7e182f8b-45cb-4bd4-83ce-1e5090e3020d@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

The security-related test updates seem good to me. I noticed a few minor issues and pushed three commits (https://github.com/openjdk/jdk-sandbox/commit/807eb6e363cd78f7051ab2512fbb9fe7f72a036c, https://github.com/openjdk/jdk-sandbox/commit/b4f68e36260cba4cb9e3f72e86674666ee04f15b, and https://github.com/openjdk/jdk-sandbox/commit/02b4bf177555eaf2fa732e918448af9ff1efa8bf).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2426923546

From darcy at openjdk.org  Mon Oct 21 15:17:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 15:17:21 GMT
Subject: Integrated: 8342653: Fix minor doc issues in AnnotatedElement
In-Reply-To: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>
References: <oBJlIdduNFVqEWWQdCHu4Uol8HcNjklJcIxiqIbv0Mw=.373f52c0-c7a2-4d36-8b70-57bddf830719@github.com>
Message-ID: <b-oRbENwAfGQnDGDquJjxzcClaTK35LyMWr5YIVu6Vs=.a079f583-7733-4198-a1cc-2a220a4fab60@github.com>

On Sun, 20 Oct 2024 22:17:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typo and remove redundant `@since` tags.

This pull request has now been integrated.

Changeset: 18b55cea
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18b55ceaa44baabdfce8dcfa1cd6b3e3bdc9df1a
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8342653: Fix minor doc issues in AnnotatedElement

Reviewed-by: jpai, iris, liach

-------------

PR: https://git.openjdk.org/jdk/pull/21597

From lancea at openjdk.org  Mon Oct 21 15:37:28 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 21 Oct 2024 15:37:28 GMT
Subject: Integrated: 8340553: ZipEntry field validation does not take into
 account the size of a CEN header
In-Reply-To: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
References: <e6bb6KHuB0qjbmEAWAK5JzqyzfuRdPubCuwE6mEVQJk=.5a9490e5-764b-4a28-80a0-3ebaf32760da@github.com>
Message-ID: <SmBW_ra5fOe5WotNEZ6Yv3Fu8l2XLJ8-j3v3dfIuOtc=.849b938d-4d70-4b67-a9e2-8bd66c0faffc@github.com>

On Wed, 16 Oct 2024 17:40:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review the changes for [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which addresses that
> 
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
> 
> currently validate that the max possiible field size is 0xFFFF(65535) instead of  0xFFD1(65489) not taking into account the size of the CEN header which is 46 bytes per the PKWare APP.NOTE 4.4.10, 4.4.11, & 4.4.12 
> 
> The CSR has been approved.
> Mach5 tiers1-3 run clean as do the relevant JCK tests

This pull request has now been integrated.

Changeset: 54a744b0
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54a744b0235ab2987f2e9c78fb5326b15233d176
Stats:     423 lines in 4 files changed: 228 ins; 187 del; 8 mod

8340553: ZipEntry field validation does not take into account the size of a CEN header

Reviewed-by: jpai, redestad, eirbjo

-------------

PR: https://git.openjdk.org/jdk/pull/21544

From dfuchs at openjdk.org  Mon Oct 21 15:41:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 15:41:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <LgcZ50hJkMyYZe-v5naaW8WmGArxPnhYHfk6SaGqNO0=.a3d70032-1ca1-4e70-af37-40dfb2f52ddf@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

For the record I have also reviewed the `java.naming` and `jdk.httpserver` source changes. They look good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2427040743

From duke at openjdk.org  Mon Oct 21 15:44:58 2024
From: duke at openjdk.org (Markus KARG)
Date: Mon, 21 Oct 2024 15:44:58 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v14]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Fixed wording according to CSR discussion: '<p> The reader is initially open and reading starts at the first character in the sequence.'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/6666f02d..a668f24e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From pchilanomate at openjdk.org  Mon Oct 21 15:45:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:45:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
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: <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@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:

 - Adjust spacing in test JfrEvents.java
 - Adjust comment in JavaThread.hpp
 - RISC-V: Avoid return misprediction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/6a81ccdc..8c196acd

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: 16 lines in 7 files changed: 2 ins; 1 del; 13 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 Oct 21 15:49:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:49:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
 <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>
Message-ID: <b52WbjxNH3fHsSRkdt_2lAtyr-lznkZjp4zBrh4QLGU=.9951c7b2-9dbe-433b-8e75-20ba49b57dc0@github.com>

On Fri, 18 Oct 2024 04:21:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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_r1809072960

From pchilanomate at openjdk.org  Mon Oct 21 15:49:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:49:23 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@github.com>
Message-ID: <wr2gUUNCp_fXQM_ggvjcOSk72PpT3vWBYDmeoL1Bsog=.6c894146-0c97-4989-8613-14ddd1153fef@github.com>

On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Adjust spacing in test JfrEvents.java
>>  - Adjust comment in JavaThread.hpp
>>  - RISC-V: Avoid return misprediction
>
> 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 duke at openjdk.org  Mon Oct 21 15:56:27 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 15:56:27 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v2]
In-Reply-To: <JFchYTt6qVtzaYCwt6O_pM4aetCTWhee4l_psP8VSVU=.dfa6e368-ffd9-4c41-a2c7-98dff4aa0a4e@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <bg7EvWF1v6Kf-V8R3T-tYvNpXeHhxGs2_NbRSik8bdY=.110f3117-7eea-4b47-b23e-c5bd3a0105eb@github.com>
 <JFchYTt6qVtzaYCwt6O_pM4aetCTWhee4l_psP8VSVU=.dfa6e368-ffd9-4c41-a2c7-98dff4aa0a4e@github.com>
Message-ID: <7JUd6cORLynd145jbUMaYzFvgAcfw26FNaZtI5lXnVw=.d3ff36d5-998f-4eab-b610-ec6816f4bd1f@github.com>

On Thu, 3 Oct 2024 00:47:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> My initial question is what additional regression test cases should be added to probe the new code.

@rgiulietti @jddarcy This should be the path tree for the test cases of the algorithm, whether `signum == 1`:

If `mc.roundingMode == RoundingMode.UNNECESSARY || mc.precision == 0` (line 2165):
- If the input is an even power of 10:
    - [ ] `result.scale < preferredScale` (line 2174);
    - [ ] `result.scale > preferredScale` (line 2174).
- Otherwise, for both cases `result.scale > preferredScale` (line 2265) and `result.scale < preferredScale` (line 2267):
    - for both cases `(strippedScale & 1) == 0` (line 2188) and `(strippedScale & 1) != 0` (line 2190):
        - [ ] `sqrtRem[1].signum != 0` (line 2200);
        - [ ] `sqrtRem[1].signum == 0 && (mc.precision != 0 && result.precision() > mc.precision)` (line 2200);
        - [ ] `sqrtRem[1].signum == 0 && mc.precision == 0` (line 2200);
        - [ ]  `sqrtRem[1].signum == 0 && (mc.precision != 0 && result.precision() <= mc.precision)` (line 2200).

Otherwise (line 2202):
- [ ] `workingScale != (int) workingScale` (line 2217);
- for both cases `result.scale > preferredScale` (line 2265) and `result.scale < preferredScale` (line 2267):
    - [ ] `mc.roundingMode == RoundingMode.DOWN || mc.roundingMode == RoundingMode.FLOOR` (line 2225);
    - otherwise (line 2227):
        - if `halfWay` (line 2232):
            - [ ] `digit > 5` (line 2239);
            - otherwise:
                - if `digit == 5` (line 2241):
                    - [ ] `mc.roundingMode == RoundingMode.HALF_UP` (line 2242);
                    - otherwise:
                        - [ ] `mc.roundingMode == RoundingMode.HALF_EVEN && sqrt.testBit(0)` (line 2243);
                        - for both cases `mc.roundingMode != RoundingMode.HALF_EVEN` and `!sqrt.testBit(0)`:
                            - [ ] `sqrtRem[1].signum != 0` (line 2245);
                            - [ ] `sqrtRem[1].signum == 0 && working.compareTo(new BigDecimal(workingInt)) != 0` (line 2245);
                            - [ ] `sqrtRem[1].signum == 0 && working.compareTo(new BigDecimal(workingInt)) == 0` (line 2245);
                - [ ] `digit < 5` (line 2241).
        - if `!halfWay` (line 2249):
            - [ ] `sqrtRem[1].signum != 0` (line 2251);
            - [ ] `sqrtRem[1].signum == 0 && working.compareTo(new BigDecimal(workingInt)) != 0` (line 2251);
            - [ ] `sqrtRem[1].signum == 0 && working.compareTo(new BigDecimal(workingInt)) == 0` (line 2251).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2427077593

From duke at openjdk.org  Mon Oct 21 16:00:38 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Oct 2024 16:00:38 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v7]
In-Reply-To: <9o9mcedTfNNbKd8QvsUVwIFAYC3-y5gPTlGMSYAt4Fk=.ff44e4fb-33d6-404c-8148-21d094f26615@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <9o9mcedTfNNbKd8QvsUVwIFAYC3-y5gPTlGMSYAt4Fk=.ff44e4fb-33d6-404c-8148-21d094f26615@github.com>
Message-ID: <doMm2Xlr7u8znabCBkNwAE7ildmYuQyCriNDZLwGZtc=.00a16391-f2a5-43c7-a56d-3158799f13ba@github.com>

On Mon, 21 Oct 2024 06:34:03 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 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/constantpool/DynamicConstantPoolEntry.java
>    #	src/java.base/share/cl...

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

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1809083465

From duke at openjdk.org  Mon Oct 21 16:10:25 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Mon, 21 Oct 2024 16:10:25 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v4]
In-Reply-To: <L44X1jEVDW-Gh-pTRUggRW7OsES4JiXtza7ok9O6JL0=.b3fdef72-eeef-4005-8287-6b7a5d88179f@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <L44X1jEVDW-Gh-pTRUggRW7OsES4JiXtza7ok9O6JL0=.b3fdef72-eeef-4005-8287-6b7a5d88179f@github.com>
Message-ID: <ljOVMf-_vmrrBKHqX95p6XVNwJdr1ef1Cf-Nvw_bGKk=.6626398c-0e3b-408d-ae39-cb690507ca57@github.com>

On Mon, 21 Oct 2024 09:41:50 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` launcher, 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 launcher 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>
>>       a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>       a ":"-separated list of directories and JAR archives to search for modules
>> 
>> For more details about this launcher:   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 two additional commits since the last revision:
> 
>  - 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.

I agree! A suuuuper nit-pick is we have three spaces between columns at the end, but two spaces between columns seemed like enough above. Sorry :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2427110618

From kevinw at openjdk.org  Mon Oct 21 16:12:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 21 Oct 2024 16:12:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <omJgksIX-GqCbQ_Q7xELjlDjaYtk8TlnCfXapHH1EzM=.8baa30f6-5bd9-424b-9cb7-e1e683f04e16@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Reviewing for management, src and test changes look good.

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2382585178

From mark.reinhold at oracle.com  Mon Oct 21 16:14:19 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Mon, 21 Oct 2024 16:14:19 +0000
Subject: New candidate JEP: 493: Linking Run-Time Images without JMODs
Message-ID: <20241021161418.0CD9677ED45@eggemoggin.niobe.net>

https://openjdk.org/jeps/493

  Summary: Reduce the size of the JDK by approximately 25% by enabling
  the jlink tool to create custom run-time images without using the JDK's
  JMOD files.  This feature must be enabled when the JDK is built; it
  will not be enabled by default, and some JDK vendors may choose not to
  enable it.

- Mark

From iris at openjdk.org  Mon Oct 21 16:16:11 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 21 Oct 2024 16:16:11 GMT
Subject: RFR: 8342698: Fix order of @param tags in module java.base
In-Reply-To: <87VIj4OcE0lx0zDcCOaY9VOm8iM7IGpNY-263N1VR8g=.cc5c7935-a1ac-4348-836b-9fdebb867816@github.com>
References: <87VIj4OcE0lx0zDcCOaY9VOm8iM7IGpNY-263N1VR8g=.cc5c7935-a1ac-4348-836b-9fdebb867816@github.com>
Message-ID: <w_lHZ9UF4daH3wa3rC2USLozvvjwVLYjzudcZsNpnKM=.b953193f-fb4d-4bb8-a414-37e24740073d@github.com>

On Mon, 21 Oct 2024 13:45:47 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc `@param` tags in module java.base.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for `@param` tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the `@param` tag, i.e. parameters of executable elements, type parameters, and record components.

Confirmed that these changes simply re-order existing @param tag declarations.

If this corresponds to all the problems in `java.base`, I'm impressed that there are so few of them.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21611#pullrequestreview-2382595089

From shade at openjdk.org  Mon Oct 21 16:24:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 21 Oct 2024 16:24:23 GMT
Subject: RFR: 8342704: GHA: Report truncation is broken after JDK-8341424
Message-ID: <I4BNnx7ZHX6LcmmJCrp8ZOoGl3F9jv9bizvvoD29-4I=.414c7f10-669d-42d7-8704-f38b86461477@github.com>

When GH output is too large, we do not actually truncate it after [JDK-8341424](https://bugs.openjdk.org/browse/JDK-8341424). The error log would be:


Run bash ./.github/scripts/gen-test-results.sh "$GITHUB_STEP_SUMMARY"
./.github/scripts/gen-test-results.sh: line 28: report-utils.sh: No such file or directory
./.github/scripts/gen-test-results.sh: line 97: truncate_summary: command not found

Error: Process completed with exit code 127.
Error: $GITHUB_STEP_SUMMARY upload aborted, supports content up to a size of 1024k, got 1579k. For more information see: https://docs.github.com/actions/using-workflows/workflow-commands-for-github-actions#adding-a-markdown-summary


This is because we import report-utils.sh incorrectly: scripts try to find it in current directory, which is not the same directory where the importing scripts are located. And we never see it in normal cases, because scripts are just eating the errors without any other observable effects.

Additional testing: 
  - [x] GHA checks work with deliberately failing tests

-------------

Commit messages:
 - Revert test hook
 - Test hook
 - Fix

Changes: https://git.openjdk.org/jdk/pull/21617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21617&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342704
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21617/head:pull/21617

PR: https://git.openjdk.org/jdk/pull/21617

From aboldtch at openjdk.org  Mon Oct 21 16:26:27 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 21 Oct 2024 16:26:27 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
Message-ID: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>

On Mon, 21 Oct 2024 15:45:21 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:
> 
>  - Adjust spacing in test JfrEvents.java
>  - Adjust comment in JavaThread.hpp
>  - RISC-V: Avoid return misprediction

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.

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 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 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/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?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2381051930
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_r1808706427
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808809374
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_r1809111830

From ccheung at openjdk.org  Mon Oct 21 16:32:44 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Oct 2024 16:32:44 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option [v3]
In-Reply-To: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
Message-ID: <aiUTLki4hRHV6Spq7ogpjB9fKus9Hs-ivcqlzVBsHZ8=.db41c70d-7876-4a48-9419-817a0614308b@github.com>

> Summary of changes:
> 
> Before dumping info the archive, all the module names from `--add-modules` will be sorted and then concatenated into one string with comma as the separator between module names.
> 
> During runtime, same function will be used to obtain the string in the same format with sorted module names. The string will be compared with the one from the archive to determine if the same module names were specified during dump time.
> 
> ModuleBootstrap.java
>         The `addModulesFromRuntimeImage` method is added to check if the modules in `addModules` are from the runtime image. If any of the modules isn't in the runtime image, archiving will be disabled.
> 
> ArchivedModuleGraph.java
>        The constructor has an addition argument `Set addModules`
>        The `get` method also has an addition argument `Set addModules`. It returns the `archivedModuleGraph` only if both the `mainModule` and the `addModules` are the same as the input arguments.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @AlanBateman comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21553/files
  - new: https://git.openjdk.org/jdk/pull/21553/files/5c2783f7..3d46102a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21553&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21553&range=01-02

  Stats: 41 lines in 1 file changed: 12 ins; 28 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21553.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21553/head:pull/21553

PR: https://git.openjdk.org/jdk/pull/21553

From ccheung at openjdk.org  Mon Oct 21 16:32:44 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Oct 2024 16:32:44 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option [v2]
In-Reply-To: <IcYaZzoR8TI1bDbVt_S_axnK6hxtnhYpG-pP1qYgQPg=.7f915220-4f8b-4c80-a486-ccc0ad0d14b7@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
 <MEXuMA7PWvze61-JglQK2hAASioMTgHz59zXFUJQNT0=.a07d3fdb-ced1-44a7-9a21-d29fd7c88c7c@github.com>
 <4nH8pVUf8BoCEwWAC3RunrTlXCSd5GHDPJg6IIw43R8=.a2826545-e806-4040-869e-25addf4e5967@github.com>
 <XrXj8FniaIuTgsltC7dZN1q8CbfQph7HZD4T2C6w5Rc=.1a7ca347-0f6d-4254-be0a-6ccb6180b1c5@github.com>
 <IcYaZzoR8TI1bDbVt_S_axnK6hxtnhYpG-pP1qYgQPg=.7f915220-4f8b-4c80-a486-ccc0ad0d14b7@github.com>
Message-ID: <o_2MW9hK5TGalHl-IRfyCV4ayQxzsFGXQBmvFpE1gNU=.ea65856a-4a4f-4fde-9d05-4d749dc9960f@github.com>

On Mon, 21 Oct 2024 13:17:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan,
>> I tried your suggestion but it can't handle the `ALL-SYSTEM` case.
>> I made some slight adjustments to your patch as follows:
>> 
>> 
>>     /**
>>      * Returns true if all modules named in the given set are in the Configuration and
>>      * the run-time image.
>>      */
>>     private static boolean allJrt(Configuration cf, Set<String> moduleNames) {
>>         if (moduleNames.size() == 1 && moduleNames.contains(ALL_SYSTEM)) {
>>             return true;
>>         }
>>         return !moduleNames.stream()
>>                 .filter(mn -> !mn.equals(ALL_SYSTEM))
>>                 .map(mn -> cf.findModule(mn).orElseThrow())
>>                 .map(m -> m.reference().location().orElseThrow())
>>                 .anyMatch(uri -> !uri.getScheme().equalsIgnoreCase("jrt"));
>>     }
>> 
>> What do you think?
>
> Good point as ALL-SYSTEM and ALL-MODULE-PATH are allowed in the value. I assume you don't need to special case the single value case as this is dump time so not performance critical.

I've removed the `if` check at the beginning of the method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21553#discussion_r1809136528

From liach at openjdk.org  Mon Oct 21 16:44:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 16:44:44 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v14]
In-Reply-To: <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>
Message-ID: <6wfvFXKOSnZpyXbfGjkzli_efwzm26dUZa2n_6p4dgk=.513f5bde-a5ee-45b1-8975-c14100db2b2d@github.com>

On Mon, 21 Oct 2024 15:44:58 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed wording according to CSR discussion: '<p> The reader is initially open and reading starts at the first character in the sequence.'

The latest revision looks good.

Since I am not a professional reviewer in the IO area, I will require extra reviewer approvals.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2382657543

From rgiulietti at openjdk.org  Mon Oct 21 16:50:25 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Oct 2024 16:50:25 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <4-8HmTeqt_jAN7gxmZQ02rCDnpaFY3mkbLq0ZXE_HQA=.57062632-7331-417a-8870-435f648170f7@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>
Message-ID: <5QiIddOeRC1c6Uu6k29kncwwYaHPihYNzbR8o5YUaQU=.0211e950-0a0c-4f36-944b-39afbe03aebd@github.com>

On Wed, 2 Oct 2024 16:43:11 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?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2427205252

From darcy at openjdk.org  Mon Oct 21 17:02:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 17:02:26 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v2]
In-Reply-To: <UUzg4SXRG1jQJr4-VLxm1vsoLjueKiX20SS7ncP2AbY=.319b5b54-6084-420d-8af0-d841cbd2684b@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <JorANqf8Isn88HntNISamxOrUftRZOckx-hdttzUrlo=.c67e0456-18f9-4f71-b878-7b6b1e9308b1@github.com>
 <UUzg4SXRG1jQJr4-VLxm1vsoLjueKiX20SS7ncP2AbY=.319b5b54-6084-420d-8af0-d841cbd2684b@github.com>
Message-ID: <b2QQ7XLPD_FAqUgJzVZZPgs40veOaDYRYcAt7fAS468=.652b03b8-4df5-4055-96d3-a5894e81a271@github.com>

On Mon, 21 Oct 2024 06:21:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove comments for intrinsics per review feedback.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 970:
> 
>> 968:         // of the double -> Float16 conversion also benefits from the
>> 969:         // 2p+2 property of IEEE 754 arithmetic.
>> 970:         return valueOf(Math.sqrt(radicand.doubleValue()));
> 
> Kindly also add a reference to link you shared on lworld+fp16 branch.
> https://dl.acm.org/doi/pdf/10.1145/221332.221334

That reference is already cited around line 850.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1809179951

From duke at openjdk.org  Mon Oct 21 17:03:43 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Mon, 21 Oct 2024 17:03:43 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v14]
In-Reply-To: <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>
Message-ID: <3XmMc58Yw09rGZUxh49MRD9UzIF8AkEGMgJ68v2-ufk=.f0ac56a8-434f-469a-88c9-a61ee13e18d9@github.com>

On Mon, 21 Oct 2024 15:44:58 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed wording according to CSR discussion: '<p> The reader is initially open and reading starts at the first character in the sequence.'

Will the Reader need to catch IndexOutOfBoundsException and BufferUnderFlowException then wrap them as EOFException? I would think these errors should not escape the Reader as is if a source CharBuffer limit is tampered with.  Or is this not an issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2427258436

From duke at openjdk.org  Mon Oct 21 17:04:24 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 17:04:24 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <5QiIddOeRC1c6Uu6k29kncwwYaHPihYNzbR8o5YUaQU=.0211e950-0a0c-4f36-944b-39afbe03aebd@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>
Message-ID: <ZoVL2aI3sRfDdt1uE0Gd8-GwGmXik6IiapS7Pl-f6Wg=.f3ff26b2-84e0-45ae-bf83-df5a6a910051@github.com>

On Mon, 21 Oct 2024 16:47:36 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...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2427261831

From darcy at openjdk.org  Mon Oct 21 17:07:35 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 17:07:35 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v3]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@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 seven additional commits since the last revision:

 - Add @since tag, respond to review feedback.
 - Merge branch 'master' into JDK-8341260
 - Remove comments for intrinsics per review feedback.
 - Update with changes from lworld+fp16 Float16.
 - Merge branch 'master' into JDK-8341260
 - Add support for BigDecimal -> Float16 conversion.
 - JDK-8341260: Add Float16 to jdk.incubator.vector

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/18c986db..0328e217

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=01-02

  Stats: 4055 lines in 104 files changed: 3381 ins; 486 del; 188 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 liach at openjdk.org  Mon Oct 21 17:09:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 17:09:28 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v14]
In-Reply-To: <3XmMc58Yw09rGZUxh49MRD9UzIF8AkEGMgJ68v2-ufk=.f0ac56a8-434f-469a-88c9-a61ee13e18d9@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>
 <3XmMc58Yw09rGZUxh49MRD9UzIF8AkEGMgJ68v2-ufk=.f0ac56a8-434f-469a-88c9-a61ee13e18d9@github.com>
Message-ID: <4udJymYBv2T-qavcN683i1agExGsVVQkeZdE0Z3JmOQ=.6e24639c-54d0-44a9-8a90-bd6a0640bc1e@github.com>

On Mon, 21 Oct 2024 17:00:55 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed wording according to CSR discussion: '<p> The reader is initially open and reading starts at the first character in the sequence.'
>
> Will the Reader need to catch IndexOutOfBoundsException and BufferUnderFlowException then wrap them as EOFException? I would think these errors should not escape the Reader as is if a source CharBuffer limit is tampered with.  Or is this not an issue?

@jmehrens We have this in our specification:

>  If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.

Thus your scenario is not an issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2427275496

From jlu at openjdk.org  Mon Oct 21 17:11:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 21 Oct 2024 17:11:43 GMT
Subject: RFR: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit [v4]
In-Reply-To: <7OSq5U0fGbrX7rrPjT7wMyNdWMOiKJBXDz7ld2im0Pc=.9e57fa0f-6b9e-4d2b-9b9c-f4ad60cb6b39@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
 <7OSq5U0fGbrX7rrPjT7wMyNdWMOiKJBXDz7ld2im0Pc=.9e57fa0f-6b9e-4d2b-9b9c-f4ad60cb6b39@github.com>
Message-ID: <zibX3C7jXMDiTCO9SOR8PoIjHURM05PMYJbViK3YQqI=.ea8a7a3d-96bd-4639-8d6e-79d00b1cba1d@github.com>

On Fri, 18 Oct 2024 21:05:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
>> 
>> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR review: More precise wording regarding 'this' impl

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21554#issuecomment-2427278436

From jlu at openjdk.org  Mon Oct 21 17:11:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 21 Oct 2024 17:11:43 GMT
Subject: Integrated: 8335271: Specify the MessageFormat ArgumentIndex
 Implementation Limit
In-Reply-To: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
References: <c-hEetweBMc2jFSH6ScAYiKVI23LmC0settwUZ3K1Ww=.4943909e-9a7f-4d67-b91c-2e20b7e23a33@github.com>
Message-ID: <RlY6e5HHsO2ckMtkZNVN6hrtmG_9jQT_QagUQ_F6dew=.a8cad8ad-e244-4db5-a99d-ea78c9f72b1b@github.com>

On Wed, 16 Oct 2024 22:48:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which specifies the _j.text.MessageFormat_ ArgumentIndex limit. A corresponding CSR is drafted.
> 
> Both the existence of the limit (and behavior if violated), as well as this implementation's limit are added to the class description. See the JBS issue comments for further history.

This pull request has now been integrated.

Changeset: 51a7ff65
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51a7ff65949e77c58c66f724e9047ca591e5c6d4
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8335271: Specify the MessageFormat ArgumentIndex Implementation Limit

Reviewed-by: darcy, iris, naoto, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/21554

From duke at openjdk.org  Mon Oct 21 17:14:42 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Mon, 21 Oct 2024 17:14:42 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
Message-ID: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>

8342566: Improve javadoc of java.lang.annotation.ElementType

-------------

Commit messages:
 - 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: https://git.openjdk.org/jdk/pull/21506/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21506&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342566
  Stats: 164 lines in 1 file changed: 113 ins; 5 del; 46 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 duke at openjdk.org  Mon Oct 21 17:14:42 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Mon, 21 Oct 2024 17:14:42 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
Message-ID: <lRCPESzvzmH99d5KGeyqsdFBZz1aiI772NkDkFK3yr8=.0a6008ba-f2b0-4bc0-9470-b24d2260531d@github.com>

On Mon, 14 Oct 2024 20:31:51 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

> 8342566: Improve javadoc of java.lang.annotation.ElementType

Thanks so much Chen! I'm interested in your general thoughts: does it make sense where I have currently "drawn the line", as far as what information belongs in here and what doesn't? I think my goal is to basically answer ~all "where will I be able to put this annotation?" questions without forcing readers to try to read JLS - at least to the extent that those answers may influence which ElementTypes the user includes in their @Target.

The class javadoc is basically a ground-up rewrite, so the fact that it is broken into red/green diff blocks is not going to be too helpful (sorry).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21506#pullrequestreview-2369893862
PR Comment: https://git.openjdk.org/jdk/pull/21506#issuecomment-2412217852

From liach at openjdk.org  Mon Oct 21 17:14:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 17:14:43 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <b6OollVoq8QpW_fyF3o6Ycyr-y0rEXRP6X5Y-N0Cclc=.cfed45d5-fd40-4bbc-84a0-4413a37b3ce9@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
 <kOl948AJNr_s1OR68_jd7-TeaefTZ3xuVqnFuErgh6Q=.7b5797cd-32fb-4bc9-8431-a1ab54d1da55@github.com>
 <b6OollVoq8QpW_fyF3o6Ycyr-y0rEXRP6X5Y-N0Cclc=.cfed45d5-fd40-4bbc-84a0-4413a37b3ce9@github.com>
Message-ID: <4RppVjzRrAxUubAAYKRuT9kqebjZBcuPb07UT9vYu0I=.fb2e738b-95ba-41f2-809c-22c0dd607b2f@github.com>

On Tue, 15 Oct 2024 16:22:36 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/annotation/ElementType.java line 46:
>> 
>>> 44:  * <p>Most annotations in Java code are <b>declaration
>>> 45:  * annotations</b>, which act like modifiers of declarations (such as
>>> 46:  * a field declaration). The constants of this class cover all ten
>> 
>> "such as a field declaration" seems like a carry-over from the old example of `@Target(ElementType.FIELD)`, which is obsolete in the current text. I suggest to remove, or to present a concrete example like "acts like modifiers of decrations, such as the transitive modifier on a field declaration."
>> 
>> The asserted number "ten" might be outdated quickly and forgotten to be updated when we add new declarations such as pattern bindings.
>
> It's meant to help make this more concrete for readers who aren't accustomed to speaking abstractly about "declarations". I've actually expanded it to "field or method" now. I certainly don't want to reference any particular modifier though. Does it work now?
> 
> I do realize that mentioning counts of things of is a pretty dodgy idea, almost "daring" the text to go stale. I could go either way about it but I want to try to defend it for a moment though.
> 
> The first question is whether citing a number like this has any positive value in the first place. This is absolutely subjective and it could just be my own "psychology" speaking only, but I think it lends "concreteness". When I read things like this it gives me more of a feeling of security that I'm really getting the full story and I can count on it. I don't know, I can't claim any more objective benefit than that, really.
> 
> As for the staleness issue, I'd claim that avoiding the numbers would basically mean we're hoping that the text might stay "accidentally current", when really we need to re-review the full text any time anything changes to quite *actively* search for what to freshen up. If a stale number helped us notice that the text hadn't be rethought yet, maybe it would be a good thing...... meh?

Yep, the "field or method declaration" is much clearer. I felt the old text "field declaration" was trying to emphasize the modifier status of annotations.

And for count: that's fair. We bump Java version every six months, too!

>> src/java.base/share/classes/java/lang/annotation/ElementType.java line 227:
>> 
>>> 225:      * RECORD_COMPONENT} or in addition to it. This allows the
>>> 226:      * annotation to be automatically copied to any generated elements
>>> 227:      * it applies to.
>> 
>> Doesn't this effectively become another "ambiguous context?" Note that in both cases, the observation of the annotations via the `class` file format (and subsequently, the core reflection API) is inconsistent.
>
> Well, this is one of the ambiguous contexts listed above. Not sure if I'm reading this right. What's the "inconsistency" you mean?

Say you have a record component like:
`record Sample(@Anno int val)`
Where `@Anno` applies to `RECORD_COMPONENT` and `FIELD`.

Then we can observe this annotation on the record component or its field, but not its getter method. This creates a scenario similar to how people can observe an annotation on both the type-use and the declaration for some common annotations like `@Nullable`, yet some annotations are only present on one of the sites.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1801832808
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1801828565

From liach at openjdk.org  Mon Oct 21 17:14:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 17:14:42 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <lRCPESzvzmH99d5KGeyqsdFBZz1aiI772NkDkFK3yr8=.0a6008ba-f2b0-4bc0-9470-b24d2260531d@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
 <lRCPESzvzmH99d5KGeyqsdFBZz1aiI772NkDkFK3yr8=.0a6008ba-f2b0-4bc0-9470-b24d2260531d@github.com>
Message-ID: <7zSBfQbN8iXJGSp0cclgER6mLO1zvuoD06U5rRcBaqg=.184365e0-18c5-4446-8bee-492b33873a65@github.com>

On Tue, 15 Oct 2024 16:35:19 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

> answer ~all "where will I be able to put this annotation?" questions

I think you've done a great job: the notes on type-use annotations are clear. The only potentially confusing thing left is record component annotations' propagation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21506#issuecomment-2414894583

From duke at openjdk.org  Mon Oct 21 17:14:43 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Mon, 21 Oct 2024 17:14:43 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <kOl948AJNr_s1OR68_jd7-TeaefTZ3xuVqnFuErgh6Q=.7b5797cd-32fb-4bc9-8431-a1ab54d1da55@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
 <kOl948AJNr_s1OR68_jd7-TeaefTZ3xuVqnFuErgh6Q=.7b5797cd-32fb-4bc9-8431-a1ab54d1da55@github.com>
Message-ID: <b6OollVoq8QpW_fyF3o6Ycyr-y0rEXRP6X5Y-N0Cclc=.cfed45d5-fd40-4bbc-84a0-4413a37b3ce9@github.com>

On Tue, 15 Oct 2024 02:10:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 8342566: Improve javadoc of java.lang.annotation.ElementType
>
> src/java.base/share/classes/java/lang/annotation/ElementType.java line 42:
> 
>> 40:  * }
>> 41:  *
>> 42:  * <h2>Declaration annotations and type-use annotations</h2>
> 
> Meta: if we add an explicit id to the h2 tag, people can have a stable link to this subsection instead of having to update their link for each release, as the javadoc tool automatically generates an unstable id.

Good idea. I guess we should always do this.

> src/java.base/share/classes/java/lang/annotation/ElementType.java line 46:
> 
>> 44:  * <p>Most annotations in Java code are <b>declaration
>> 45:  * annotations</b>, which act like modifiers of declarations (such as
>> 46:  * a field declaration). The constants of this class cover all ten
> 
> "such as a field declaration" seems like a carry-over from the old example of `@Target(ElementType.FIELD)`, which is obsolete in the current text. I suggest to remove, or to present a concrete example like "acts like modifiers of decrations, such as the transitive modifier on a field declaration."
> 
> The asserted number "ten" might be outdated quickly and forgotten to be updated when we add new declarations such as pattern bindings.

It's meant to help make this more concrete for readers who aren't accustomed to speaking abstractly about "declarations". I've actually expanded it to "field or method" now. I certainly don't want to reference any particular modifier though. Does it work now?

I do realize that mentioning counts of things of is a pretty dodgy idea, almost "daring" the text to go stale. I could go either way about it but I want to try to defend it for a moment though.

The first question is whether citing a number like this has any positive value in the first place. This is absolutely subjective and it could just be my own "psychology" speaking only, but I think it lends "concreteness". When I read things like this it gives me more of a feeling of security that I'm really getting the full story and I can count on it. I don't know, I can't claim any more objective benefit than that, really.

As for the staleness issue, I'd claim that avoiding the numbers would basically mean we're hoping that the text might stay "accidentally current", when really we need to re-review the full text any time anything changes to quite *actively* search for what to freshen up. If a stale number helped us notice that the text hadn't be rethought yet, maybe it would be a good thing...... meh?

> src/java.base/share/classes/java/lang/annotation/ElementType.java line 57:
> 
>> 55:  * indicated (normally, immediately preceding that type). To enable
>> 56:  * use as a type-use annotation, an annotation interface must
>> 57:  * explicitly include {@link #TYPE_USE} in its list of targets. 
> 
> I would word like `an annotation interface must have a {@code @Target} that includes {@link #TYPE_USE}.` Main issue with existing text is the plain "target" word was undefined previously.

Fixed

> src/java.base/share/classes/java/lang/annotation/ElementType.java line 133:
> 
>> 131:     /** 
>> 132:      * The declaration of a formal parameter (of a method, constructor,
>> 133:      * or lambda expression), exception parameter, or receiver
> 
> Receiver parameters are type-use only; they were only added in Java 8. JLS 9.7.4:
> 
>> **It is a compile-time error if an annotation of interface A is syntactically a modifier for:**
>> - [...]
>> - a receiver parameter, but A is not applicable in type contexts.

Good catch!

> src/java.base/share/classes/java/lang/annotation/ElementType.java line 227:
> 
>> 225:      * RECORD_COMPONENT} or in addition to it. This allows the
>> 226:      * annotation to be automatically copied to any generated elements
>> 227:      * it applies to.
> 
> Doesn't this effectively become another "ambiguous context?" Note that in both cases, the observation of the annotations via the `class` file format (and subsequently, the core reflection API) is inconsistent.

Well, this is one of the ambiguous contexts listed above. Not sure if I'm reading this right. What's the "inconsistency" you mean?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1801503770
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1801532150
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1801516766
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1801505164
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1801511302

From duke at openjdk.org  Mon Oct 21 17:14:43 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Mon, 21 Oct 2024 17:14:43 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <4RppVjzRrAxUubAAYKRuT9kqebjZBcuPb07UT9vYu0I=.fb2e738b-95ba-41f2-809c-22c0dd607b2f@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
 <kOl948AJNr_s1OR68_jd7-TeaefTZ3xuVqnFuErgh6Q=.7b5797cd-32fb-4bc9-8431-a1ab54d1da55@github.com>
 <b6OollVoq8QpW_fyF3o6Ycyr-y0rEXRP6X5Y-N0Cclc=.cfed45d5-fd40-4bbc-84a0-4413a37b3ce9@github.com>
 <4RppVjzRrAxUubAAYKRuT9kqebjZBcuPb07UT9vYu0I=.fb2e738b-95ba-41f2-809c-22c0dd607b2f@github.com>
Message-ID: <PbXyuFEaMW7IawWNAcvsCgbbHcXs_Tjn5U-mBXKRdko=.95568b24-f301-473c-8ec3-106c8321ea3c@github.com>

On Tue, 15 Oct 2024 19:54:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Well, this is one of the ambiguous contexts listed above. Not sure if I'm reading this right. What's the "inconsistency" you mean?
>
> Say you have a record component like:
> `record Sample(@Anno int val)`
> Where `@Anno` applies to `RECORD_COMPONENT` and `FIELD`.
> 
> Then we can observe this annotation on the record component or its field, but not its getter method. This creates a scenario similar to how people can observe an annotation on both the type-use and the declaration for some common annotations like `@Nullable`, yet some annotations are only present on one of the sites.

Okay, I see the connection. I'm trying to think about why I used the word "ambiguous" to talk about the case above. I think there are 2 reasons

1. For purposes of answering "which of the two kinds of annotations is this, anyway?" But in this case, it's not so much that it's ambiguous, it's just that its *both*.
2. Specifically because of the `@DualPurposeAnnot String[] field;` problem. It's maybe "ambiguous" whether this is trying to say something about the field or the _component_ type of the array type.

I think I'll try describing this situation without "ambiguous".

Getting back to record/field, I don't see a problem as long as any annotation interface that targets both kinds doesn't try to document incompatible *meanings* for the two.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1802003932

From liach at openjdk.org  Mon Oct 21 17:14:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Oct 2024 17:14:43 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
Message-ID: <kOl948AJNr_s1OR68_jd7-TeaefTZ3xuVqnFuErgh6Q=.7b5797cd-32fb-4bc9-8431-a1ab54d1da55@github.com>

On Mon, 14 Oct 2024 20:31:51 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

> 8342566: Improve javadoc of java.lang.annotation.ElementType

src/java.base/share/classes/java/lang/annotation/ElementType.java line 42:

> 40:  * }
> 41:  *
> 42:  * <h2>Declaration annotations and type-use annotations</h2>

Meta: if we add an explicit id to the h2 tag, people can have a stable link to this subsection instead of having to update their link for each release, as the javadoc tool automatically generates an unstable id.

src/java.base/share/classes/java/lang/annotation/ElementType.java line 46:

> 44:  * <p>Most annotations in Java code are <b>declaration
> 45:  * annotations</b>, which act like modifiers of declarations (such as
> 46:  * a field declaration). The constants of this class cover all ten

"such as a field declaration" seems like a carry-over from the old example of `@Target(ElementType.FIELD)`, which is obsolete in the current text. I suggest to remove, or to present a concrete example like "acts like modifiers of decrations, such as the transitive modifier on a field declaration."

The asserted number "ten" might be outdated quickly and forgotten to be updated when we add new declarations such as pattern bindings.

src/java.base/share/classes/java/lang/annotation/ElementType.java line 57:

> 55:  * indicated (normally, immediately preceding that type). To enable
> 56:  * use as a type-use annotation, an annotation interface must
> 57:  * explicitly include {@link #TYPE_USE} in its list of targets. 

I would word like `an annotation interface must have a {@code @Target} that includes {@link #TYPE_USE}.` Main issue with existing text is the plain "target" word was undefined previously.

src/java.base/share/classes/java/lang/annotation/ElementType.java line 61:

> 59:  * <h3 id="ambiguous">Ambiguous contexts</h3>
> 60:  *
> 61:  * <p>For six kinds of declarations, type-use annotations can also

Same number assertion remark; pattern bindings most likely will have this same problem too.

src/java.base/share/classes/java/lang/annotation/ElementType.java line 133:

> 131:     /** 
> 132:      * The declaration of a formal parameter (of a method, constructor,
> 133:      * or lambda expression), exception parameter, or receiver

Receiver parameters are type-use only; they were only added in Java 8. JLS 9.7.4:

> **It is a compile-time error if an annotation of interface A is syntactically a modifier for:**
> - [...]
> - a receiver parameter, but A is not applicable in type contexts.

src/java.base/share/classes/java/lang/annotation/ElementType.java line 227:

> 225:      * RECORD_COMPONENT} or in addition to it. This allows the
> 226:      * annotation to be automatically copied to any generated elements
> 227:      * it applies to.

Doesn't this effectively become another "ambiguous context?" Note that in both cases, the observation of the annotations via the `class` file format (and subsequently, the core reflection API) is inconsistent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1800319604
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1800315455
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1800318732
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1800320595
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1800326769
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1800327793

From hannesw at openjdk.org  Mon Oct 21 17:17:19 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 21 Oct 2024 17:17:19 GMT
Subject: RFR: 8342698: Fix order of @param tags in module java.base
In-Reply-To: <87VIj4OcE0lx0zDcCOaY9VOm8iM7IGpNY-263N1VR8g=.cc5c7935-a1ac-4348-836b-9fdebb867816@github.com>
References: <87VIj4OcE0lx0zDcCOaY9VOm8iM7IGpNY-263N1VR8g=.cc5c7935-a1ac-4348-836b-9fdebb867816@github.com>
Message-ID: <kBK8cV0Yi4z-14oaMS_sJ61yvqHvj-xWCWXkoZzkvzU=.604cec11-43b5-48d5-8e7e-e598e1155cf4@github.com>

On Mon, 21 Oct 2024 13:45:47 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc `@param` tags in module java.base.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for `@param` tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the `@param` tag, i.e. parameters of executable elements, type parameters, and record components.

Thanks for the review!

> If this corresponds to all the problems in `java.base`, I'm impressed that there are so few of them.

There are a bit more in other modules, which is why I though it was a good idea to split it up into subtasks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21611#issuecomment-2427289078

From hannesw at openjdk.org  Mon Oct 21 17:17:19 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 21 Oct 2024 17:17:19 GMT
Subject: Integrated: 8342698: Fix order of @param tags in module java.base
In-Reply-To: <87VIj4OcE0lx0zDcCOaY9VOm8iM7IGpNY-263N1VR8g=.cc5c7935-a1ac-4348-836b-9fdebb867816@github.com>
References: <87VIj4OcE0lx0zDcCOaY9VOm8iM7IGpNY-263N1VR8g=.cc5c7935-a1ac-4348-836b-9fdebb867816@github.com>
Message-ID: <WBmpJgz_M1BApYr4OCHtjeuyCl10rDKHfMA8CNwFztI=.0f3cb484-400e-4b2b-8488-6df80f1bf6b8@github.com>

On Mon, 21 Oct 2024 13:45:47 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc `@param` tags in module java.base.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for `@param` tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the `@param` tag, i.e. parameters of executable elements, type parameters, and record components.

This pull request has now been integrated.

Changeset: 97c92128
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97c921284222ca53a293dcebe513fbb59ee9c690
Stats:     33 lines in 6 files changed: 15 ins; 15 del; 3 mod

8342698: Fix order of @param tags in module java.base

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk/pull/21611

From naoto at openjdk.org  Mon Oct 21 17:24:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 21 Oct 2024 17:24:24 GMT
Subject: RFR: 8340477: Remove JDK1.1 compatible behavior for "EST", "MST", 
 and "HST" time zones [v3]
In-Reply-To: <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
 <lk6Zn9eCLxxB0caHXBWOTIfz4-kZK8D8Y8lLgBbmv0w=.987e59d3-a888-4171-b2fa-9a060ac57a0b@github.com>
Message-ID: <HfHZYL6POBP8NwxFxGPwaywXUIvGBhF00Th4_warIvM=.9ca50057-abd3-4622-b5f3-50f93e0cd542@github.com>

On Wed, 16 Oct 2024 19:59:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined it more

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21545#issuecomment-2427301194

From mullan at openjdk.org  Mon Oct 21 17:24:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 21 Oct 2024 17:24:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
Message-ID: <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>

On Sat, 19 Oct 2024 07:54:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.

Fixed, will be in next drop. There are a couple of other micro tests that test the performance of `AccessController.doPrivileged` and `getContext` which probably don't make sense anymore, but I've left them for now to be looked at later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2427301539

From naoto at openjdk.org  Mon Oct 21 17:24:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 21 Oct 2024 17:24:25 GMT
Subject: Integrated: 8340477: Remove JDK1.1 compatible behavior for "EST",
 "MST", and "HST" time zones
In-Reply-To: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
References: <s6Zd9t4tihT0WBxp-83mGMer4GKrZE3oZiSek0x5PtE=.ea6c9527-b1b8-4984-9437-715f09a98c57@github.com>
Message-ID: <BBnefs5M022TyxYKsotupxV4ISneeH6ZXq5msZ5PN8A=.068b7976-b27a-4a50-b889-27cc18a3ba6e@github.com>

On Wed, 16 Oct 2024 17:46:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the old compatibility behavior switch for JDK1.1. With the integration of tzdata2024b, definitions of those three (deprecated) IDs changed again, so maintaining the JDK11 compatibility got less useful. Removing the compatibility behavior makes the code and test simpler. A CSR for the behavior change is drafted too.

This pull request has now been integrated.

Changeset: 71583222
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71583222eb221f2bae480d1f834e48527081691e
Stats:     285 lines in 5 files changed: 1 ins; 276 del; 8 mod

8340477: Remove JDK1.1 compatible behavior for "EST", "MST", and "HST" time zones

Reviewed-by: iris, jlu, joehw

-------------

PR: https://git.openjdk.org/jdk/pull/21545

From duke at openjdk.org  Mon Oct 21 17:32:33 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 17:32:33 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v8]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <wRafx_t_Fro8QmSTvd6J42B8OqAL5ggGCXA35PkseDY=.9795ab65-cca1-4b92-8d8c-b1be7245bd42@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 two additional commits since the last revision:

 - Removed unused variable
 - Ensure the result does not exceed the requested precision
   
   Ensure the result does not exceed the requested precision to fit the preferred scale

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/2731a724..57034fed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=06-07

  Stats: 13 lines in 1 file changed: 5 ins; 2 del; 6 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 rgiulietti at openjdk.org  Mon Oct 21 17:36:16 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Oct 2024 17:36:16 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v8]
In-Reply-To: <wRafx_t_Fro8QmSTvd6J42B8OqAL5ggGCXA35PkseDY=.9795ab65-cca1-4b92-8d8c-b1be7245bd42@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <wRafx_t_Fro8QmSTvd6J42B8OqAL5ggGCXA35PkseDY=.9795ab65-cca1-4b92-8d8c-b1be7245bd42@github.com>
Message-ID: <lR5EatUUvIl7LtFeaa8muwDsnC93ehdtSqYHp_PvlFk=.94cd379b-a1c0-4c1f-b8c2-9da85f75d048@github.com>

On Mon, 21 Oct 2024 17:32:33 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 two additional commits since the last revision:
> 
>  - Removed unused variable
>  - Ensure the result does not exceed the requested precision
>    
>    Ensure the result does not exceed the requested precision to fit the preferred scale

Please make sure that your commits do not break compilation and builds.
[This one](https://github.com/openjdk/jdk/pull/21301/commits/82a4357e947817dfdf25274654d14f5cce00c46d) does not compile.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2427324606

From darcy at openjdk.org  Mon Oct 21 17:36:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 17:36:19 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
Message-ID: <H3S9oCevF2bGr3J1TccJ2Tp2pCnEriJaGJYWloOlgro=.1e73a03c-c3a4-46e9-bd48-466a63dda3fd@github.com>

On Mon, 14 Oct 2024 20:31:51 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

> 8342566: Improve javadoc of java.lang.annotation.ElementType

src/java.base/share/classes/java/lang/annotation/ElementType.java line 63:

> 61:  * <h3 id="ambiguous">Ambiguous contexts</h3>
> 62:  *
> 63:  * <p>For six kinds of declarations, type-use annotations can also

The GitHub UI isn't letting me reply directly to the relevant existing comment. In any case, I strongly advise against referring to concrete numbers for language contexts in the JLS. As noted, that is a hazard for the comments getting out of date with language changes or previewing language changes. The JLS text does favor use of such numbers, but the JLS as a whole is in the same maintenance domain so there is a much higher chance that when adding another context, all the N's in the JLS get updated to (N+1)'s.

src/java.base/share/classes/java/lang/annotation/ElementType.java line 79:

> 77:  * (like {@link java.lang.reflect.Field#getAnnotations}) will not
> 78:  * return type-use annotations found in the same location, and
> 79:  * vice-versa.

If type annotations are going to be discussed, it would be helpful to readers to include something along the lines of "in core reflection, type annotations can are retrieved by methods that return AnnotatedType."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1809223497
PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1809226800

From darcy at openjdk.org  Mon Oct 21 17:41:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 17:41:19 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
Message-ID: <Myy9PawA5HjXUWIx-9dFLUV6tJ3e9GJwxR4BGoxQu54=.c820915f-cc3c-4de0-bb64-f712d370d539@github.com>

On Mon, 14 Oct 2024 20:31:51 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

> 8342566: Improve javadoc of java.lang.annotation.ElementType

src/java.base/share/classes/java/lang/annotation/ElementType.java line 118:

> 116:      * on the declaration of a record component, and is automatically
> 117:      * copied to the private field of the same name that is generated
> 118:      * during compilation.

If there is a JLS citation for this behavior, please include it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21506#discussion_r1809232916

From darcy at openjdk.org  Mon Oct 21 17:44:19 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 17:44:19 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
In-Reply-To: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
Message-ID: <K1QTYOw6u4fvn1K2fRFrHp00GRxom61GJgxeVVhcVAc=.751dcdbd-fda9-4298-8f8e-54efd4a8d8a7@github.com>

On Mon, 14 Oct 2024 20:31:51 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

> 8342566: Improve javadoc of java.lang.annotation.ElementType

With an update in this spirit, some mention of `Constructror.getAnnotatedReceiverType()` would be helpful too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21506#issuecomment-2427340508

From naoto at openjdk.org  Mon Oct 21 17:49:33 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 21 Oct 2024 17:49:33 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v4]
In-Reply-To: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
Message-ID: <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>

> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21569/files
  - new: https://git.openjdk.org/jdk/pull/21569/files/9000280b..805365c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=02-03

  Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21569/head:pull/21569

PR: https://git.openjdk.org/jdk/pull/21569

From naoto at openjdk.org  Mon Oct 21 17:52:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 21 Oct 2024 17:52:14 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v3]
In-Reply-To: <Fdua2qIELjn-tPGA0ZR3Bob1ZM9LR2Jc3H6MPp1wJmY=.399017b6-b1af-4df2-80e5-68122dc7016b@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <2SfZK99Gmi9-wuuAl6B4jrgc-QUeqbUaYbVmdVYibCY=.bc9fedbc-0ef1-471d-a3c0-4a8e913c4217@github.com>
 <Fdua2qIELjn-tPGA0ZR3Bob1ZM9LR2Jc3H6MPp1wJmY=.399017b6-b1af-4df2-80e5-68122dc7016b@github.com>
Message-ID: <Ubhod02h9N5ASUm9UQCgtN1w4rpvCVwL4_TjY_apq7Q=.bde1b23f-270e-4610-9804-f1ff3dba70fe@github.com>

On Sat, 19 Oct 2024 07:10:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Explicitly refer to `stdout.encoding`
>
> src/java.base/share/classes/java/io/Console.java line 584:
> 
>> 582:      * The returned charset corresponds to the input and output source
>> 583:      * (e.g., keyboard and/or display) specified by the host environment or user,
>> 584:      * which defaults to the one based on {@link System##stdout.encoding stdtout.encoding}.
> 
> In System.getProperties, this is specified for as the encoding for System.out. That may need to be expanded to say Console too.

Added `System.console()` mention to `stdout.encoding`. Also removed `Console` mention from `System.out`, as it no longer provides extra meaning.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21569#discussion_r1809245944

From vromero at openjdk.org  Mon Oct 21 18:00:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 21 Oct 2024 18:00:17 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v3]
In-Reply-To: <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
 <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>
Message-ID: <NJ1kA2s5gYMRDafFlhNCi2zBhn5tRoguIvpEDkGlhxQ=.b5f223ca-78a1-47e6-be66-702989164680@github.com>

On Fri, 4 Oct 2024 00:02:52 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 incrementally with one additional commit since the last revision:
> 
>   Migrate another use of sun.misc.Unsafewq

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19397#pullrequestreview-2382925864

From duke at openjdk.org  Mon Oct 21 18:02:41 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 18:02:41 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v9]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <DL6pxbNLFNKG-HR5oJIvhidQzO_1bOaBTySZWalJaes=.1378314e-f179-4b4f-9922-91d6749f07d7@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:

  Do round up with ulp in the final result
  
  Do round up with ulp in the final result to ensure the result does not exceed the requested precision

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/57034fed..571507af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=07-08

  Stats: 12 lines in 1 file changed: 3 ins; 4 del; 5 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 iris at openjdk.org  Mon Oct 21 18:04:15 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 21 Oct 2024 18:04:15 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v4]
In-Reply-To: <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
Message-ID: <1-bcCd2LozfUFWxbesQaarfa3Xv5YEudxRK9VRv-RrQ=.47550cbc-069d-4ec2-a9a2-eb738ee17495@github.com>

On Mon, 21 Oct 2024 17:49:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21569#pullrequestreview-2382945880

From mbalao at openjdk.org  Mon Oct 21 18:30:50 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 21 Oct 2024 18:30:50 GMT
Subject: RFR: 8315487: Security Providers Filter [v9]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <KCl1GCy11MAYdSIVlLQ3P5aVA7r2G-mxixox7ahr9Do=.87cc6cee-369a-48d4-abe2-c8f02b9a7656@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 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>

-------------

Changes: https://git.openjdk.org/jdk/pull/15539/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=08
  Stats: 5234 lines in 25 files changed: 4603 ins; 353 del; 278 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 duke at openjdk.org  Mon Oct 21 18:50:55 2024
From: duke at openjdk.org (fabioromano1)
Date: Mon, 21 Oct 2024 18:50:55 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v10]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <kLKOXLve90nAcw_sjNkM2kNwZOYy2IFi3S2ZKmpUQu0=.837e5ec2-e981-4742-afac-d9574b6b89fa@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:

  Ensure no increase of precision in 99...9+1 cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/571507af..5cd590c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=08-09

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 duke at openjdk.org  Mon Oct 21 19:03:22 2024
From: duke at openjdk.org (duke)
Date: Mon, 21 Oct 2024 19:03:22 GMT
Subject: Withdrawn: 8328995: Launcher can't open jar files where the offset of
 the manifest is >4GB
In-Reply-To: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
Message-ID: <yrONO-pU3Ol1r_FxK44VZGXLlQNM04yrjanBzRqkeao=.c1be98eb-b7e9-4e2e-b3c4-6a686cd908a2@github.com>

On Mon, 25 Mar 2024 21:37:03 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18479

From dl at openjdk.org  Mon Oct 21 20:19:58 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 21 Oct 2024 20:19:58 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v3]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <Fh6Cfs5HsptHpdROehbG16Wp6mT-ThL0EqrhRCN5NAU=.e3b25b07-41f1-4a5a-9cd5-3253fbf61139@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 19 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336707
 - adjust type tests
 - Better disinguish need for exhaustive scans
 - Consistent constructions; remove no-longer needed checks; update internal docs
 - Reconcile constuctions
 - Fencing
 - experiment
 - Merge branch 'openjdk:master' into JDK-8336707
 - Reactivation
 - Recheck
 - ... and 9 more: https://git.openjdk.org/jdk/compare/4e057aad...0bf0bfa0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/0e3e9def..0bf0bfa0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=01-02

  Stats: 124555 lines in 967 files changed: 116531 ins; 4015 del; 4009 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 almatvee at openjdk.org  Mon Oct 21 20:20:16 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 21 Oct 2024 20:20:16 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v4]
In-Reply-To: <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
 <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>
Message-ID: <SdKYC4lEu4xg069HCwKDBtbwvut3tINpHOkMmgmJ1mM=.32613a74-9b78-488c-ad73-3dd3c676e28c@github.com>

On Fri, 18 Oct 2024 14:42:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make jpackage correctly handle the output directory (`--dest`) that is:
>>  - a subdirectory of the input directory;
>>  - the same as the input directory.
>> 
>> Make jpackage correctly handle temp directory (`--temp`) that is:
>>  - a subdirectory of the input directory.
>> 
>> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
>> 
>> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
>> 
>> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
>> 
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
>> 
>> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files.isSameFile() throws exception if a file doesn't exist

Do we need to check various combinations for similar issues, but for `--app-content` and `--mac-dmg-content`? Both of these options are used to copy files from destination to app bundle or DMG image.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21550#issuecomment-2427634294

From iklam at openjdk.org  Mon Oct 21 20:34:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 20:34:54 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v11]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <C380NMLhJ_bpgd6TE5M-I0NdtCwvXnIPRssuCb6oqi0=.413c9d00-e5e5-4010-9055-ad2fc6f3f819@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @stefank comment -- changed to assert(is_pending_aot_linked_class(k), "sanity")

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/3f094645..bdba2b66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=09-10

  Stats: 15 lines in 4 files changed: 2 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Mon Oct 21 20:34:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 20:34:54 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
 <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
Message-ID: <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>

On Mon, 21 Oct 2024 07:03:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added ClaimMetadataVisitingOopIterateClosure::assert_is_pending_aot_linked_class()
>
> src/hotspot/share/memory/iterator.inline.hpp line 57:
> 
>> 55:     ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
>> 56:   } else {
>> 57:     assert_is_pending_aot_linked_class(k);
> 
> Would there be a drawback to just adding `assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity");` here and skip the changes the both .hpp and .cpp files?

I changed the code to `assert(is_pending_aot_linked_class(k), "sanity")`. Since iterator.hpp is widely used, I avoid including aotLinkedClassBulkLoader.hpp in this header, and route the call through iterator.cpp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809487525

From vromero at openjdk.org  Mon Oct 21 20:38:29 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 21 Oct 2024 20:38:29 GMT
Subject: RFR: 8342679: Clean up PreviewFeature.Feature [v3]
In-Reply-To: <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
 <SjZwPM2b8SttIwOAqpKbuGfgW1Zw-dJVnOeMImpR9W0=.932bd71e-d4c7-42ae-8980-b3eab797cbc1@github.com>
Message-ID: <OzKoqfXxuV9C4keBLVbuKd2EPNv0LLRlYX4eZwGmP44=.465f49f1-9538-49e8-ac21-106f68e69f2a@github.com>

On Mon, 21 Oct 2024 14:49:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> After doing a build + bootcycle build confirms that these constants can be removed.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21605#pullrequestreview-2383257496

From iklam at openjdk.org  Mon Oct 21 20:47:08 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 20:47:08 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v10]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <l3f_pmOI3Z8bPaz6QcFS5mgmrKb8k0i1ji35OMar8LU=.fae30b06-d985-4d6c-b010-107b66deb81b@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @iwanowww comment: no need for @Stable for USE_SOFT_CACHE; use final instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/11391c39..a9ae70e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From prr at openjdk.org  Mon Oct 21 21:24:30 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Oct 2024 21:24:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 55:

> 53:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest false w.policy
> 54:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest false rw.policy
> 55:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest true rwd.policy

Looks to me like we should delete these 3 policy files.
Also this test isn't about Permissions anymore. So should be renamed to CacheUsedTest 
Then we can get rid of the misspelt directory. in a follow up.Probably do this

test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:

> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
> 75: 
> 76:         if (args.length > 1) {

The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?

Also the messing around with exceptions at the end of the test is pointless

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809540920
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809544420

From iklam at openjdk.org  Mon Oct 21 21:58:39 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 21:58:39 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v12]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <gPFtTrXg-Kq-yklTDLd5u159H-UqwOsi87LcUO0I0oo=.11accaf6-0e0d-46a6-b5e6-e73c275c3bca@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - dholmes-ora comment - removed direct_only parameter from InstanceKlass::is_enum_subclass()
 - In respond to @ashu-mehra review: add comment about why the main module name needs to be lifted out of MetaspaceShared::serialize()
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - @stefank comment -- changed to assert(is_pending_aot_linked_class(k), "sanity")
 - Added ClaimMetadataVisitingOopIterateClosure::assert_is_pending_aot_linked_class()
 - @rose00 comments -- tighten up the checks for what can or cannot be aot-inited; removed is_trivial_clinit() as it is used only in logging but the meaning is unclear
 - @liach comments -- added comments; added asserts for HashMap safety in MethodType.java
 - Fixed typo in last commit; fixed header inclusion order
 - @DanHeidinga comments -- added comments and asserts related to ClassLoaderData used by archived hidden classes
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - ... and 29 more: https://git.openjdk.org/jdk/compare/a9ae70e2...044f28a7

-------------

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=11
  Stats: 2729 lines in 73 files changed: 2387 ins; 144 del; 198 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Mon Oct 21 21:58:39 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 21:58:39 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <H9zBs7z0MHZsdJ2ufOwuGDaA_ccTbE3vaZbRLUWSU1g=.c8dab9ef-5963-4bff-b9b9-b134fb4152c2@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
 <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>
 <H9zBs7z0MHZsdJ2ufOwuGDaA_ccTbE3vaZbRLUWSU1g=.c8dab9ef-5963-4bff-b9b9-b134fb4152c2@github.com>
Message-ID: <eQWogONr__xT9ru7QPG-qLF2C1Kmx8rXJcuv8kFSoNA=.7ffb5eee-9cd0-4f60-8fbc-06892650359e@github.com>

On Fri, 18 Oct 2024 02:19:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> ```
> +bool InstanceKlass::is_enum_subclass(bool direct_only) const {
> +  InstanceKlass* s = java_super();
> +  return (s == vmClasses::Enum_klass() ||
> +          (s != null && s->java_super() == vmClasses::Enum_klass()));
> +}
> ```
> 
> Just happened to notice you aren't checking `direct_only`.

I consulted with John and removed the `direct_only` parameter as it's no longer needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2427815518

From almatvee at openjdk.org  Mon Oct 21 22:00:15 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 21 Oct 2024 22:00:15 GMT
Subject: RFR: 8342609: jpackage test helper function incorrectly removes a
 directory instead of its contents only
In-Reply-To: <l6DyfD0KC3hruoyIdozFp0iDlZktByR79zPG3ecxpug=.8b41340d-4e9a-4ac1-8389-f846af4e7642@github.com>
References: <l6DyfD0KC3hruoyIdozFp0iDlZktByR79zPG3ecxpug=.8b41340d-4e9a-4ac1-8389-f846af4e7642@github.com>
Message-ID: <osKPPDsstI3N-loRhcnLRje1NMhj7PwuZLZxEtDBcPg=.71e8fac8-01ef-4404-9391-5d7ac0c75df7@github.com>

On Fri, 18 Oct 2024 13:45:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> `Files.walk(root, 0)` returns the `root` itself and not the contents of the `root`.
> Replaced `Files.walk(root, 0)` with `Files.list(root)` to get a non-recursive listing of the `root` directory.

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21582#pullrequestreview-2383379068

From iklam at openjdk.org  Mon Oct 21 22:04:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 22:04:25 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v8]
In-Reply-To: <eQWogONr__xT9ru7QPG-qLF2C1Kmx8rXJcuv8kFSoNA=.7ffb5eee-9cd0-4f60-8fbc-06892650359e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <SPvJMeNNeAonaNA8KadD2dSuQ_4OXqNSe1Skxdt0OAc=.9b1e5dbc-d611-47b1-92cb-e74889e58419@github.com>
 <OWSzUMuPDdjeBz4LStPyFcHX6BLvmdYwInPocqzWnHE=.389e363f-b735-48b6-a869-843366326793@github.com>
 <H9zBs7z0MHZsdJ2ufOwuGDaA_ccTbE3vaZbRLUWSU1g=.c8dab9ef-5963-4bff-b9b9-b134fb4152c2@github.com>
 <eQWogONr__xT9ru7QPG-qLF2C1Kmx8rXJcuv8kFSoNA=.7ffb5eee-9cd0-4f60-8fbc-06892650359e@github.com>
Message-ID: <4sSoZGQm9sqRAT_Yumn5klSfAjZ8JoaYwPC_QELDBaw=.f5a29771-4f09-4810-b4aa-13249b948d96@github.com>

On Mon, 21 Oct 2024 21:56:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> I read through it fairly thoroughly. I made a lot of suggestions. Rather than edit comments into lots of spots in this PR, I made the following patch file. [aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/17408940/aot-indy-21143-commentary.diff.txt)
>> 
>> 
>> +bool InstanceKlass::is_enum_subclass(bool direct_only) const {
>> +  InstanceKlass* s = java_super();
>> +  return (s == vmClasses::Enum_klass() ||
>> +          (s != null && s->java_super() == vmClasses::Enum_klass()));
>> +}
>> 
>> Just happened to notice you aren't checking `direct_only`.
>
>> ```
>> +bool InstanceKlass::is_enum_subclass(bool direct_only) const {
>> +  InstanceKlass* s = java_super();
>> +  return (s == vmClasses::Enum_klass() ||
>> +          (s != null && s->java_super() == vmClasses::Enum_klass()));
>> +}
>> ```
>> 
>> Just happened to notice you aren't checking `direct_only`.
> 
> I consulted with John and removed the `direct_only` parameter as it's no longer needed.

> @iklam Changes to move main module name from modules.cpp to elsewhere do not look related to AOT-linking of indy. If so, can they be done in a separate PR.

The change is actually necessary --  the main module name used to be restored inside `MetaspaceShared::serialize()`, which happens after we decide to accept the CDS archive. When the main module doesn't match, we will disable the "archived full module graph" and keep on using the rest of the CDS archive.

With aot-linked classes, the main module is needed early to decide whether to reject a CDS archive altogether. Therefore, I needed to lift its processing our of `MetaspaceShared::serialize()` and put its information directly inside the archive file header.

(This change could have been included in https://github.com/openjdk/jdk/pull/20843 , but that might be too much work now that the review for JEP 483 is winding down).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21143#issuecomment-2427822847

From asemenyuk at openjdk.org  Mon Oct 21 22:16:16 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 21 Oct 2024 22:16:16 GMT
Subject: Integrated: 8342609: jpackage test helper function incorrectly removes
 a directory instead of its contents only
In-Reply-To: <l6DyfD0KC3hruoyIdozFp0iDlZktByR79zPG3ecxpug=.8b41340d-4e9a-4ac1-8389-f846af4e7642@github.com>
References: <l6DyfD0KC3hruoyIdozFp0iDlZktByR79zPG3ecxpug=.8b41340d-4e9a-4ac1-8389-f846af4e7642@github.com>
Message-ID: <8zMuYB0LbjTbaraY-tJOjAiPCHZ_zD0kq3vzpEfzgaQ=.67f42031-1c09-4a65-a386-05ad15b30e13@github.com>

On Fri, 18 Oct 2024 13:45:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> `Files.walk(root, 0)` returns the `root` itself and not the contents of the `root`.
> Replaced `Files.walk(root, 0)` with `Files.list(root)` to get a non-recursive listing of the `root` directory.

This pull request has now been integrated.

Changeset: 7133d1b9
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7133d1b983d7b85ba3c8dde26eb654c7ab695b07
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8342609: jpackage test helper function incorrectly removes a directory instead of its contents only

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/21582

From iklam at openjdk.org  Mon Oct 21 23:33:21 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 23:33:21 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v13]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <pmw4_RSGSke0Ts_6yfn-46CagAAY-m3Tydo5W8CnYmM=.e7923e39-3afd-4ddf-b607-a0fda3dd0bf3@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed JDK-8342438: runtime/cds/SharedBaseAddress.java fails with Parallel and Serial GCs when running with AOTClassLinking enabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/044f28a7..07e80df8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=11-12

  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Tue Oct 22 00:58:00 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 00:58:00 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v14]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <ltzOrCWNuzNN9KsCSNz-sHI8Rjz-z081xrgBUJV3yJ4=.15dd43dc-5fc8-4473-a40e-d4abce4aac41@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - @ashu-mehra comments: renamed to find_required_hidden_classes(), etc, and added checks for only hidden classes
 - fixed minimal build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/07e80df8..6916e187

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=12-13

  Stats: 56 lines in 9 files changed: 18 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From iklam at openjdk.org  Tue Oct 22 00:58:00 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 00:58:00 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <bawYxEbNMLLsVKFAcdwD3Bu_Zoc1_5w0kpIU8OJB9D4=.21544e14-d107-49bf-9d00-afa56b6bf63d@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
 <UclqKuf6jZl1nnmiy3qPqWmoLlFDkN6x84Lr7akjCzo=.74e73243-d75e-4c7c-87be-e1506e4fa79b@github.com>
 <bawYxEbNMLLsVKFAcdwD3Bu_Zoc1_5w0kpIU8OJB9D4=.21544e14-d107-49bf-9d00-afa56b6bf63d@github.com>
Message-ID: <K4faLPg0OMoaGveUB8xAJauKq78p2uCy-GPpCfWtlUs=.81eb16e9-78e3-49da-966c-3c0e4b12da1c@github.com>

On Fri, 18 Oct 2024 05:39:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `Class::reflectionFactory` is a large table that must be cleared, or else we will bring unwanted (unsupported) objects into the cache.
>> 
>> During runtime, `reflectionFactory` will be initialized on demand, so there's no need to explicitly create it with `runtimeSetup`.
>
> That said, can reflectionFactory field be stable in the future with this?

Perhaps. In the Leyden repo we are doing some optimizations for reflection. See the `ArchiveReflectionData` flag in the Leyden premain repo.. I am not sure if `reflectionFactory` itself needs to be cached.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809702708

From iklam at openjdk.org  Tue Oct 22 01:10:29 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 01:10:29 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <vlnQGlbG7NDzWUc_gJWL6qO7pDIfmnww-JBHGiH-2zs=.3a3e0644-ea17-42aa-96de-d0d024e19f87@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
 <vlnQGlbG7NDzWUc_gJWL6qO7pDIfmnww-JBHGiH-2zs=.3a3e0644-ea17-42aa-96de-d0d024e19f87@github.com>
Message-ID: <wkQOXn5_fy6Il0KzTdwUMfs9Ox5f-rdjUASXzaFwuy8=.095b506d-31c9-42f0-b89b-8f84e5402056@github.com>

On Wed, 16 Oct 2024 23:16:00 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo in last commit; fixed header inclusion order
>
> src/hotspot/share/cds/dumpTimeClassInfo.hpp line 45:
> 
>> 43:   bool                         _is_early_klass;
>> 44:   bool                         _has_checked_exclusion;
>> 45:   bool                         _is_required;
> 
> Is this flag only used for hidden classes?

I changed it to `_is_required_hidden_class`.

> src/hotspot/share/cds/heapShared.cpp line 717:
> 
>> 715: };
>> 716: 
>> 717: void HeapShared::find_archivable_hidden_classes_in_object(oop root) {
> 
> If this function find archivable hidden classes, shouldn't there be a check for`is_hidden()` on the InstanceKlass being marked as `required`. Am I missing something?

I added the `ik->is_hidden()` check as you suggested. I also renamed the `find_archivable_hidden_classes_xxx` functions to `find_required_hidden_classes_xxx()`. This is to avoid confusion with `HeapShared::is_archivable_hidden_klass()`, which means "it is possible to archive X", but not "it is necessary to archive X".

> src/hotspot/share/cds/heapShared.cpp line 790:
> 
>> 788: 
>> 789:   init_seen_objects_table();
>> 790:   {
> 
> Why was this scope introduced?

To indicate that these calls must be made while the "see objects" table is available.

> src/hotspot/share/classfile/systemDictionaryShared.cpp line 675:
> 
>> 673: 
>> 674: // Returns true if the class should be excluded. This can be called before
>> 675: // SystemDictionaryShared::check_excluded_classes().
> 
> There are a couple of references to check_excluded_classes() in the comments but this function no longer exists. Can you please update the comment accordingly.

I replaced with the new name of the function `find_all_archivable_classes()`.

> src/hotspot/share/classfile/systemDictionaryShared.cpp line 759:
> 
>> 757:       if (k->is_hidden() && should_hidden_class_be_archived(k)) {
>> 758:         SystemDictionaryShared::check_for_exclusion(k, &info);
>> 759:         if (info.is_excluded()) {
> 
> Is it possible that a hidden class for which `should_hidden_class_be_archived()` returns true is marked for exclusion by `SDS::check_for exclusion`? I guess only possibility is if for some reason its super or interface is excluded. Is that possible?

We filter out hidden classes that cannot be supported (e.g., when a Lambda uses an interface using "old" bytecodes). See

https://github.com/openjdk/jdk/pull/21143/files#diff-fc60af483d061250f01054372fd56eba517a6b8dd37a742a66dfb0e15cb68e40R366-R372

https://github.com/openjdk/jdk/pull/21143/files#diff-2520dedd703ec600cd3037ec0008e9d7f45c6a41acaefac019339641bc749163R149-R152

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809709541
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809709627
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809709670
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809709979
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1809710069

From jwaters at openjdk.org  Tue Oct 22 01:46:19 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Oct 2024 01:46:19 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>
Message-ID: <-zfrUge_9zAFIlJQB-L2oytEBTLluINYiNlbkCFkCTE=.db445cce-343f-4792-bfa7-1ea22d453d46@github.com>

On Tue, 22 Oct 2024 01:40:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > and whatever team is responsible for HotSpot debugging.
> 
> I don't see anything hotspot related here.
> 
> I think you would be better off splitting this up into distinct issues and PRs for different areas. I expect the client team in particular would prefer that.

Aren't the dt_shmem and jdwp changes related to HotSpot? But I guess I'll split it up in that case, I thought it might have been quicker to group it all together in one shot. This particular Pull Request I'll probably reserve for jdwp and the like, core-libs and client (And everything else) I'll move to their own PRs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2428041172

From dholmes at openjdk.org  Tue Oct 22 01:46:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 01:46:19 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>

On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> and whatever team is responsible for HotSpot debugging.

I don't see anything hotspot related here.

I think you would be better off splitting this up into distinct issues and PRs for different areas. I expect the client team in particular would prefer that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2428037844

From almatvee at openjdk.org  Tue Oct 22 01:52:41 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 22 Oct 2024 01:52:41 GMT
Subject: RFR: 8341939: SigningOptionsTest fails without Xcode with command line
 developer tools after JDK-8341443
Message-ID: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>

- Removed hard check for "Xcode with command line developer tools" when `--mac-sign` is specified and instead we will show information message if `codesign` fails for any reason that possible root cause of failure is missing Xcode with command line developer tools.
- Reason for this is that `codesign` works fine on recent macOS versions and it looks like dependency on Xcode with command line developer tools is no longer required. Unfortunately it is unknown which macOS versions are require Xcode with command line developer tools in order to `codesign` work, so this check will be done as soft check.
- SigningOptionsTest which requires "Xcode with command line developer tools" on some older macOS versions was modified to skip certain tests which might fail if Xcode is not installed.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8341939
 - 8341939: SigningOptionsTest fails without Xcode with command line developer tools after JDK-8341443

Changes: https://git.openjdk.org/jdk/pull/21628/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21628&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341939
  Stats: 96 lines in 8 files changed: 62 ins; 26 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21628/head:pull/21628

PR: https://git.openjdk.org/jdk/pull/21628

From pchilanomate at openjdk.org  Tue Oct 22 02:14:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:14:23 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
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: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@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 six additional commits since the last revision:

 - Fix comments in objectMonitor.hpp
 - Move frame::saved_thread_address() to platform dependent files
 - Fix typo in jvmtiExport.cpp
 - remove usage of frame::metadata_words in possibly_adjust_frame()
 - Fix comments in c2 locking paths
 - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/8c196acd..23d1a2be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=01-02

  Stats: 253 lines in 19 files changed: 122 ins; 97 del; 34 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 Oct 22 02:14:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:14:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>

On Mon, 21 Oct 2024 06:38:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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 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.

-------------

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_r1809747046

From pchilanomate at openjdk.org  Tue Oct 22 02:23:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:23:16 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>

On Mon, 21 Oct 2024 07:57:31 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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/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/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/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/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_r1809753868
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_r1809749805
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_r1809754940

From bpb at openjdk.org  Tue Oct 22 02:40:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 02:40:44 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8233451: Add tests for read{All,N}Bytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/492659f6..ead1b59b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=02-03

  Stats: 125 lines in 1 file changed: 116 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

PR: https://git.openjdk.org/jdk/pull/21508

From iklam at openjdk.org  Tue Oct 22 04:04:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 04:04:25 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v15]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <ljzL27S6RRkk3XHppu_OQxwcWtGrcSLDjm2HqwZA324=.a0d97a9d-8215-426c-a9a9-d04c9ebdafc6@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed JDK-8342732: java/lang/invoke/MethodTypeSecurityManager.java fails with "should never leak JDK internal class" in case AOTClassLinking enabled
 - Fixed JDK-8342723: Crash with "assert(_instance != nullptr) failed: cannot enqueue events before the service thread runs" in case AOTClassLinking enabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/6916e187..d3663890

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=13-14

  Stats: 17 lines in 4 files changed: 15 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From liach at openjdk.org  Tue Oct 22 04:12:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 04:12:11 GMT
Subject: RFR: 8342644: Optimize InvokerBytecodeGenerator for using
 ClassFile API [v2]
In-Reply-To: <Qi1MmYf4ds_Q5CCUVmD6ksUwDl6PvmYAWAeFYdhu72U=.00f5e220-eeac-453e-8dd7-88b91a81f2bc@github.com>
References: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
 <Qi1MmYf4ds_Q5CCUVmD6ksUwDl6PvmYAWAeFYdhu72U=.00f5e220-eeac-453e-8dd7-88b91a81f2bc@github.com>
Message-ID: <jAtSFfMvpaFp7grDld4EcaiwMILlnxtaRnONNrF1aOE=.7a5ba738-e01d-4c78-80eb-65ea8a377646@github.com>

On Sat, 19 Oct 2024 11:56:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Cache commonly used classDesc to avoid creating ReferenceClassDescImpl every time
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add LFI/NFI

Would it make sense for us to pass the ClassDesc as a constructor argument? We can drop the SourceFile attribute as I think we included it by convenience back when we were using ASM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21580#issuecomment-2428187478

From liach at openjdk.org  Tue Oct 22 04:28:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 04:28:44 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction
Message-ID: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>

Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.

-------------

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342469
  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 liach at openjdk.org  Tue Oct 22 04:28:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 04:28:44 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction
In-Reply-To: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
Message-ID: <z5ZyAOXEsknZbwGNnxZf3bbzxoq9l2c4edaGbN8UjHE=.8fbeff71-8387-470c-9328-0922ad618602@github.com>

On Mon, 21 Oct 2024 22:43:42 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.

Proofread a little bit. Since this is huge and there may be mistakes, I will only create a CSR after some typos and problems have been fixed to reduce repeated updates to the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21625#issuecomment-2428205240

From liach at openjdk.org  Tue Oct 22 04:32:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 04:32:26 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v5]
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <1tChaHsGsjDMOmMNcwaTvC0hNIJ8R_GN-IsiqyCBY4Y=.966f90b9-2ea5-44aa-8ee5-9bc244c760d9@github.com>

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Chen Liang 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' of https://github.com/openjdk/jdk into feature/array-cd
 - Merge
 - object array desc constant
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Mandy reviews
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - mlchung suggestions: elementType, improve utility methods
 - class or interface descriptor renamed for clarity
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Cleanup after merge
 - ... and 6 more: https://git.openjdk.org/jdk/compare/8bcd4920...62deed8b

-------------

Changes: https://git.openjdk.org/jdk/pull/20665/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=04
  Stats: 829 lines in 19 files changed: 445 ins; 251 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/20665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20665/head:pull/20665

PR: https://git.openjdk.org/jdk/pull/20665

From john.r.rose at oracle.com  Tue Oct 22 04:49:33 2024
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 21 Oct 2024 21:49:33 -0700
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <pgNVGyhN6uSCgipzMJeUoJd0BMJnb9qa-7Hpn6EWz6M=.8d294031-08a7-4450-a7af-1f46bb159436@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
 <pgNVGyhN6uSCgipzMJeUoJd0BMJnb9qa-7Hpn6EWz6M=.8d294031-08a7-4450-a7af-1f46bb159436@github.com>
Message-ID: <EF4DE7C2-4045-4D82-86FD-22591E98C405@oracle.com>

On 15 Oct 2024, at 12:35, Ioi Lam wrote:

> On Tue, 15 Oct 2024 19:08:20 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:
>
>>> 597:
>>> 598:     /** Number of CPUS, to place bounds on some sizings */
>>> 599:     static @Stable int NCPU;
>>
>> I would prefer to not mark this `@Stable` at this time as it would have different assembly and runtime values and instead add a followup RFE to investigate adding it in later.
>
> We have been archiving `ConcurrentHashMap` objects for many JDK releases (to support archiving of modules) and `NCPU` would change between CDS archive dump time and program run time. We have not seen any problems, so I think it's safe to use the `@Stable` annotation.

Is it necessary to get constant folding from NCPU?  I guess a division is slow, but it does not seem to be a hot path, at all.  The division is not in any loop.  If there is no performance issue, it?s perhaps more honest just to use a mutable variable.  I guess what we need here is something that means ?stable except for AOT activity?.

Normally, making something stable means it should be used according to the contract of stable, which is only one second value, and no third, after the initial default.

There is a sub-rosa contract, as well, which is that we can add third values if they do not conflict with the second values.  But we have to convince ourselves that is safe, because the second and third values can (in general) co-exist as folded constants in JIT code.

We currently refuse to fold stable constants in AOT code (and there?s no AOT code in this JEP anyway) so the AOT-only stable binding is tolerable.

Here?s what I think we should do later (not in this PR):  Amend the contract for @Stable that the value is allowed to be different during the AOT assembly phase than later.  Working out the details will require some discussion:  Should the AOT-AP reset stable values that need new bindings?  (Probably??)  Or should there be a warmup method that takes full responsibility for managing the stable value during the production run?

For now, I?m content to make this guy NCPU either stable or not.  But it is clear that, along with other details, we will need an amended story for the life-cycle of a stable variable that includes the AOT assembly phase.

Eventually, something like this may well play into a similar Leyden story for user-visible stables.  Those would be declared by an object API, not the private annotation we use in the JDK.  User-visible stable objects are likely to be wrappers for JDK-level stable-annotated fields, and that?s how the turtles tend to stack up.

No PR change requested here!

From liach at openjdk.org  Tue Oct 22 04:50:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 04:50:29 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v6]
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Relax displayName spec

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20665/files
  - new: https://git.openjdk.org/jdk/pull/20665/files/62deed8b..4acec988

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=04-05

  Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20665/head:pull/20665

PR: https://git.openjdk.org/jdk/pull/20665

From davidalayachew at gmail.com  Tue Oct 22 05:10:36 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 22 Oct 2024 01:10:36 -0400
Subject: Streams, parallelization, and OOME.
In-Reply-To: <MW4PR10MB5774C64231E4C0A5CE971AF2FF432@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>
 <MW4PR10MB5774C64231E4C0A5CE971AF2FF432@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_PYBxNog13ca5WSgrcst4aDhH=KJPYUf5_hk1pCu9LD4Q@mail.gmail.com>

Thanks Viktor, this was what I was looking for.

Ok, so due to existing difficulties in translating push to pull, it makes
sense why this wouldn't work.

I really look forward to upgrading my codebase soon. Gatherers fixed window
completely negates this problem. At least, it appears to.

On Mon, Oct 21, 2024, 6:54?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Hi David,
>
> Stream::spliterator() and Stream::iterator() suffer from inherent
> limitations (see https://bugs.openjdk.org/browse/JDK-8268483 ) because
> they attempt to convert push-style streams into pull-style constructs
> (Iterator, Spliterator). Since the only way to know if there's something to
> pull is for something to get pushed, but who's doing to pushing (answer:
> the same one who tries to do the pulling)?
>
> For sequential Streams this is often as problematic, but for parallel
> streams it's not the caller which evaluates the stream but rather a
> task-tree submitted to a ForkJoinPool. You can see the implementation here:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/StreamSpliterators.java#L272
>
> As an example, Stream::flatMap(?) had corner cases where its use of
> Stream::spliterator() would end up not terminating, which was fixed in Java
> 23: https://github.com/openjdk/jdk/pull/18625
> <https://github.com/openjdk/jdk/pull/18625>
> 8196106: Support nested infinite or recursive flat mapped streams by
> viktorklang-ora ? Pull Request #18625 ? openjdk/jdk
> <https://github.com/openjdk/jdk/pull/18625>
> This PR implements Gatherer-inspired encoding of flatMap that shows that
> it is both competitive performance-wise as well as improve correctness.
> Below is the performance of Stream::flatMap (for ref...
> github.com
>
>
>
>
> 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:* Saturday, 19 October 2024 07:54
> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Streams, parallelization, and OOME.
>
> Hello Core Libs Dev Team,
>
> I have a file that I am streaming from a service, and I am trying to split
> into multiple parts based on a certain attribute found on each line. I am
> sending each part up to a different service.
>
> I am using BufferedReader.lines(). However, I cannot read the whole file
> into memory because it is larger than the amount of RAM that I have on the
> machine. So, since I don't have access to Java 22's Preview Gatherers Fixed
> Window, I used the iterator() method on my stream, wrapped that in another
> iterator that can grab my batch size worth of data, then built a
> spliterator from that that I then used to create a new stream. In short,
> this wrapper iterator isn't Iterator<T>, it's Iterator<List<T>>.
>
> When I ran this sequentially, everything worked well. However, my CPU was
> low and we definitely have a performance problem -- our team needs this
> number as fast as we can get. Plus, we had plenty of network bandwidth to
> spare, so I had (imo) good reason to go use parallelism.
>
> As soon as I turned on parallelism, the stream's behaviour changed
> completely. Instead of fetching the batch and processing, it started
> grabbing SEVERAL BATCHES and processing NONE OF THEM. Or at the very least,
> it grabbed so many batches that it ran out of memory before it could get to
> processing them.
>
> To give some numbers, this is a 4 core machine. And we can safely hold
> about 30-40 batches worth of data in memory before crashing. But again,
> when running sequentially, this thing only grabs 1 batch, processes that
> one batch, sends out the results, and then start the next one, all as
> expected. I thought that adding parallelism would simply make it so that we
> have this happening 4 or 8 times at once.
>
> After a very long period of digging, I managed to find this link.
>
>
> https://stackoverflow.com/questions/30825708/java-8-using-parallel-in-a-stream-causes-oom-error
>
> Tagir Valeev gives an answer which doesn't go very deep into the "why" at
> all. And the answer is more directed to the user's specific question as
> opposed to solving this particular problem.
>
> After digging through a bunch of other solutions (plus my own testing), it
> seems that the answer is that the engine that does parallelization for
> Streams tries to grab a large enough "buffer" before doing any parallel
> processing. I could be wrong, and how large that buffer is? I have no idea.
>
> Regardless, that's about where I gave up and went sequential, since the
> clock was ticking.
>
> But I still have a performance problem. How would one suggest going about
> this in Java 8?
>
> 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/20241022/1608d28b/attachment.htm>

From iklam at openjdk.org  Tue Oct 22 06:22:43 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:22:43 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v16]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <gJaAuNIdvxZRKNY5zolFrSOFAWelTOJjw-OVkLVcayY=.e6cf05aa-b8aa-4ab7-9d86-5fb0d59da067@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request incrementally with three additional commits since the last revision:

 - Better fix for JDK-8342438: runtime/cds/SharedBaseAddress.java fails with Parallel and Serial GCs when running with AOTClassLinking enabled
 - (1) @ashu-mehra review comments - code simplfication; (2) fix bug in last commit
 - @DanHeidinga comments - removed dead code; added assert with ArchiveBuilder::has_been_buffered(src_ik)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21143/files
  - new: https://git.openjdk.org/jdk/pull/21143/files/d3663890..021466dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=14-15

  Stats: 90 lines in 7 files changed: 40 ins; 30 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From pkoppula at openjdk.org  Tue Oct 22 06:24:17 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Tue, 22 Oct 2024 06:24:17 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v5]
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: <fA3YS83i-waWk3TpJAezGooqDpgF10aNOQvOzYR0zQs=.f8b94adb-387e-4dde-b61b-b34162d708f3@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 BIS case as well

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/4e65df66..6a015262

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20414&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20414&range=03-04

  Stats: 106 lines in 8 files changed: 67 ins; 8 del; 31 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 iklam at openjdk.org  Tue Oct 22 06:26:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:26:25 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v4]
In-Reply-To: <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <qZBq4CEQm7zPuzOO9U6c6eXSMfM15W38ZICgEwuwxUI=.562ea12d-2a42-4c53-86e1-aba6f579d48a@github.com>
 <fGBSOjhrngOLmZz2oKyF0kfdoLpamJAGX-8f9v1z3_I=.0c235272-551f-48b0-8c64-9d261f5f6c89@github.com>
Message-ID: <flDY6rbsejKhpqlU2AfvCm4fDGMDur6ZDGsfRRPeQYk=.2153a882-98ee-45cf-bd43-d116ccc22921@github.com>

On Mon, 14 Oct 2024 15:54:15 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 JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>
> src/hotspot/share/cds/archiveUtils.cpp line 377:
> 
>> 375:   if (SystemDictionaryShared::is_excluded_class(src_ik)) {
>> 376:     return false;
>> 377:   }
> 
> Do we want an assert here that `ArchiveBuilder::current()->get_buffered_addr(src_ik)->has_aot_initialized_mirror() == false`?

These classes are not buffered so `ArchiveBuilder::current()->get_buffered_addr(src_ik)` won't work. I added this assert instead.


  if (SystemDictionaryShared::is_excluded_class(src_ik)) {
    assert(!ArchiveBuilder::current()->has_been_buffered(src_ik), "sanity");
    return false;
  }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810019800

From iklam at openjdk.org  Tue Oct 22 06:26:27 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:26:27 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v5]
In-Reply-To: <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <-xsA9qLazNdeHZznMpHZslb97HIadvTsTx8cAwNHnGA=.6ed2871d-b363-4ca5-8744-7d680a2fadfe@github.com>
 <kebhHgWS7UHKSc7D75UxbC0BECTaM_QAN2zhs4fqFCE=.e3cff076-351a-49d4-8ddf-9eb696afd79e@github.com>
Message-ID: <54Mbb-RA8vascKhl9W2lI103ZF9HqQ_I0x1Rx7wdaeI=.07cf9872-c5fa-45a8-ae9e-617a7f418381@github.com>

On Tue, 15 Oct 2024 15:12:44 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init NCPU to runtime value; also use the same runtimeSetup() pattern to call registerNatives() for Class.java and Unsafe.java
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Fixed JDK-8341988: jstack launched with AOT cache created with -XX:+AOTClassLinking crashes
>>  - 8341600: [premain] Automatic aot-init of classes used by java.lang.invoke
>>  - @adinn comments
>>  - improve checks for not changing <clinit> order for aot linking of lambda; added comprehensive test cases: AOTLinkedLambdasApp::testClinitOrder()
>>  - Clean up of aotClassInitializer and cdsHeaVerifier; added lambda test cases for <clinit> order of app classes
>>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>>  - Require all <clinit> of supertypes of aot-inited classes to be executed in assembly phase
>>  - Limit the use of AOTHolder
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/e46b910a...382446d4
>
> src/hotspot/share/cds/heapShared.cpp line 457:
> 
>> 455:   if (HeapShared::is_archivable_hidden_klass(ik)) {
>> 456:     // We can't rerun the <clinit> method of hidden classes as we don't save
>> 457:     // the classData, so we must archive its mirror in initialized state.
> 
> Is this comment still accurate?  It looks like we do save the class_data on line 506

This comment is obsolete. Also, we won't come for any class unless it's already initialized. So I deleted the comment and changed the assert to this for all classes


assert(ik->is_initialized(), "must be");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810021339

From iklam at openjdk.org  Tue Oct 22 06:30:29 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:30:29 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v7]
In-Reply-To: <P2bNpw2Ke20lBr7tLUfXdnwjqmPiEFqBchB2naVSgJ4=.c42ea920-e67c-4312-ad82-e11944747168@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <YeGWTUseD6S2V4qSBkP0urWzQU9rpDHpyqv5GrEGf4o=.1d37e93e-97a9-4016-af54-219abbc8abfe@github.com>
 <P2bNpw2Ke20lBr7tLUfXdnwjqmPiEFqBchB2naVSgJ4=.c42ea920-e67c-4312-ad82-e11944747168@github.com>
Message-ID: <i7GqBMUjKs6UKJcZEaWC7JVeT76kdGhun0wconArtQ0=.dd612fd7-150b-46ac-b968-a7e1459c9420@github.com>

On Wed, 16 Oct 2024 22:56:06 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo in last commit; fixed header inclusion order
>
> src/hotspot/share/cds/heapShared.cpp line 675:
> 
>> 673:     const char* klass_name = info->klass_name;
>> 674:     for (; fields[i].valid(); i++) {
>> 675:       ArchivableStaticFieldInfo* f = &fields[i];
> 
> It looks like the pattern of nested for-loops is copied from HeapShared::archive_object_subgraphs()
> but this pattern doesn't seem to give any advantage here. If so can we replace it with just single for loop to make it easier to understand?

I changed it to a single loop as suggested.

> src/hotspot/share/classfile/systemDictionaryShared.cpp line 775:
> 
>> 773:   // Now, all hidden classes that have not yet been scanned must be marked as excluded
>> 774:   auto exclude_remaining_hidden = [&] (InstanceKlass* k, DumpTimeClassInfo& info) {
>> 775:     if (k->is_hidden() && !info.has_checked_exclusion()) {
> 
> Suggestion: Check for `has_checked_exclusion()` is not really required as the call to `SDS::check_for_exclusion()` does that. And the condition in `guarantee()` can be updated as `info.is_excluded() || info.is_required()`.

I changed the code to the following to make sure that `should_hidden_class_be_archived(k)` is mutually exclusive with `info.is_excluded()`.


  auto exclude_remaining_hidden = [&] (InstanceKlass* k, DumpTimeClassInfo& info) {
    if (k->is_hidden()) {
      SystemDictionaryShared::check_for_exclusion(k, &info);
      if (CDSConfig::is_dumping_invokedynamic()) {
        if (should_hidden_class_be_archived(k)) {
          guarantee(!info.is_excluded(), "Must be");
        } else {
          guarantee(info.is_excluded(), "Must be");
        }
      }
    }
  };


Unfortunately I can do this only for `CDSConfig::is_dumping_invokedynamic()`. In the "legacy CDS" mode of lambda support, we actually would return true from `should_hidden_class_be_archived(k)` and then later decide to exclude `k`.

> src/hotspot/share/oops/constantPool.cpp line 340:
> 
>> 338:     src_cp->iterate_archivable_resolved_references([&](int rr_index) {
>> 339:       keep_resolved_refs.at_put(rr_index, true);
>> 340:       });
> 
> Indentation seems off here

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810025512
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810025031
PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810025626

From alanb at openjdk.org  Tue Oct 22 06:36:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 06:36:20 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v4]
In-Reply-To: <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
Message-ID: <FGpfPp16CM0aDtplOQAFBpM3CaTwJGJyANksLK5UiIo=.3da58de6-b758-49b4-8491-b4be1fa8e438@github.com>

On Mon, 21 Oct 2024 17:49:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21569#pullrequestreview-2384050186

From iklam at openjdk.org  Tue Oct 22 06:36:55 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:36:55 GMT
Subject: RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and
 MethodTypeForm when storing heap objects into AOT cache [v11]
In-Reply-To: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
References: <4jEh7IoWn8EeCJTGdakHlAuyBjybcPm3B3j0p2uthus=.9aa492df-388f-4ac2-acfd-dbf97ceb9f5d@github.com>
Message-ID: <1JXAb0o5ommAPMWfWxJeIIuUujfBChjdA4LQfv0R11M=.3dc4b290-719f-404b-bab4-88b2823b4360@github.com>

> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
> 
> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
> 
> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
> 
> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
> 
> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
> 
> ---
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam 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 18 additional commits since the last revision:

 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @iwanowww comment: no need for @Stable for USE_SOFT_CACHE; use final instead
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - reviews from @iwanowww and @rose00 -- move USE_SOFT_CACHE to MethodHandleNatives as a @Stable field; use system prop for init
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - @liach and @cl4es comments
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - ... and 8 more: https://git.openjdk.org/jdk/compare/30a325cf...875c066d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21049/files
  - new: https://git.openjdk.org/jdk/pull/21049/files/a9ae70e2..875c066d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21049&range=09-10

  Stats: 7 lines in 4 files changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21049/head:pull/21049

PR: https://git.openjdk.org/jdk/pull/21049

From iklam at openjdk.org  Tue Oct 22 06:53:35 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 06:53:35 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v17]
In-Reply-To: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
Message-ID: <51FcVJxb8SzgO6C_cUx_8ZuwC99yhkq_jXpbrmyQaJs=.236008f1-319a-482d-8d96-598dc65a486e@github.com>

> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and string concat (`StringConcatFactory::makeConcatWithConstants()`) as the results of these bootstrap methods do not have environment dependencies and can be safely cached.
> - The resolved CallSites are represented as Java heap objects. Thus, this optimizations is supported only for the static CDS archive, which can store heap objects. The dynamic CDS archive is not supported.
> 
> **Review Notes:**
> 
> - Start with `AOTConstantPoolResolver::preresolve_indy_cp_entries()` -- it checks all indys that were linked during the training run, and aot-links only those for lambdas and string concats
> - `SystemDictionaryShared::find_all_archivable_classes()` finds all the hidden classes that are reachable from the indy CallSites
> - In `MetaspaceShared::preload_and_dump_impl()` we call `MethodType::createArchivedObjects()` to record all MethodTypes that were created in the assembly phase. This is necessary because the identity of MethodTypes is significant (they are compared with the `==` operator). Also see MethodType.java for the corresponding code that are used in the production run.
> - Afterwards, we enter the safepoint (`VM_PopulateDumpSharedSpace::doit()`). In this safepoint,  `ConstantPoolCache::remove_resolved_indy_entries_if_non_deterministic()` is called to remove any resolved indy callsites that cannot be archived. (Such CallSites may be created as a side effect of Java code execution in the assembly phase. E.g., the bootstrap of the module system).
> 
> **Rough Edges:**
> 
> - Many archived CallSites references (directly or indirectly) the static fields of the classes listed under `AOTClassInitializer::can_archive_initialized_mirror()`, where the object identity of these static fields is significant. Therefore, we must preserve the initialized states of these classes. Otherwise, we might run into problems such as [JDK-8340836](https://bugs.openjdk.org/browse/JDK-8340836). Unfortunately, the list is created by trial-and-error, and may need to be updated to match changes in the `java.lang.invoke` and `jdk.internal.constant` packages. We expect Project Leyden to come with a general solution to this problem.
> - If the identity is significant for a static field in a complex class, but not all of the static fields of this cl...

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits:

 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Better fix for JDK-8342438: runtime/cds/SharedBaseAddress.java fails with Parallel and Serial GCs when running with AOTClassLinking enabled
 - (1) @ashu-mehra review comments - code simplfication; (2) fix bug in last commit
 - @DanHeidinga comments - removed dead code; added assert with ArchiveBuilder::has_been_buffered(src_ik)
 - Fixed JDK-8342732: java/lang/invoke/MethodTypeSecurityManager.java fails with "should never leak JDK internal class" in case AOTClassLinking enabled
 - Fixed JDK-8342723: Crash with "assert(_instance != nullptr) failed: cannot enqueue events before the service thread runs" in case AOTClassLinking enabled
 - @ashu-mehra comments: renamed to find_required_hidden_classes(), etc, and added checks for only hidden classes
 - fixed minimal build
 - Fixed JDK-8342438: runtime/cds/SharedBaseAddress.java fails with Parallel and Serial GCs when running with AOTClassLinking enabled
 - dholmes-ora comment - removed direct_only parameter from InstanceKlass::is_enum_subclass()
 - ... and 38 more: https://git.openjdk.org/jdk/compare/875c066d...f0bc1ae6

-------------

Changes: https://git.openjdk.org/jdk/pull/21143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21143&range=16
  Stats: 2793 lines in 76 files changed: 2445 ins; 146 del; 202 mod
  Patch: https://git.openjdk.org/jdk/pull/21143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21143/head:pull/21143

PR: https://git.openjdk.org/jdk/pull/21143

From stefank at openjdk.org  Tue Oct 22 07:09:23 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 07:09:23 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
 <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
 <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>
Message-ID: <7omxfwDgvafhEV_y55J67oh1mv89mcbOXtMwdhwHCS4=.bca52790-c031-4b68-80f8-0ead581a1b7b@github.com>

On Mon, 21 Oct 2024 20:31:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/memory/iterator.inline.hpp line 57:
>> 
>>> 55:     ClaimMetadataVisitingOopIterateClosure::do_cld(cld);
>>> 56:   } else {
>>> 57:     assert_is_pending_aot_linked_class(k);
>> 
>> Would there be a drawback to just adding `assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity");` here and skip the changes the both .hpp and .cpp files?
>
> I changed the code to `assert(is_pending_aot_linked_class(k), "sanity")`. Since iterator.hpp is widely used, I avoid including aotLinkedClassBulkLoader.hpp in this header, and route the call through iterator.cpp.

My proposal was to use it in this file (iterator.inline.hpp) and not iterator.hpp. I see no need to route this through the .cpp file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810071099

From duke at openjdk.org  Tue Oct 22 07:34:33 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 22 Oct 2024 07:34:33 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence)
In-Reply-To: <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>
 <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>
 <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>
Message-ID: <fl457WFQ9swlPWSrOTBc6CBEwEsM6xevz6RXH79Pr_U=.96803e86-7726-4d58-b965-474e0f742ff8@github.com>

On Wed, 9 Oct 2024 10:40:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @AlanBateman Can you please review [the CSR request](https://bugs.openjdk.org/browse/JDK-8341596) so I can finish it? Thanks!
>> 
>> Latest API docs looks good, will you update the CSR?
>
>> @AlanBateman WDYT?
> 
> A title like "Add Reader.of(CharSequence)" would make it clear to everyone what this issue, and the CSR, is about.

@AlanBateman As the CSR is approved, kindly asking for your review of this PR to finally integrate the changes. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2428477360

From dholmes at openjdk.org  Tue Oct 22 07:44:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 07:44:22 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>

On Tue, 22 Oct 2024 02:14: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 six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

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

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 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 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 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 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/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/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. ??

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2384039238
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810025380
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_r1810032387
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_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_r1810068395
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

From psadhukhan at openjdk.org  Tue Oct 22 08:11:35 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 08:11:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:

> 24: import javax.swing.SwingUtilities;
> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
> 26: /*

I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810185617

From psadhukhan at openjdk.org  Tue Oct 22 08:19:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 08:19:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:

> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
> 48:     }
> 49: 

Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810199838

From psadhukhan at openjdk.org  Tue Oct 22 09:01:38 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:01:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <1EhcQfR-j3LoYCg_GkqbbJGXZEEF7PQgXtEfq_MZFZw=.6db08c42-646e-4cc1-b704-07820ae128bb@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:

> 29: /**
> 30:  * @test
> 31:  * @key headful

javadoc style /** at the beginning

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810285947

From dholmes at openjdk.org  Tue Oct 22 09:05:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 09:05:19 GMT
Subject: RFR: 8340133: Investigate if the java launcher could give hints
 about JShell [v3]
In-Reply-To: <7_G2FUJH6XZYwVugDm7vGpXWeq82UHz1PnnzS0vohvc=.1b41e871-8623-4550-ba8c-659dc5c95332@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <JtMJYJYik7htgVKpeG-FBriWyUfun3OGJ-Sgvxzt3yA=.fe635d22-6455-4e6f-a8dd-ee36c64166e0@github.com>
 <7_G2FUJH6XZYwVugDm7vGpXWeq82UHz1PnnzS0vohvc=.1b41e871-8623-4550-ba8c-659dc5c95332@github.com>
Message-ID: <gLgpb4rjVqDSQRVhsJK49hLqSpgJCD4GrlPUrSFgJ6g=.532b4944-d516-45ad-8c9c-118185476f0e@github.com>

On Mon, 21 Oct 2024 07:21:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> usage of what

That seems pretty self-evident to me.

"launcher" is our terminology for the java executable, but for users it is just a program that runs other stuff.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1810294114

From psadhukhan at openjdk.org  Tue Oct 22 09:07:51 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:07:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <YNmEi00IsUjIq2jyebS_mjfWgyUlkz9lx4Hlw2PE5yc=.e917162c-9b2c-4c14-ace0-f4fe31e4cf5a@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 48:

> 46:         test.setupUI();
> 47:         test.testApplication();
> 48:         test.testApplet();

I guess we can only remove this `testApplet` as SM is invoked there only....we can still test `testApplication`, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810297085

From psadhukhan at openjdk.org  Tue Oct 22 09:12:33 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:12:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <rb-fYphAyA6BGkUU1fouWA9XPKElgZTf13MGIgbv2gc=.1d78026e-00e6-4f0e-b194-a4df08e8688e@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 66:

> 64:         }
> 65: 
> 66:         // Show popup as if from an applet

remove applet

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810309276

From psadhukhan at openjdk.org  Tue Oct 22 09:19:31 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:19:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <1rvnBCeqVl1aLtZcR0YYv7abOQlZ7WNQrOQgH359CVw=.ad43bb44-7be8-429b-aea7-ea4cd8ad507c@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:

> 115:             }
> 116:             popup.setVisible(false);
> 117:             frame.dispose();

The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:

> 27:  * @test
> 28:  * @bug 6622002
> 29:  * @author Alexander Potochkin

remove @author tag

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810327184
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810331078

From psadhukhan at openjdk.org  Tue Oct 22 09:32:33 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:32:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:

> 43:         JTable table = new JTable();
> 44:         TableCellEditor de = table.getDefaultEditor(Double.class);
> 45:         if (de == null) {

I guess we can test this without SM since it tests SwingLazyValue?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810353747

From abimpoudis at openjdk.org  Tue Oct 22 09:42:25 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 22 Oct 2024 09:42:25 GMT
Subject: Integrated: 8342679: Clean up PreviewFeature.Feature
In-Reply-To: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
References: <wTlLCIu6dtOpP66vyc9ZZUHF8na73EXjEH2nYukXVzw=.8aa3268a-d83e-4fa6-9cbb-2e79f668c3d8@github.com>
Message-ID: <QxcIEUBFKsKwzI8Z5Png5WWdCbTyGoWlpZ58BySJK1c=.ab0a8174-4537-4443-bea2-f3e705f75465@github.com>

On Mon, 21 Oct 2024 11:23:05 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> After doing a build + bootcycle build confirms that these constants can be removed.

This pull request has now been integrated.

Changeset: c9f38409
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9f38409ccb84f315fa61490baacea9f070b646d
Stats:     5 lines in 1 file changed: 0 ins; 1 del; 4 mod

8342679: Clean up PreviewFeature.Feature

Reviewed-by: liach, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/21605

From dholmes at openjdk.org  Tue Oct 22 09:43:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 09:43:41 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <-zfrUge_9zAFIlJQB-L2oytEBTLluINYiNlbkCFkCTE=.db445cce-343f-4792-bfa7-1ea22d453d46@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>
 <-zfrUge_9zAFIlJQB-L2oytEBTLluINYiNlbkCFkCTE=.db445cce-343f-4792-bfa7-1ea22d453d46@github.com>
Message-ID: <3kfD7hXMBKj93H04sYwW60CpKwCJUbwgfBpDnC9aMj8=.84120ba5-8e46-4711-b220-ec23d5d5f296@github.com>

On Tue, 22 Oct 2024 01:43:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Aren't the dt_shmem and jdwp changes related to HotSpot? 

Nope. That's core-svc - the non-hotspot side of serviceability. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2428793636

From duke at openjdk.org  Tue Oct 22 10:00:55 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Oct 2024 10:00:55 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v11]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <5vli4_vrIaNpZ2s67VlbfLTAEGIKT9ddRHUVBWtJeWQ=.931a772b-d0b1-48e0-b15c-7ee032cd1693@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:

  Increment the unscaled sqrt for speed and round the result

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/5cd590c2..d75e6e50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=09-10

  Stats: 7 lines in 1 file changed: 3 ins; 3 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 alanb at openjdk.org  Tue Oct 22 10:20:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 10:20:14 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
Message-ID: <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>

On Tue, 22 Oct 2024 02:40:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233451: Add tests for read{All,N}Bytes

This update looks good, just a bit minor nits. I assume you'll run the test many tests on all platforms to ensure its stability before integrating.

test/jdk/java/nio/file/Files/InputStreamTest.java line 29:

> 27:  * @library .. /test/lib
> 28:  * @build jdk.test.lib.Platform
> 29:  * @run junit InputStreamTest

I think this will need --enable-native-access=ALL-UNNAMED.

test/jdk/java/nio/file/Files/InputStreamTest.java line 99:

> 97:                     try {
> 98:                         try (FileOutputStream fos = new FileOutputStream(PIPE);)
> 99:                         {

The formatting is a bit messed up, I think a previous iteration has a second resource that is now removed.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21508#pullrequestreview-2384729469
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1810439366
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1810441547

From eirbjo at openjdk.org  Tue Oct 22 10:56:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 22 Oct 2024 10:56:50 GMT
Subject: RFR: 8342807: Update links in java.base to use https://
Message-ID: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>

Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http.

Links in `java.security` and `share/data/tzdata` are excluded from this PR.

This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. 

There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`).

Changes beyond the obvious  are as follows:

`linux/native/libsimdsort/xss-common-qsort.h`:
The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170

`share/man/keytool.1`:
www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well?

`unix/classes/sun/net/PortConfig.java`
The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports.

`unix/native/libjava/*`,
 Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs

`unix/native/libjava/ProcessImpl_md.c`
A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to.

-------------

Commit messages:
 - Use Wayback link
 - Update copyright year
 - Update links in java.base to use https://

Changes: https://git.openjdk.org/jdk/pull/21633/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342807
  Stats: 14 lines in 8 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21633/head:pull/21633

PR: https://git.openjdk.org/jdk/pull/21633

From jlahoda at openjdk.org  Tue Oct 22 11:06:44 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 22 Oct 2024 11:06:44 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v5]
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: <1lAqvR59LNaK3sSbf-ZeXgHav93nP9EVQnmu3wG0P1Q=.85613333-5df5-4d54-bf07-463c85d1a624@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>
>     a ":"-separated list of directories and JAR archives to search for class files
>   --module-path <module path>
>     a ":"-separated list of directories and JAR archives to search for modules
> 
> 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:

  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".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21411/files
  - new: https://git.openjdk.org/jdk/pull/21411/files/5d82312f..dc85a167

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 Oct 22 11:06:44 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 22 Oct 2024 11:06:44 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v3]
In-Reply-To: <gLgpb4rjVqDSQRVhsJK49hLqSpgJCD4GrlPUrSFgJ6g=.532b4944-d516-45ad-8c9c-118185476f0e@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <JtMJYJYik7htgVKpeG-FBriWyUfun3OGJ-Sgvxzt3yA=.fe635d22-6455-4e6f-a8dd-ee36c64166e0@github.com>
 <7_G2FUJH6XZYwVugDm7vGpXWeq82UHz1PnnzS0vohvc=.1b41e871-8623-4550-ba8c-659dc5c95332@github.com>
 <gLgpb4rjVqDSQRVhsJK49hLqSpgJCD4GrlPUrSFgJ6g=.532b4944-d516-45ad-8c9c-118185476f0e@github.com>
Message-ID: <9J_l8aAGeoJ-4nhGwO9bxtXFcnEFNDFAf5MOdNQOGJo=.c8b92dcd-3571-4b98-9edf-4013fa182a5b@github.com>

On Tue, 22 Oct 2024 09:02:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sorry, but it feels a bit incomplete - it does not say usage of what. I don't quite see the issue with the word "launcher". The `java` command is a launcher for user programs, is it not?
>
>> usage of what
> 
> That seems pretty self-evident to me.
> 
> "launcher" is our terminology for the java executable, but for users it is just a program that runs other stuff.

Ok:
https://github.com/openjdk/jdk/pull/21411/commits/dc85a1679b623806a62de34c22e96793e7c0a3cd

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1810510057

From jvernee at openjdk.org  Tue Oct 22 11:16:12 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 22 Oct 2024 11:16:12 GMT
Subject: RFR: 8341584: Test java/foreign/TestUpcallStress.java intermittent
 timeout with -Xcomp
In-Reply-To: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
References: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
Message-ID: <79rISYVJlHORpkagywmTKjnODykt2AzFD0Fj1XNq1gM=.6f8f2174-2cc9-4c05-beaf-bfd6a73efc53@github.com>

On Tue, 15 Oct 2024 01:25:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `java/foreign/TestUpcallStress.java` intermittent timeout with -Xcomp, and this test use a very precise race, thus `-Xcomp` probably will never trigger the problematic use-case. So this test not suitable for -Xcomp mode.I add `@requires vm.compMode != "Xcomp"` to exclude from Xcomp testing and remove this test from `ProblemList-Xcomp.txt`.
> Trivial fix, test-fix only, no risk.

Looks good, thanks for making this change.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21512#pullrequestreview-2384871649

From duke at openjdk.org  Tue Oct 22 11:20:20 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Oct 2024 11:20:20 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v12]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <4TFgVOd-HUF7tuPsUkDnhmCU7vwPBwbn3NE7azmFXZg=.eccbeb7d-4486-4e38-a26e-e5b04c857eb6@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:

  adjust to preferred scale in each branch for speed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/d75e6e50..d4218464

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=10-11

  Stats: 50 lines in 1 file changed: 35 ins; 13 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 jwaters at openjdk.org  Tue Oct 22 11:35:39 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Oct 2024 11:35:39 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <3kfD7hXMBKj93H04sYwW60CpKwCJUbwgfBpDnC9aMj8=.84120ba5-8e46-4711-b220-ec23d5d5f296@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>
 <-zfrUge_9zAFIlJQB-L2oytEBTLluINYiNlbkCFkCTE=.db445cce-343f-4792-bfa7-1ea22d453d46@github.com>
 <3kfD7hXMBKj93H04sYwW60CpKwCJUbwgfBpDnC9aMj8=.84120ba5-8e46-4711-b220-ec23d5d5f296@github.com>
Message-ID: <AZW9odbdZiZH_ctLd_GOU3cXw6rLoYTvav_YqiqHOaE=.418db53f-3ddc-4886-9dd4-60e2e5369150@github.com>

On Tue, 22 Oct 2024 09:40:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Aren't the dt_shmem and jdwp changes related to HotSpot?
> 
> Nope. That's core-svc - the non-hotspot side of serviceability. :)

Oh, well I guess you learn something new everyday :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2429033577

From duke at openjdk.org  Tue Oct 22 11:41:31 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Oct 2024 11:41:31 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v13]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <VGsOdGidqYpmOGGfuE0sxXqD_Z-gKIWC1rIuU5s6zdg=.ec2b50da-bc46-4b31-8a1e-9b62e6439895@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:

  Avoid overflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/d4218464..f90cea6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=11-12

  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 michaelm at openjdk.org  Tue Oct 22 11:53:39 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 22 Oct 2024 11:53:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

test/jdk/java/net/URLPermission/OpenURL.java line 30:

> 28:  * @run main/othervm OpenURL
> 29:  */
> 30: 

Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2384948510
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810575350

From alanb at openjdk.org  Tue Oct 22 11:58:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 11:58:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>

On Mon, 21 Oct 2024 15:41:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810578179

From alanb at openjdk.org  Tue Oct 22 11:58:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 11:58:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>

On Tue, 22 Oct 2024 07:28:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810579901
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810583267

From liach at openjdk.org  Tue Oct 22 12:00:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 12:00:53 GMT
Subject: RFR: 8341776: Remove unused enum values from LambdaForm$Kind
In-Reply-To: <S-8nTDQCfllBLb5dcMSgzEFNxu0KrdBqy5UDwSbp1Vo=.ea38962f-9dbb-463f-a429-a0670df13657@github.com>
References: <S-8nTDQCfllBLb5dcMSgzEFNxu0KrdBqy5UDwSbp1Vo=.ea38962f-9dbb-463f-a429-a0670df13657@github.com>
Message-ID: <thTvSEUOdmuobXbmQJSWgGDV7x68pRt5swnCULLGij4=.91fd00a1-678b-4abf-84f7-535bbcd873dd@github.com>

On Sat, 19 Oct 2024 20:39:48 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially removing some unused left-over `LambdaForm$Kind` enums. 
> 
> - Last use of `COLLECT` and `SPREAD` was removed by fac39fe9
> - `FIELD` was added by 8d5f5b9a but had no usage from the start
> - Last use of `CONVERT` was removed by eda5f090

Makes sense.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21592#pullrequestreview-2384973579

From alanb at openjdk.org  Tue Oct 22 12:08:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 12:08:19 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>

On Tue, 22 Oct 2024 07:39:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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_r1810598265

From dholmes at openjdk.org  Tue Oct 22 12:20:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 12:20:13 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
Message-ID: <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>

On Tue, 22 Oct 2024 12:05:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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_r1810615473

From syan at openjdk.org  Tue Oct 22 12:30:24 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Oct 2024 12:30:24 GMT
Subject: RFR: 8341584: Test java/foreign/TestUpcallStress.java intermittent
 timeout with -Xcomp
In-Reply-To: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
References: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
Message-ID: <n7XghbfZ9-s5rp1WAhN2cs--HA-BJz2S0av7VYo2jjA=.cc906965-7d3d-4ec4-a017-20ac2df63aac@github.com>

On Tue, 15 Oct 2024 01:25:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `java/foreign/TestUpcallStress.java` intermittent timeout with -Xcomp, and this test use a very precise race, thus `-Xcomp` probably will never trigger the problematic use-case. So this test not suitable for -Xcomp mode.I add `@requires vm.compMode != "Xcomp"` to exclude from Xcomp testing and remove this test from `ProblemList-Xcomp.txt`.
> Trivial fix, test-fix only, no risk.

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21512#issuecomment-2429145098

From syan at openjdk.org  Tue Oct 22 12:30:24 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Oct 2024 12:30:24 GMT
Subject: Integrated: 8341584: Test java/foreign/TestUpcallStress.java
 intermittent timeout with -Xcomp
In-Reply-To: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
References: <RiFUtgvf-i4OccbEj1geE1haZyERDGGyfMI4h7Gd4hU=.8161296e-17aa-4ebc-a763-3ee87497390b@github.com>
Message-ID: <jzWfaa0QsBNYKExMfTsxqlW0OS--_igHmCPXE_QQk2o=.ac7ecc11-b61c-444a-a60c-04efc41f1d65@github.com>

On Tue, 15 Oct 2024 01:25:56 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `java/foreign/TestUpcallStress.java` intermittent timeout with -Xcomp, and this test use a very precise race, thus `-Xcomp` probably will never trigger the problematic use-case. So this test not suitable for -Xcomp mode.I add `@requires vm.compMode != "Xcomp"` to exclude from Xcomp testing and remove this test from `ProblemList-Xcomp.txt`.
> Trivial fix, test-fix only, no risk.

This pull request has now been integrated.

Changeset: 3b71657f
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b71657f5995482d26c36209f72650fbf672a965
Stats:     2 lines in 2 files changed: 1 ins; 1 del; 0 mod

8341584: Test java/foreign/TestUpcallStress.java intermittent timeout with -Xcomp

Reviewed-by: jpai, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/21512

From duke at openjdk.org  Tue Oct 22 12:32:52 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Oct 2024 12:32:52 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v14]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <8dWkGgJOodaqnc3bh1EyXPiH7JRdW07Z4lefw0RQ4Rg=.a86c336f-4be6-47c7-808d-d4edf2ebced4@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:

  Refine documentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/f90cea6a..e9a5a769

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=12-13

  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 alanb at openjdk.org  Tue Oct 22 12:34:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 12:34:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
Message-ID: <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>

On Tue, 22 Oct 2024 12:17:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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_r1810636960

From duke at openjdk.org  Tue Oct 22 12:38:01 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Oct 2024 12:38:01 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v15]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <QkujoINJLQiWpSgEI5lscjf7cF5by4TxlbDK0URFd70=.cdede7fa-08c8-439f-ad15-181b70577c34@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:

  Refine documentation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/e9a5a769..cf4a449d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=13-14

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 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 alanb at openjdk.org  Tue Oct 22 12:45:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 12:45:21 GMT
Subject: RFR: 8319343: Improve CDS module graph support for --add-modules
 option [v2]
In-Reply-To: <o_2MW9hK5TGalHl-IRfyCV4ayQxzsFGXQBmvFpE1gNU=.ea65856a-4a4f-4fde-9d05-4d749dc9960f@github.com>
References: <jogURZ2gxfRkCaiI58Pf_JMEZwaK4JVYMvSXOJ-0X_8=.9c77ea88-d20b-4f6b-b5e3-3a541bd4319d@github.com>
 <MEXuMA7PWvze61-JglQK2hAASioMTgHz59zXFUJQNT0=.a07d3fdb-ced1-44a7-9a21-d29fd7c88c7c@github.com>
 <4nH8pVUf8BoCEwWAC3RunrTlXCSd5GHDPJg6IIw43R8=.a2826545-e806-4040-869e-25addf4e5967@github.com>
 <XrXj8FniaIuTgsltC7dZN1q8CbfQph7HZD4T2C6w5Rc=.1a7ca347-0f6d-4254-be0a-6ccb6180b1c5@github.com>
 <IcYaZzoR8TI1bDbVt_S_axnK6hxtnhYpG-pP1qYgQPg=.7f915220-4f8b-4c80-a486-ccc0ad0d14b7@github.com>
 <o_2MW9hK5TGalHl-IRfyCV4ayQxzsFGXQBmvFpE1gNU=.ea65856a-4a4f-4fde-9d05-4d749dc9960f@github.com>
Message-ID: <teQPCmz_DsO_0UFRPdR5hgxroU4u5_3BXiACS9BMPDY=.1f0bfb2d-0759-4a48-b93a-9b25cd4c0654@github.com>

On Mon, 21 Oct 2024 16:29:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Good point as ALL-SYSTEM and ALL-MODULE-PATH are allowed in the value. I assume you don't need to special case the single value case as this is dump time so not performance critical.
>
> I've removed the `if` check at the beginning of the method.

Thanks, I'll get back to you on but I want see how this will behave with ALL-MODULE-PATH as that will sometimes appear in Maven environments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21553#discussion_r1810653443

From duke at openjdk.org  Tue Oct 22 12:49:08 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 22 Oct 2024 12:49:08 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v8]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <ELfo-c5mx1cvcf49gJTt_L_-kxq-QWZdN5QlEsdZH0Q=.3e46bd59-e684-411d-8497-5dc3701ae594@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 incrementally with one additional commit since the last revision:

  Round out the documentation of the new methods to explain the supported and unsupported cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19702/files
  - new: https://git.openjdk.org/jdk/pull/19702/files/11bc95e8..997dba08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=06-07

  Stats: 68 lines in 1 file changed: 57 ins; 0 del; 11 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 galder at openjdk.org  Tue Oct 22 13:16:25 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 22 Oct 2024 13:16:25 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: <y3QBXx3AmozmxxTST0xHJbIY-Ej8r4n_fOmzOaZ1NhI=.74234f19-128a-432c-a8ee-f91801b9e1b5@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/8c2fe27c...0a8718e1

The CI failure was on downloading boot JDK

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2429253091

From mli at openjdk.org  Tue Oct 22 13:17:30 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 22 Oct 2024 13:17:30 GMT
Subject: RFR: 8327624: Remove VM implementation that bypass verification
 for core reflection [v2]
In-Reply-To: <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
 <lbyRUFSx1VQw1lq8e4PyoQf7OukL9Lze3QsU7M-3pmE=.a627824c-4648-415a-822b-3dbb09df19b7@github.com>
Message-ID: <YdGTI2fl025IbjZgYLv4sFiz2TwFA1eKPmmncYNfz78=.9ae6c20a-de16-4cce-926b-84fb7f86cc22@github.com>

On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
>> 
>> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
>> 
>> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
>> 
>> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
>> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
>> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused classes

Looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21571#pullrequestreview-2385172700

From dfuchs at openjdk.org  Tue Oct 22 13:37:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Oct 2024 13:37:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>
Message-ID: <AOTi73-spmeUDB5J44UY2JsXYmZN9rNHl8oXlXTlgDQ=.f159726c-1867-4c4e-9a44-86bd185f763c@github.com>

On Tue, 22 Oct 2024 11:50:13 GMT, Michael McMahon <michaelm 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/net/URLPermission/OpenURL.java line 30:
> 
>> 28:  * @run main/othervm OpenURL
>> 29:  */
>> 30: 
> 
> Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

It could - but technically openConnection / getInputStream could still throw if there was an issue with the provided URL. The difference here is that with a SecurityManager the connection would be rejected with a SecurityException before the connection was made. Without a security manager, the connection will go through, so you need the server simulation (can't rely on getting IOException assuming nobody would be listening).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810741690

From hannesw at openjdk.org  Tue Oct 22 13:41:27 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 13:41:27 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
Message-ID: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>

Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.

We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.

I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

-------------

Commit messages:
 - 8342827: Fix order of @param tags in other modules

Changes: https://git.openjdk.org/jdk/pull/21637/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342827
  Stats: 144 lines in 28 files changed: 58 ins; 58 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21637/head:pull/21637

PR: https://git.openjdk.org/jdk/pull/21637

From aboldtch at openjdk.org  Tue Oct 22 13:50:32 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 22 Oct 2024 13:50:32 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <qvYgffEQcyKQk1ojTcELnXVEQHQj1VcKgP-WxTiGVIE=.a50014b9-52d2-48ac-a5c7-4c506f68db09@github.com>

On Tue, 22 Oct 2024 02:14: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 six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

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;
   }
 ```

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810764911

From aboldtch at openjdk.org  Tue Oct 22 13:54:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 22 Oct 2024 13:54:36 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>

On Tue, 22 Oct 2024 02:14: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 six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810772765

From redestad at openjdk.org  Tue Oct 22 13:54:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 13:54:35 GMT
Subject: RFR: 8341776: Remove unused enum values from LambdaForm$Kind
In-Reply-To: <S-8nTDQCfllBLb5dcMSgzEFNxu0KrdBqy5UDwSbp1Vo=.ea38962f-9dbb-463f-a429-a0670df13657@github.com>
References: <S-8nTDQCfllBLb5dcMSgzEFNxu0KrdBqy5UDwSbp1Vo=.ea38962f-9dbb-463f-a429-a0670df13657@github.com>
Message-ID: <8_KHmIrLeTt1FdWMEu5HzRpFt66_O4ctfeeRScXB9IA=.6486b5b2-4542-4ae2-9b38-099f241685d4@github.com>

On Sat, 19 Oct 2024 20:39:48 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially removing some unused left-over `LambdaForm$Kind` enums. 
> 
> - Last use of `COLLECT` and `SPREAD` was removed by fac39fe9
> - `FIELD` was added by 8d5f5b9a but had no usage from the start
> - Last use of `CONVERT` was removed by eda5f090

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21592#issuecomment-2429349036

From redestad at openjdk.org  Tue Oct 22 13:54:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 22 Oct 2024 13:54:36 GMT
Subject: Integrated: 8341776: Remove unused enum values from LambdaForm$Kind
In-Reply-To: <S-8nTDQCfllBLb5dcMSgzEFNxu0KrdBqy5UDwSbp1Vo=.ea38962f-9dbb-463f-a429-a0670df13657@github.com>
References: <S-8nTDQCfllBLb5dcMSgzEFNxu0KrdBqy5UDwSbp1Vo=.ea38962f-9dbb-463f-a429-a0670df13657@github.com>
Message-ID: <pRK-MD5zF2reaDsIUerWySLsA_1Wsjautt34KL1YWMY=.6e6172a9-b017-46d1-b408-55581f35efd0@github.com>

On Sat, 19 Oct 2024 20:39:48 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivially removing some unused left-over `LambdaForm$Kind` enums. 
> 
> - Last use of `COLLECT` and `SPREAD` was removed by fac39fe9
> - `FIELD` was added by 8d5f5b9a but had no usage from the start
> - Last use of `CONVERT` was removed by eda5f090

This pull request has now been integrated.

Changeset: d10eecf1
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d10eecf1619903fadea7eca9afd6bb154831ae50
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8341776: Remove unused enum values from LambdaForm$Kind

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21592

From duke at openjdk.org  Tue Oct 22 14:07:30 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 22 Oct 2024 14:07:30 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v16]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <nY3sJr9lXOao2s22hkRnSUmDeLZtdz2JFBYyt5A3iyY=.6b20357a-4d2f-4765-b117-b08d921f6684@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/cf4a449d..a4e85944

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=14-15

  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 sgehwolf at openjdk.org  Tue Oct 22 14:14:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 22 Oct 2024 14:14:11 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v39]
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: <kQEI8nXxNPVyq7FDHe5yuDu_AYVO78KZu1ThpVSrxVg=.16226736-384c-4ec0-a81f-0d9c2970b416@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 146 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Only show info message about runtime link when verbose
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Update error message when linking jdk.jlink
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - JLinkDedupTestBatchSizeOne.java test fix
   
   Run only the packaged modules version if we have a linkable JDK runtime
   with packaged modules available as well in the JDK install.
 - ... and 136 more: https://git.openjdk.org/jdk/compare/2da7f2bc...22eb4b89

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=38
  Stats: 3960 lines in 42 files changed: 3763 ins; 117 del; 80 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 dfuchs at openjdk.org  Tue Oct 22 14:15:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Oct 2024 14:15:40 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Changes to java.management, java.naming, and sctp look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2385344473

From sgehwolf at openjdk.org  Tue Oct 22 14:18:50 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 22 Oct 2024 14:18:50 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v11]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <64ooaT_1G3AIl9kLn2ms8Q4GoNLequhhcD05LIETN3g=.449e4916-2770-48f6-b5a8-aa07d6ffeab6@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 36 commits:

 - 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
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - ... and 26 more: https://git.openjdk.org/jdk/compare/2da7f2bc...a3989e80

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=10
  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 fferrari at openjdk.org  Tue Oct 22 14:20:22 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Tue, 22 Oct 2024 14:20:22 GMT
Subject: RFR: 8315487: Security Providers Filter
In-Reply-To: <MGWlCXFwtzVMDpiiyAjqfhf8iHKwuscNVRwmbVStYU8=.d551cd82-2887-42a7-93ec-af1fdd40e7e8@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
 <MGWlCXFwtzVMDpiiyAjqfhf8iHKwuscNVRwmbVStYU8=.d551cd82-2887-42a7-93ec-af1fdd40e7e8@github.com>
Message-ID: <FICnVvpvXWv3p-ZlZqsBbDPXqBLK29HvEKBsArPM9XI=.74518e72-f2de-4ab5-a1e4-5109b7052c78@github.com>

On Fri, 6 Oct 2023 17:06:03 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...
>
> I wish we could keep this PR open. This is the latest comment in the ongoing discussion: https://mail.openjdk.org/pipermail/security-dev/2023-October/037479.html

The push to @martinuy's fork didn't execute the tests, so I pushed a temporary copy of the branch to my own fork. This is the [full run for `6a3666f6`](https://github.com/franferrax/jdk/actions/runs/11459373829), no regressions detected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2429415789

From rgiulietti at openjdk.org  Tue Oct 22 14:21:34 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 22 Oct 2024 14:21:34 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v3]
In-Reply-To: <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@github.com>
Message-ID: <XH7y_mjnCS_xZktPvUH_1HrS6itVKZxsklbCf0Hq3tw=.1d367e86-c1a7-4604-bb4a-64095f1cb942@github.com>

On Mon, 21 Oct 2024 17:07:35 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 seven additional commits since the last revision:
> 
>  - Add @since tag, respond to review feedback.
>  - Merge branch 'master' into JDK-8341260
>  - Remove comments for intrinsics per review feedback.
>  - Update with changes from lworld+fp16 Float16.
>  - Merge branch 'master' into JDK-8341260
>  - Add support for BigDecimal -> Float16 conversion.
>  - JDK-8341260: Add Float16 to jdk.incubator.vector

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 471:

> 469: //                     }
> 470: //                 }
> 471: //             }

Suggestion:

             int scale = bd.scale();
             BigInteger unscaledValue = bd.unscaledValue();

             if (unscaledValue.abs().compareTo(BigInteger.valueOf(Long.MAX_VALUE)) <= 0) {
                 long intCompact = unscaledValue.longValue();
                 Float16 v = Float16.valueOf(intCompact);
                 if (scale == 0) {
                     return v;
                 }
                 /*
                  * The discussion for the double case also applies here. That is,
                  * the following test is precise for all long values, but here
                  * Long.MAX_VALUE is not an issue.
                  */
                 if (v.longValue() == intCompact) {
                     if (0 < scale && scale < FLOAT16_10_POW.length) {
                         return Float16.divide(v, FLOAT16_10_POW[scale]);
                     }
                     if (0 > scale && scale > -FLOAT16_10_POW.length) {
                         return Float16.multiply(v, FLOAT16_10_POW[-scale]);
                     }
                 }
             }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1810823357

From liach at openjdk.org  Tue Oct 22 14:43:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 14:43:14 GMT
Subject: RFR: 8342206: Convenience method to check if a ClassEntry matches
 a ClassDesc [v3]
In-Reply-To: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
References: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
Message-ID: <JXcDw2p-JNjXPEjYGmWXQVCSyZFHmJhImXKwmwBAT68=.d5c8e49f-ab8c-4e5c-b13a-a4ad36be7c62@github.com>

> Currently, to efficiently check if a `ClassEntry`, such as one from an `InvokeInstruction`, is of a particular class, we use such a pattern (as seen in JEP 486 [Appendix](https://openjdk.org/jeps/486#Appendix)):
> 
> inst.owner().name().equalsString("java/lang/System")
> 
> This pattern has a few issues:
> 
> 1. This is not straightforward. Users may be tempted to write
> 
> inst.owner().asSymbol().equals(CD_System)
> 
> unaware of the degraded performance from extra conversions.
> 
> 2. We aim to reduce the use of "internal names" with encapsulation. Direct use of `"java/lang/System"` goes against this, and we have no constants offered to reduce such error-prone use of internal name.
> 
> Thus, I propose a new API in `ClassEntry`:
> 
> boolean equalsSymbol(ClassDesc)
> 
> that can be used conveniently to check the identity of a class entry with a clean syntax and better performance.

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 five additional commits since the last revision:

 - Merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-equalssym
 - Reuse cache for arrays, replace some use cases
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-equalssym
 - 8342206: Convenience method to check if a ClassEntry matches a ClassDesc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21526/files
  - new: https://git.openjdk.org/jdk/pull/21526/files/54139eae..7f5a7ac4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21526&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21526&range=01-02

  Stats: 100400 lines in 564 files changed: 97301 ins; 2208 del; 891 mod
  Patch: https://git.openjdk.org/jdk/pull/21526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21526/head:pull/21526

PR: https://git.openjdk.org/jdk/pull/21526

From viktor.klang at oracle.com  Tue Oct 22 15:05:39 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 22 Oct 2024 15:05:39 +0000
Subject: [External] : Re: Streams, parallelization, and OOME.
In-Reply-To: <CAA9v-_PYBxNog13ca5WSgrcst4aDhH=KJPYUf5_hk1pCu9LD4Q@mail.gmail.com>
References: <CAA9v-_MH50D0RN6iZJmH29vEpLSX533u8fPuU76LiX=2KL4CvQ@mail.gmail.com>
 <MW4PR10MB5774C64231E4C0A5CE971AF2FF432@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_PYBxNog13ca5WSgrcst4aDhH=KJPYUf5_hk1pCu9LD4Q@mail.gmail.com>
Message-ID: <MW4PR10MB5774D4B14875B6A2019144CBFF4C2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi David,

You're most welcome, I hope you can migrate to Gatherers successfully in the near future. ?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Tuesday, 22 October 2024 07:10
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: [External] : Re: Streams, parallelization, and OOME.


Thanks Viktor, this was what I was looking for.

Ok, so due to existing difficulties in translating push to pull, it makes sense why this wouldn't work.

I really look forward to upgrading my codebase soon. Gatherers fixed window completely negates this problem. At least, it appears to.

On Mon, Oct 21, 2024, 6:54?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi David,

Stream::spliterator() and Stream::iterator() suffer from inherent limitations (see https://bugs.openjdk.org/browse/JDK-8268483 ) because they attempt to convert push-style streams into pull-style constructs (Iterator, Spliterator). Since the only way to know if there's something to pull is for something to get pushed, but who's doing to pushing (answer: the same one who tries to do the pulling)?

For sequential Streams this is often as problematic, but for parallel streams it's not the caller which evaluates the stream but rather a task-tree submitted to a ForkJoinPool. You can see the implementation here: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/StreamSpliterators.java#L272<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/StreamSpliterators.java*L272__;Iw!!ACWV5N9M2RV99hQ!MSjhcxVOz1JA70k0u0-uZ21Kr6FwnlVKfIPB6BlH33FbF_8Vhv1J7xmWDVDo4q5EFPghubFnWwTpn3jmJ0747MaQFoU$>

As an example, Stream::flatMap(?) had corner cases where its use of Stream::spliterator() would end up not terminating, which was fixed in Java 23: https://github.com/openjdk/jdk/pull/18625<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/18625__;!!ACWV5N9M2RV99hQ!MSjhcxVOz1JA70k0u0-uZ21Kr6FwnlVKfIPB6BlH33FbF_8Vhv1J7xmWDVDo4q5EFPghubFnWwTpn3jmJ074sCSPtmg$>
[https://opengraph.githubassets.com/0c04ee3059849e8b8dd4ac103bc00db5b08ff8b3bd56c826c9e7ea86105f4824/openjdk/jdk/pull/18625]<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/18625__;!!ACWV5N9M2RV99hQ!MSjhcxVOz1JA70k0u0-uZ21Kr6FwnlVKfIPB6BlH33FbF_8Vhv1J7xmWDVDo4q5EFPghubFnWwTpn3jmJ074sCSPtmg$>
8196106: Support nested infinite or recursive flat mapped streams by viktorklang-ora ? Pull Request #18625 ? openjdk/jdk<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/18625__;!!ACWV5N9M2RV99hQ!MSjhcxVOz1JA70k0u0-uZ21Kr6FwnlVKfIPB6BlH33FbF_8Vhv1J7xmWDVDo4q5EFPghubFnWwTpn3jmJ074sCSPtmg$>
This PR implements Gatherer-inspired encoding of flatMap that shows that it is both competitive performance-wise as well as improve correctness. Below is the performance of Stream::flatMap (for ref...
github.com<https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!MSjhcxVOz1JA70k0u0-uZ21Kr6FwnlVKfIPB6BlH33FbF_8Vhv1J7xmWDVDo4q5EFPghubFnWwTpn3jmJ074XBXngn8$>




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: Saturday, 19 October 2024 07:54
To: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Streams, parallelization, and OOME.

Hello Core Libs Dev Team,

I have a file that I am streaming from a service, and I am trying to split into multiple parts based on a certain attribute found on each line. I am sending each part up to a different service.

I am using BufferedReader.lines(). However, I cannot read the whole file into memory because it is larger than the amount of RAM that I have on the machine. So, since I don't have access to Java 22's Preview Gatherers Fixed Window, I used the iterator() method on my stream, wrapped that in another iterator that can grab my batch size worth of data, then built a spliterator from that that I then used to create a new stream. In short, this wrapper iterator isn't Iterator<T>, it's Iterator<List<T>>.

When I ran this sequentially, everything worked well. However, my CPU was low and we definitely have a performance problem -- our team needs this number as fast as we can get. Plus, we had plenty of network bandwidth to spare, so I had (imo) good reason to go use parallelism.

As soon as I turned on parallelism, the stream's behaviour changed completely. Instead of fetching the batch and processing, it started grabbing SEVERAL BATCHES and processing NONE OF THEM. Or at the very least, it grabbed so many batches that it ran out of memory before it could get to processing them.

To give some numbers, this is a 4 core machine. And we can safely hold about 30-40 batches worth of data in memory before crashing. But again, when running sequentially, this thing only grabs 1 batch, processes that one batch, sends out the results, and then start the next one, all as expected. I thought that adding parallelism would simply make it so that we have this happening 4 or 8 times at once.

After a very long period of digging, I managed to find this link.

https://stackoverflow.com/questions/30825708/java-8-using-parallel-in-a-stream-causes-oom-error<https://urldefense.com/v3/__https://stackoverflow.com/questions/30825708/java-8-using-parallel-in-a-stream-causes-oom-error__;!!ACWV5N9M2RV99hQ!MSjhcxVOz1JA70k0u0-uZ21Kr6FwnlVKfIPB6BlH33FbF_8Vhv1J7xmWDVDo4q5EFPghubFnWwTpn3jmJ074pm-0Z8w$>

Tagir Valeev gives an answer which doesn't go very deep into the "why" at all. And the answer is more directed to the user's specific question as opposed to solving this particular problem.

After digging through a bunch of other solutions (plus my own testing), it seems that the answer is that the engine that does parallelization for Streams tries to grab a large enough "buffer" before doing any parallel processing. I could be wrong, and how large that buffer is? I have no idea.

Regardless, that's about where I gave up and went sequential, since the clock was ticking.

But I still have a performance problem. How would one suggest going about this in Java 8?

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/20241022/533d0fbc/attachment-0001.htm>

From rriggs at openjdk.org  Tue Oct 22 15:06:24 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Oct 2024 15:06:24 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v4]
In-Reply-To: <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
Message-ID: <kH5YQrEy3aYOQS-DgprzfI_XlGJIEDj9hHwd7joElEc=.c8159faa-1b84-4550-b01e-e61493afeb46@github.com>

On Mon, 21 Oct 2024 17:49:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21569#pullrequestreview-2385501032

From jpai at openjdk.org  Tue Oct 22 15:08:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Oct 2024 15:08:16 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Hello Hannes, since `@param` requires a parameter name and since javadoc already warns about incorrect `@param` names (that don't match the name of the method parameter), does the order in which the `@param` is listed in the javadoc text matter? I looked at https://bugs.openjdk.org/browse/JDK-8279931 but that doesn't tell why the order would be important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429541439

From liach at openjdk.org  Tue Oct 22 15:15:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 15:15:14 GMT
Subject: RFR: 8250659: Clarify in ParameterizedType.getRawType() doc that
 only Class is returned [v2]
In-Reply-To: <t5grGPxpTMli38FUPJlLcpv0Iirx7-4jYdfC1wz79Ik=.b33f6727-d2cd-4ce0-8e59-7a25d9b451c3@github.com>
References: <t5grGPxpTMli38FUPJlLcpv0Iirx7-4jYdfC1wz79Ik=.b33f6727-d2cd-4ce0-8e59-7a25d9b451c3@github.com>
Message-ID: <sBt_vMpOqBFK2OryFBYAt1T6XtW67UYxaQrqnvsJ7ks=.7d736b2d-ac15-41c5-86e8-7b03282a7b4f@github.com>

> Clarify that only `Class` is returned for core reflection implementation, and the return type is `Type` to support other implementations, such as ones modeling unloaded or remote types.

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 three additional commits since the last revision:

 - Reword
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/raw-type
 - 8250659: Clarify in ParameterizedType.getRawType() doc that only Class is returned

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19978/files
  - new: https://git.openjdk.org/jdk/pull/19978/files/ab617da5..e9ca21a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19978&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19978&range=00-01

  Stats: 435100 lines in 4440 files changed: 368107 ins; 41407 del; 25586 mod
  Patch: https://git.openjdk.org/jdk/pull/19978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19978/head:pull/19978

PR: https://git.openjdk.org/jdk/pull/19978

From aph at openjdk.org  Tue Oct 22 15:26:30 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:26:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>

On Tue, 22 Oct 2024 02:14: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 six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

>     * 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2429587519

From mullan at openjdk.org  Tue Oct 22 15:28:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Oct 2024 15:28:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
Message-ID: <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>

On Tue, 22 Oct 2024 08:09:01 GMT, Prasanta Sadhukhan <psadhukhan 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:
> 
>> 24: import javax.swing.SwingUtilities;
>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
>> 26: /*
> 
> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.

> test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:
> 
>> 29: /**
>> 30:  * @test
>> 31:  * @key headful
> 
> javadoc style /** at the beginning

Not specific to JEP 486, this should be done as part of a different issue.

> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 66:
> 
>> 64:         }
>> 65: 
>> 66:         // Show popup as if from an applet
> 
> remove applet

Not specific to JEP 486, this should be done as part of a different issue.

> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 6622002
>> 29:  * @author Alexander Potochkin
> 
> remove @author tag

Not specific to JEP 486, this should be done as part of a different issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810939227
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810942471
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810943153
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810943359

From iklam at openjdk.org  Tue Oct 22 15:35:43 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 15:35:43 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <7omxfwDgvafhEV_y55J67oh1mv89mcbOXtMwdhwHCS4=.bca52790-c031-4b68-80f8-0ead581a1b7b@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
 <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
 <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>
 <7omxfwDgvafhEV_y55J67oh1mv89mcbOXtMwdhwHCS4=.bca52790-c031-4b68-80f8-0ead581a1b7b@github.com>
Message-ID: <PEOfgnY1tuFdYetoWDoxDhAUBE9HOu02a82WGCSlGMg=.86136092-3126-437c-8e9c-5856ce39b431@github.com>

On Tue, 22 Oct 2024 07:06:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I changed the code to `assert(is_pending_aot_linked_class(k), "sanity")`. Since iterator.hpp is widely used, I avoid including aotLinkedClassBulkLoader.hpp in this header, and route the call through iterator.cpp.
>
> My proposal was to use it in this file (iterator.inline.hpp) and not iterator.hpp. I see no need to route this through the .cpp file.

iterator.inline.hpp is included by many cpp file (580 out of 1409 .o files in hotspot), so I don't want to add aotLinkedClassBulkLoader.hpp to it.


scanning    580 iterator.inline.hpp
   2 found    580 oop.inline.hpp
   3 found    580 zIterator.inline.hpp
   4 found    580 zBarrierSet.inline.hpp
   5 found     60 g1OopClosures.inline.hpp
   6 found      7 g1FullGCOopClosures.inline.hpp
   7 found      5 psPromotionManager.inline.hpp

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1810959378

From aph at openjdk.org  Tue Oct 22 15:40:14 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:40:14 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>

On Tue, 22 Oct 2024 02:14: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 six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810966647

From liach at openjdk.org  Tue Oct 22 15:50:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 15:50:14 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v4]
In-Reply-To: <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
Message-ID: <8wMMcb0fZtgKEC4UYt35mfRNUMP_bMDYZyJzvxCCHCQ=.eabe2955-1e96-4f67-9b24-186d669b98d7@github.com>

On Mon, 21 Oct 2024 17:49:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/java/lang/System.java line 150:

> 148:      * specified by the host environment or user. The encoding used
> 149:      * in the conversion from characters to bytes is equivalent to
> 150:      * <a href="#stdout.encoding">stdout.encoding</a>.

Suggestion:

     * {@systemProperty stdout.encoding}.


This defines the anchor with the same id, and also makes this property available for javadoc index search. Example includes the system property at https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/ClassLoader.html#java.system.class.loader

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21569#discussion_r1810979391

From aph at openjdk.org  Tue Oct 22 15:53:21 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:53:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
Message-ID: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>

On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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 aph at openjdk.org  Tue Oct 22 15:53:24 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:53:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>

On Tue, 22 Oct 2024 02:14: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 six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

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 Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810987929
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810989022

From aph at openjdk.org  Tue Oct 22 15:58:24 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:58:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
Message-ID: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@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 psandoz at openjdk.org  Tue Oct 22 15:59:38 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 22 Oct 2024 15:59:38 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
Message-ID: <vUK5ijP4bDH0P3SKlKcdY3g2D45oROAFDBPCqCda15o=.901e3d96-629a-4b60-b57f-e3137c2a964a@github.com>

On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Factor out IR tests and Transforms to follow-up PRs.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2385653877

From psandoz at openjdk.org  Tue Oct 22 15:59:38 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 22 Oct 2024 15:59:38 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
 <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>
Message-ID: <FzDMi0bp6vzxLkpXz4li9u-odivGOdvSN8xPva9GI9c=.e5356fe6-33cb-4753-b86d-f6edc04f7ad2@github.com>

On Mon, 21 Oct 2024 12:25:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Can you kindly run this though your test infrastructure and approve if it goes fine ?
>

Internal tier 1 to 3 testing passed (i needed to merge with master at 7133d1b983d, due to some updates to unrelated test configuration files the test infrastructure expects).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2429666927

From bpb at openjdk.org  Tue Oct 22 16:05:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 16:05:42 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
 <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
Message-ID: <CPDYC8n3_a3QGffwYvCjoSO9MdK_VJ8kw3MdezTBsV0=.cbfd98e1-f7ef-4f70-b076-d70e3231d6c3@github.com>

On Tue, 22 Oct 2024 10:15:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8233451: Add tests for read{All,N}Bytes
>
> test/jdk/java/nio/file/Files/InputStreamTest.java line 29:
> 
>> 27:  * @library .. /test/lib
>> 28:  * @build jdk.test.lib.Platform
>> 29:  * @run junit InputStreamTest
> 
> I think this will need --enable-native-access=ALL-UNNAMED.

It works as is in the CI.

> test/jdk/java/nio/file/Files/InputStreamTest.java line 99:
> 
>> 97:                     try {
>> 98:                         try (FileOutputStream fos = new FileOutputStream(PIPE);)
>> 99:                         {
> 
> The formatting is a bit messed up, I think a previous iteration has a second resource that is now removed.

Thanks, I'll clean it up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1811008472
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1811009366

From stefank at openjdk.org  Tue Oct 22 16:08:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 16:08:39 GMT
Subject: RFR: 8293336: AOT-linking of invokedynamic for lambda expression
 and string concat [v10]
In-Reply-To: <PEOfgnY1tuFdYetoWDoxDhAUBE9HOu02a82WGCSlGMg=.86136092-3126-437c-8e9c-5856ce39b431@github.com>
References: <If2hatrWB-ufwYht3xk6uqMHB89F1rcel7Fralyn64k=.d8e032c5-ff41-4bf0-903d-b2ff3f2f7c4a@github.com>
 <1eVagVsklhB2Qrq07mXvqfurHx9ovAnSFa4okzdjMfM=.5846f16d-62f2-4e7c-93e1-36bc243fa80a@github.com>
 <KMvTkr0L6OzImMjr-t1uzV8Zdd7RtF3YN3J5VTz0VOg=.6a87a57c-a533-4cdc-b82b-a222308313a2@github.com>
 <LOMOqs0rAcrTZMHmgsLhJlIvrSI3mwNUegsDUDZJP1w=.bf2aef36-2b25-46f4-82f6-241d7512eb44@github.com>
 <7omxfwDgvafhEV_y55J67oh1mv89mcbOXtMwdhwHCS4=.bca52790-c031-4b68-80f8-0ead581a1b7b@github.com>
 <PEOfgnY1tuFdYetoWDoxDhAUBE9HOu02a82WGCSlGMg=.86136092-3126-437c-8e9c-5856ce39b431@github.com>
Message-ID: <2NzD8szEoiVyDYb2ZSwdX6C8wXSWEDmv881xEjMmHLQ=.576942a1-1dec-4b09-aa53-203de4766c55@github.com>

On Tue, 22 Oct 2024 15:32:45 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> My proposal was to use it in this file (iterator.inline.hpp) and not iterator.hpp. I see no need to route this through the .cpp file.
>
> iterator.inline.hpp is included by many cpp file (580 out of 1409 .o files in hotspot), so I don't want to add aotLinkedClassBulkLoader.hpp to it.
> 
> 
> scanning    580 iterator.inline.hpp
>    2 found    580 oop.inline.hpp
>    3 found    580 zIterator.inline.hpp
>    4 found    580 zBarrierSet.inline.hpp
>    5 found     60 g1OopClosures.inline.hpp
>    6 found      7 g1FullGCOopClosures.inline.hpp
>    7 found      5 psPromotionManager.inline.hpp

>From what I can tell it is a tiny header with very few dependencies. I don't think we gain much by trying to prevent it from being include. I would strongly prefer to have cleaner code in iterator.hpp/cpp than trying to get rid of that include.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21143#discussion_r1811012268

From bpb at openjdk.org  Tue Oct 22 16:26:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 16:26:13 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
 <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
Message-ID: <zcxNbI4rEvbmjCTnFvq8J8b8RccqBD8hOovbA3-duB0=.770c4f47-a9f1-4757-be79-8c1a7f37f586@github.com>

On Tue, 22 Oct 2024 10:16:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you'll run the test many tests on all platforms to ensure its stability before integrating.

I already have to an extent but will run again with more platforms and repeats.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2429725100

From jpai at openjdk.org  Tue Oct 22 16:34:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Oct 2024 16:34:56 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v4]
In-Reply-To: <8wMMcb0fZtgKEC4UYt35mfRNUMP_bMDYZyJzvxCCHCQ=.eabe2955-1e96-4f67-9b24-186d669b98d7@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
 <8wMMcb0fZtgKEC4UYt35mfRNUMP_bMDYZyJzvxCCHCQ=.eabe2955-1e96-4f67-9b24-186d669b98d7@github.com>
Message-ID: <lcOEGwVOz4JnLsxdgYmKG7i7Bxxh3Ig_PkeDivbA7zA=.84df805f-fdcb-4c42-9cab-c4d5764b50d5@github.com>

On Tue, 22 Oct 2024 15:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/lang/System.java line 150:
> 
>> 148:      * specified by the host environment or user. The encoding used
>> 149:      * in the conversion from characters to bytes is equivalent to
>> 150:      * <a href="#stdout.encoding">stdout.encoding</a>.
> 
> Suggestion:
> 
>      * {@systemProperty stdout.encoding}.
> 
> 
> This defines the anchor with the same id, and also makes this property available for javadoc index search. Example includes the system property at https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/ClassLoader.html#java.system.class.loader

Hello Chen, the `{@systemProperty}` tag is expected to be used where the system property is being defined (the "Where should the tag be used?" section in https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056653.html). 
On this line, it's merely being referenced and the actual definition of this property is in the documentation of System.getProperties() method and there it correctly already uses a `{@systemProperty}` tag for this property https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/System.java#L790

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21569#discussion_r1811041477

From iklam at openjdk.org  Tue Oct 22 16:36:50 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 16:36:50 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking
Message-ID: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@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

-------------

Commit messages:
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - Merge branch 'jep-483-step-03-8329706-implement-xx-aot-class-linking' of /jdk3/yak/open into jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap
 - @calvinccheung review comments
 - @coleenp: No need to hold InvokeMethodIntrinsicTable_lock during bootstrap
 - Better fix for JDK-8342438: runtime/cds/SharedBaseAddress.java fails with Parallel and Serial GCs when running with AOTClassLinking enabled
 - (1) @ashu-mehra review comments - code simplfication; (2) fix bug in last commit
 - @DanHeidinga comments - removed dead code; added assert with ArchiveBuilder::has_been_buffered(src_ik)
 - Fixed JDK-8342732: java/lang/invoke/MethodTypeSecurityManager.java fails with "should never leak JDK internal class" in case AOTClassLinking enabled
 - ... and 142 more: https://git.openjdk.org/jdk/compare/8d0975a2...f0bc1ae6

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331497
  Stats: 6713 lines in 104 files changed: 5835 ins; 560 del; 318 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  Tue Oct 22 16:42:41 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 16:42:41 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v7]
In-Reply-To: <AFueBA58XCIF0EAP__qoGJtStxQMheYsRqYcsdHXJrk=.6da79931-0a15-4fdb-bfdf-71b4707823dd@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <AFueBA58XCIF0EAP__qoGJtStxQMheYsRqYcsdHXJrk=.6da79931-0a15-4fdb-bfdf-71b4707823dd@github.com>
Message-ID: <-T2rIN_-46ks05GaJQWqv96vpNNS-6rmdZ5Lo8o74V0=.7e07d815-afc9-4d91-aa1c-bc2d617748a1@github.com>

On Mon, 14 Oct 2024 05:33:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam 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 jep-483-step-01-8338017-add-aot-command-line-aliases
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
>  - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
>  - @macarte comments
>  - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
>  - @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c
>  - Fixed copyright dates
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
>  - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
>  - Fixed whitespaces
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/886cf507...d02959b8

Closing this PR as its changes have been combined into https://github.com/openjdk/jdk/pull/21642.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20516#issuecomment-2429737737

From iklam at openjdk.org  Tue Oct 22 16:42:41 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 16:42:41 GMT
Subject: Withdrawn: 8338017: Add AOT command-line flag aliases
In-Reply-To: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
Message-ID: <J2UR24tOagm27GyeGHGgtM3I8ubPT0CQXinM-w7Q0TQ=.fb5ed2fc-6658-4c68-87bf-86f6e2815bc3@github.com>

On Thu, 8 Aug 2024 22:50:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> Add the following command-line options as specified in JEP 483:
> 
> 
> - `-XX:AOTMode=off/record/create/auto/on`
> - `-XX:AOTConfiguration=<file>.aotconfig`
> - `-XX:AOTCache=<file>.aot`
> 
> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
> 
> Please see the CSR (TODO) for detailed specification.
> 
> -----
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20516

From hannesw at openjdk.org  Tue Oct 22 16:52:37 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 16:52:37 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>
Message-ID: <6rbSFaQrFn1gW7D8VtU2EqAQr4WoZKBdnapd9w3yEIU=.50bab757-b312-4b84-a220-e88fdd1f3bed@github.com>

On Tue, 22 Oct 2024 15:05:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hello Hannes, since `@param` requires a parameter name and since javadoc already warns about incorrect `@param` names (that don't match the name of the method parameter), does the order in which the `@param` is listed in the javadoc text matter? I looked at https://bugs.openjdk.org/browse/JDK-8279931 but that doesn't tell why the order would be important.

@jaikiran it does not matter for the generated documentation because we already [put the tags in the correct order][JDK-8234682]. So it's purely a code hygiene issue to make doc comments easier to read and maintain. 

[JDK-8234682]: https://bugs.openjdk.org/browse/JDK-8234682

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429770979

From hannesw at openjdk.org  Tue Oct 22 16:52:44 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 16:52:44 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>
Message-ID: <Ts-V7wU5tk83HEaK9oM4ECkbp8gfZF5vUPceOTp75sY=.4dd2318d-bfdd-4f40-956f-fe4fe3268585@github.com>

On Tue, 22 Oct 2024 14:12:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Changes to java.management, java.naming, and sctp look good to me.

Thanks @dfuch, setting reviewers to 2 for changes in the the remaining modules.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429782605

From prr at openjdk.org  Tue Oct 22 16:53:19 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Oct 2024 16:53:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
Message-ID: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>

On Tue, 22 Oct 2024 15:22:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:
>> 
>>> 24: import javax.swing.SwingUtilities;
>>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
>>> 26: /*
>> 
>> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...
>
> This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.

Agreed. This is not a "clean up / update tests" task.
If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.

>> test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:
>> 
>>> 29: /**
>>> 30:  * @test
>>> 31:  * @key headful
>> 
>> javadoc style /** at the beginning
>
> Not specific to JEP 486, this should be done as part of a different issue.

agreed. No need to touch.

>> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:
>> 
>>> 27:  * @test
>>> 28:  * @bug 6622002
>>> 29:  * @author Alexander Potochkin
>> 
>> remove @author tag
>
> Not specific to JEP 486, this should be done as part of a different issue.

agreed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811067982
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811068956
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811070418

From duke at openjdk.org  Tue Oct 22 16:56:13 2024
From: duke at openjdk.org (Markus KARG)
Date: Tue, 22 Oct 2024 16:56:13 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v14]
In-Reply-To: <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>
Message-ID: <01BFe8I-MdL1G_eusCz6CsjypXBxoT2gjPrZJ6JA384=.ed8b49fd-bcf0-4f21-abe8-d83a7366cbba@github.com>

On Mon, 21 Oct 2024 15:44:58 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed wording according to CSR discussion: '<p> The reader is initially open and reading starts at the first character in the sequence.'

@parttimenerd FYI :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2429790120

From naoto at openjdk.org  Tue Oct 22 16:56:36 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 16:56:36 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v5]
In-Reply-To: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
Message-ID: <dn-Z4mbLc3Lcp6mze_uLNKCBHnh66plcTY1ZpxUl-_U=.f8e49850-a58a-4326-9d01-cf5356dee095@github.com>

> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Changed HTML anchor to link tag, do the same for stderr.encoding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21569/files
  - new: https://git.openjdk.org/jdk/pull/21569/files/805365c6..c234961e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21569/head:pull/21569

PR: https://git.openjdk.org/jdk/pull/21569

From naoto at openjdk.org  Tue Oct 22 16:56:48 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 16:56:48 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v4]
In-Reply-To: <lcOEGwVOz4JnLsxdgYmKG7i7Bxxh3Ig_PkeDivbA7zA=.84df805f-fdcb-4c42-9cab-c4d5764b50d5@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
 <8wMMcb0fZtgKEC4UYt35mfRNUMP_bMDYZyJzvxCCHCQ=.eabe2955-1e96-4f67-9b24-186d669b98d7@github.com>
 <lcOEGwVOz4JnLsxdgYmKG7i7Bxxh3Ig_PkeDivbA7zA=.84df805f-fdcb-4c42-9cab-c4d5764b50d5@github.com>
Message-ID: <i7kdEzqtP_1wfn8mHMrZAk3cAlFRS88w7NKP8q4ia3o=.6a2111b7-8436-4fb1-81c1-8df898a955b2@github.com>

On Tue, 22 Oct 2024 16:26:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 150:
>> 
>>> 148:      * specified by the host environment or user. The encoding used
>>> 149:      * in the conversion from characters to bytes is equivalent to
>>> 150:      * <a href="#stdout.encoding">stdout.encoding</a>.
>> 
>> Suggestion:
>> 
>>      * {@systemProperty stdout.encoding}.
>> 
>> 
>> This defines the anchor with the same id, and also makes this property available for javadoc index search. Example includes the system property at https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/ClassLoader.html#java.system.class.loader
>
> Hello Chen, the `{@systemProperty}` tag is expected to be used where the system property is being defined (the "Where should the tag be used?" section in https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056653.html). 
> On this line, it's merely being referenced and the actual definition of this property is in the documentation of System.getProperties() method and there it correctly already uses a `{@systemProperty}` tag for this property https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/System.java#L790

@jaikiran is correct. `stdout.encoding` has already been searchable. That said, using HTML anchor tag can be replaced with link tag. Also this modification needs to be done for `stderr.encoding` too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21569#discussion_r1811080169

From liach at openjdk.org  Tue Oct 22 16:56:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 16:56:49 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v4]
In-Reply-To: <i7kdEzqtP_1wfn8mHMrZAk3cAlFRS88w7NKP8q4ia3o=.6a2111b7-8436-4fb1-81c1-8df898a955b2@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <fSqBi3q2tx5REfsqgp_maQedfo6EfYaE_bPPOXCalcY=.444f1e9b-7224-4324-8aec-21f7a5a59bd4@github.com>
 <8wMMcb0fZtgKEC4UYt35mfRNUMP_bMDYZyJzvxCCHCQ=.eabe2955-1e96-4f67-9b24-186d669b98d7@github.com>
 <lcOEGwVOz4JnLsxdgYmKG7i7Bxxh3Ig_PkeDivbA7zA=.84df805f-fdcb-4c42-9cab-c4d5764b50d5@github.com>
 <i7kdEzqtP_1wfn8mHMrZAk3cAlFRS88w7NKP8q4ia3o=.6a2111b7-8436-4fb1-81c1-8df898a955b2@github.com>
Message-ID: <N7dE1BmGCPvm-nfG_a2SkHBavnWUcTuSMAYEg7XGLjA=.609dd40b-b8bb-45fd-a3a7-f0ddd36fb2f7@github.com>

On Tue, 22 Oct 2024 16:53:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello Chen, the `{@systemProperty}` tag is expected to be used where the system property is being defined (the "Where should the tag be used?" section in https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056653.html). 
>> On this line, it's merely being referenced and the actual definition of this property is in the documentation of System.getProperties() method and there it correctly already uses a `{@systemProperty}` tag for this property https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/System.java#L790
>
> @jaikiran is correct. `stdout.encoding` has already been searchable. That said, using HTML anchor tag can be replaced with link tag. Also this modification needs to be done for `stderr.encoding` too.

Indeed my bad, this is an href instead of an id.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21569#discussion_r1811080521

From kvn at openjdk.org  Tue Oct 22 17:23:09 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Oct 2024 17:23:09 GMT
Subject: RFR: 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: <VwR8x8eHX4GRS-eJ8Jews-1USq4IA7IntX_ssJ3h7Wo=.abc387cc-b46a-4ffb-b683-f182a74b988d@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

Approved.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2385847834

From jlu at openjdk.org  Tue Oct 22 17:24:20 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Oct 2024 17:24:20 GMT
Subject: Integrated: 8341445: DecimalFormatSymbols setters should throw NPE
In-Reply-To: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
References: <uMN0_mrwVaNAgw093c9mlOHYiVpN2D5aHg5-SWD1Exw=.1f78c0c7-2f8b-4940-b181-8ba899a6c76d@github.com>
Message-ID: <5NhsQXzKTJKY50DyNkgDL11Q6ZmPuf_rMW4ua_zUJww=.2144180d-6961-4bf3-b189-abb7b0ac06d4@github.com>

On Wed, 2 Oct 2024 23:16:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves the safety of equality checking for DecimalFormatSymbols. As certain setters did not throw NPE, this allowed for NPE in the equality method. This PR now updates the setters to throw NPE.
> 
> In addition to the NPEs, there is also a behavioral change that `setInternationalCurrencySymbol` no longer sets currency to null if the `currencyCode` is invalid. Instead, it simply does not update `currency`. This must be done, because we do not want to allow nullable instance variables post `initalizeCurrency`.

This pull request has now been integrated.

Changeset: c61d2c5a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c61d2c5a3403ad5f48daad22bdfb031f42bc3dd5
Stats:     152 lines in 2 files changed: 122 ins; 15 del; 15 mod

8341445: DecimalFormatSymbols setters should throw NPE

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21315

From jlu at openjdk.org  Tue Oct 22 17:58:06 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Oct 2024 17:58:06 GMT
Subject: RFR: 8342807: Update links in java.base to use https://
In-Reply-To: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
References: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
Message-ID: <1sfWdB4G5a6orGYEOPhPZyttTp8cQ3BAqHyEiy5ot_I=.82094810-383b-43ec-ad37-df84ba8a8412@github.com>

On Tue, 22 Oct 2024 10:19:23 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http.
> 
> Links in `java.security` and `share/data/tzdata` are excluded from this PR.
> 
> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. 
> 
> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`).
> 
> Changes beyond the obvious  are as follows:
> 
> `linux/native/libsimdsort/xss-common-qsort.h`:
> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170
> 
> `share/man/keytool.1`:
> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well?
> 
> `unix/classes/sun/net/PortConfig.java`
> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports.
> 
> `unix/native/libjava/*`,
>  Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs
> 
> `unix/native/libjava/ProcessImpl_md.c`
> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to.

Most new links look fine to me/resolve correctly minus the comments. I believe we should not modify the non-Oracle copyright headers at all.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 109:

> 107:  * the jspawnhelper, then in the jspawnhelper we do the pre-exec work and exec a
> 108:  * second time, this time the target binary (similar to the "exec-twice-technique"
> 109:  * described in 'https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html).

Unintentional `'` was added.

src/java.base/unix/native/libjava/ProcessImpl_md.c line 204:

> 202:      * References:
> 203:      * https://pubs.opengroup.org/onlinepubs/7908799/xsh/exec.html
> 204:      * https://web.archive.org/web/20090106162458/http://www.pasc.org/interps/unofficial/db/p1003.1/pasc-1003.1-132.html

The new Wayback link does not resolve for me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21633#pullrequestreview-2385886437
PR Review Comment: https://git.openjdk.org/jdk/pull/21633#discussion_r1811137958
PR Review Comment: https://git.openjdk.org/jdk/pull/21633#discussion_r1811151881

From jlu at openjdk.org  Tue Oct 22 18:04:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Oct 2024 18:04:18 GMT
Subject: RFR: 8342807: Update links in java.base to use https://
In-Reply-To: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
References: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
Message-ID: <iHAILXwDhi0LJT3EAOwGhEwlF-biBchlFgQsnEVg9wI=.a0b4f39a-24a6-440a-9b3b-6186a0dcb80d@github.com>

On Tue, 22 Oct 2024 10:19:23 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http.
> 
> Links in `java.security` and `share/data/tzdata` are excluded from this PR.
> 
> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. 
> 
> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`).
> 
> Changes beyond the obvious  are as follows:
> 
> `linux/native/libsimdsort/xss-common-qsort.h`:
> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170
> 
> `share/man/keytool.1`:
> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well?
> 
> `unix/classes/sun/net/PortConfig.java`
> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports.
> 
> `unix/native/libjava/*`,
>  Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs
> 
> `unix/native/libjava/ProcessImpl_md.c`
> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to.

I think the interesting links are the ones being changed in `unix/native/libjava/ProcessImpl_md.c` and `unix/classes/sun/net/PortConfig.java` since the current ones no longer resolve. Since those will potentially require new links (with different content), I believe the change will require a CSR then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2429917256

From cjplummer at openjdk.org  Tue Oct 22 18:06:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 22 Oct 2024 18:06:08 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>

On Mon, 21 Oct 2024 14:34:30 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

src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 47:

> 45: {
> 46:     void *mappedMemory;
> 47:  // HANDLE memHandle;

Why comment out this one but not the one at line 88? It seems they are both equally problematic and are hiding the static memHandle. I'm not sure why the 2nd one isn't flagged. I'd actually suggest getting rid of the static memHandle. It does not seem to be needed.

src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 53:

> 51: #ifndef _WIN32
> 52: static MUTEX_T my_mutex = MUTEX_INIT;
> 53: #endif

The reason for no reference on windows is because of the following on windows:


#define MUTEX_LOCK(x)           /* FIXUP? */
#define MUTEX_UNLOCK(x)         /* FIXUP? */


So looks like this mutex support is something we never got around to. I think your current workaround is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1811166232
PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1811154735

From duke at openjdk.org  Tue Oct 22 18:09:06 2024
From: duke at openjdk.org (Louis Bergelson)
Date: Tue, 22 Oct 2024 18:09:06 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
Message-ID: <r662kCM8bAQA_NAvkT9KmmJeHFhrCPN2hG4cBJRGi54=.1dc5378c-7070-47a4-9c90-4e1ed7177670@github.com>

On Tue, 22 Oct 2024 02:40:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233451: Add tests for read{All,N}Bytes

? Thanks for these changes!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2429926276

From naoto at openjdk.org  Tue Oct 22 18:15:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 18:15:18 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works for
 21.0.5
Message-ID: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>

This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/21645/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342582
  Stats: 101 lines in 3 files changed: 74 ins; 20 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21645/head:pull/21645

PR: https://git.openjdk.org/jdk/pull/21645

From mchung at openjdk.org  Tue Oct 22 18:17:14 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Oct 2024 18:17:14 GMT
Subject: Integrated: 8327624: Remove VM implementation that bypass verification
 for core reflection
In-Reply-To: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
References: <FbYzd1pXYzjuVH-2IGf6wCT5p1Q9COACffUq4_W01ZA=.efd37356-defd-448f-a0cd-3b6e536fd3c1@github.com>
Message-ID: <U3D3JYxrkGhMuHA7eiGpsRppUWkpr2dQnySgEzZs1s4=.82584958-b3f3-4c5f-9bfb-41607d29e98a@github.com>

On Thu, 17 Oct 2024 20:45:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The old core reflection implementation generates dynamic classes that are special cases in the VM to bypass bytecode verification to workaround various issues [1] [2] [3].
> 
> The old core reflection implementation was [removed in JDK 22](https://bugs.openjdk.org/browse/JDK-8305104).   It's time to remove these VM hacks along with the old implementation of  `sun.reflect.ReflectionFactory::newConstructorForSerialization`.   
> 
> After this change, `jdk.internal.reflect.DelegatingClassLoader` no longer exists.   Hence the special metaspace for reflection is no longer needed.  GTests will need to be updated when `Metaspace::ReflectionMetaspaceType` is removed.  Such clean up can be done separately (JDK-8342561).
> 
> [1] [JDK-4486457](https://bugs.openjdk.org/browse/JDK-4486457)
> [2] [JDK-4474172](https://bugs.openjdk.org/browse/JDK-4474172)
> [3] [JDK-6790209](https://bugs.openjdk.org/browse/JDK-6790209)

This pull request has now been integrated.

Changeset: d6eddcda
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6eddcdaf92f2352266ba519608879141997cd63
Stats:     2817 lines in 28 files changed: 0 ins; 2805 del; 12 mod

8327624: Remove VM implementation that bypass verification for core reflection

Reviewed-by: liach, dholmes, jrose, alanb, mli

-------------

PR: https://git.openjdk.org/jdk/pull/21571

From dfuchs at openjdk.org  Tue Oct 22 18:26:05 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Oct 2024 18:26:05 GMT
Subject: RFR: 8342807: Update links in java.base to use https://
In-Reply-To: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
References: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
Message-ID: <LSUjvZKdRaTQGHr4zTBGQiWEmgc3sphcfoWZWSXsbUM=.a3f90c43-6a72-44cd-af65-cf5a0e7b2191@github.com>

On Tue, 22 Oct 2024 10:19:23 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http.
> 
> Links in `java.security` and `share/data/tzdata` are excluded from this PR.
> 
> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. 
> 
> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`).
> 
> Changes beyond the obvious  are as follows:
> 
> `linux/native/libsimdsort/xss-common-qsort.h`:
> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170
> 
> `share/man/keytool.1`:
> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well?
> 
> `unix/classes/sun/net/PortConfig.java`
> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports.
> 
> `unix/native/libjava/*`,
>  Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs
> 
> `unix/native/libjava/ProcessImpl_md.c`
> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to.

FWIW: I don't believe a change to a link in a comment in an internal class requires a CSR.
For PortConfig.java - it would be good to have someone involved in the AIX port comment on the proposed changes. 
Removing the obsolete link altogether is also a possibility.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2429957794

From dhanalla at openjdk.org  Tue Oct 22 18:42:13 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Tue, 22 Oct 2024 18:42:13 GMT
Subject: Withdrawn: 8337408: Use GetTempPath2 API instead of GetTempPath
In-Reply-To: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
Message-ID: <jnYtYinpbHGCOqYASitMQXUfLHwkJPMFzKFz-CCPbS4=.81adf8f3-dc79-4af8-a1e6-d41377cb8ab9@github.com>

On Thu, 15 Aug 2024 16:23:18 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
> 
> 
> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
> 
> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
> 3. Some parts of the code are written in C others in C++.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20600

From naoto at openjdk.org  Tue Oct 22 18:55:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 18:55:29 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v6]
In-Reply-To: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
Message-ID: <w4Vh3lJ2QKCEi-Y6LJTAl0mBSzYt8xchPfxbhhFKMks=.a5dccfd8-445a-47d3-be27-a5b204f414d6@github.com>

> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixed a typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21569/files
  - new: https://git.openjdk.org/jdk/pull/21569/files/c234961e..8e9f2a21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21569&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21569/head:pull/21569

PR: https://git.openjdk.org/jdk/pull/21569

From pchilanomate at openjdk.org  Tue Oct 22 19:01:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:01:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
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: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@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:

  Make lea with RIP-relative addressing more general

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/23d1a2be..81e5c6d0

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: 24 lines in 2 files changed: 7 ins; 9 del; 8 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 Oct 22 19:07:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
Message-ID: <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>

On Tue, 22 Oct 2024 13:51:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244844
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244206

From pchilanomate at openjdk.org  Tue Oct 22 19:07:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
Message-ID: <LXvYQLMhjGyozdv2SaLbBGAv7rujDnS1jd9JyvUTHBw=.8a7c1706-9df3-4d17-b6e1-a230db585669@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 pchilanomate at openjdk.org  Tue Oct 22 19:07:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
Message-ID: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@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 sspitsyn at openjdk.org  Tue Oct 22 19:08:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 22 Oct 2024 19:08:07 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v7]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <BX67eE8zK3X9gZ_tt7Okz6KH77uV6CDn9N_IjDDd5AE=.af5c0df4-a97d-48aa-b566-cafe67ae3c89@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: explain better what methods can be annotated with JvmtiMountTransition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/94862c30..d59d499e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=05-06

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From eirbjo at openjdk.org  Tue Oct 22 19:08:58 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 22 Oct 2024 19:08:58 GMT
Subject: RFR: 8342807: Update links in java.base to use https:// [v2]
In-Reply-To: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
References: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
Message-ID: <EBhwxMSUvPydH-WEdPxwd1A4vVxY1TECVhLZiJCmJJ4=.72547c6a-a2da-485f-93d8-f948c4606c8e@github.com>

> Please review this cleanup PR which updates a total of 12 links to external documentation or references in `java.base` to use https instead of plain text http.
> 
> Links in `java.security` and `share/data/tzdata` are excluded from this PR.
> 
> This is a documentaton-only cleanup. No tests are added or updated. `noreg-cleanup` added in the JBS. All updated links have been verified to resolve and to show the expected content. 
> 
> There are two files here with non-Oracle copyright headers, not quite sure how to update those? (`java_md_aix.h` and `xss-common-qsort.h`).
> 
> Changes beyond the obvious  are as follows:
> 
> `linux/native/libsimdsort/xss-common-qsort.h`:
> The current link uses a non-default port number. Changed to using the default port number. Reported upstream as intel/x86-simd-sort#170
> 
> `share/man/keytool.1`:
> www.oracle.com redirects this from `/technetwork/java/javase/javasecarootcertsprogram-1876540.html` to `/java/technologies/javase/carootcertsprogram.html`. Using the new URL here. Should this be updated in Oracle-internal sources as well?
> 
> `unix/classes/sun/net/PortConfig.java`
> The current link no longer resolves. As a replacement, I suggest https://www.ibm.com/support/pages/node/886227 which answers a support question regarding ephemeral ports.
> 
> `unix/native/libjava/*`,
>  Links redirect from "www.opengroup.org" to "pubs.opengroup.org". Using this new host in the URLs
> 
> `unix/native/libjava/ProcessImpl_md.c`
> A link to pasc.org now requires authentication. I changed this to be a Wayback link. Alternantives would be to delete this link, or to track down a revised version of the spec the linked Interpretation Request refers to.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Remove accidental "'"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21633/files
  - new: https://git.openjdk.org/jdk/pull/21633/files/0c453f51..f2580d87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21633&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21633&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21633/head:pull/21633

PR: https://git.openjdk.org/jdk/pull/21633

From eirbjo at openjdk.org  Tue Oct 22 19:16:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 22 Oct 2024 19:16:08 GMT
Subject: RFR: 8342807: Update links in java.base to use https:// [v2]
In-Reply-To: <1sfWdB4G5a6orGYEOPhPZyttTp8cQ3BAqHyEiy5ot_I=.82094810-383b-43ec-ad37-df84ba8a8412@github.com>
References: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
 <1sfWdB4G5a6orGYEOPhPZyttTp8cQ3BAqHyEiy5ot_I=.82094810-383b-43ec-ad37-df84ba8a8412@github.com>
Message-ID: <gyQaCoqVXHwf0UjwCIhpBpAEhglgalGaxMqOq0rtfCk=.2cf4791f-8039-4abe-9e33-b410ed470bdd@github.com>

On Tue, 22 Oct 2024 17:40:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove accidental "'"
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 109:
> 
>> 107:  * the jspawnhelper, then in the jspawnhelper we do the pre-exec work and exec a
>> 108:  * second time, this time the target binary (similar to the "exec-twice-technique"
>> 109:  * described in 'https://mail.openjdk.org/pipermail/core-libs-dev/2018-September/055333.html).
> 
> Unintentional `'` was added.

Thanks, good catch!

> src/java.base/unix/native/libjava/ProcessImpl_md.c line 204:
> 
>> 202:      * References:
>> 203:      * https://pubs.opengroup.org/onlinepubs/7908799/xsh/exec.html
>> 204:      * https://web.archive.org/web/20090106162458/http://www.pasc.org/interps/unofficial/db/p1003.1/pasc-1003.1-132.html
> 
> The new Wayback link does not resolve for me.

It seems the Wayback Machine is suffering a DDOS attack again..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21633#discussion_r1811254236
PR Review Comment: https://git.openjdk.org/jdk/pull/21633#discussion_r1811254815

From sspitsyn at openjdk.org  Tue Oct 22 19:16:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 22 Oct 2024 19:16:21 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v8]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <15ZEmA1D4X71LAEk66t2yPYmkdYvOI5W1ySny1-k9TI=.14eb1bd0-d75a-4a93-899c-a563a53bb058@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn 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
 - review: explain better what methods can be annotated with JvmtiMountTransition
 - review: clarify the use of annotation @JvmtiMountTransition in yield/yield0
 - review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller
 - review: tweaked disabler for carrier threads; more hiddenjvmti_mount_transition frames
 - Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
 - review: 1. Minor tweaks in new test; 2. Refactor skip_hidden_frames in two
 - fix one more place with trailing spaces
 - fix trailing spaces
 - add new test coverage with  vthread/CheckHiddenFrames
 - ... and 1 more: https://git.openjdk.org/jdk/compare/d6eddcda...54dc2b4a

-------------

Changes: https://git.openjdk.org/jdk/pull/21397/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=07
  Stats: 282 lines in 11 files changed: 236 ins; 18 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From asemenyuk at openjdk.org  Tue Oct 22 19:31:10 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Oct 2024 19:31:10 GMT
Subject: RFR: 8341939: SigningOptionsTest fails without Xcode with command
 line developer tools after JDK-8341443
In-Reply-To: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
References: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
Message-ID: <o9OoQlxcxkw1rhY7va22OI__cbuqsyc4jQoUA-7yNjA=.a43d8cfb-ef23-41a8-9fe8-81947226fc1b@github.com>

On Tue, 22 Oct 2024 01:46:45 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Removed hard check for "Xcode with command line developer tools" when `--mac-sign` is specified and instead we will show information message if `codesign` fails for any reason that possible root cause of failure is missing Xcode with command line developer tools.
> - Reason for this is that `codesign` works fine on recent macOS versions and it looks like dependency on Xcode with command line developer tools is no longer required. Unfortunately it is unknown which macOS versions are require Xcode with command line developer tools in order to `codesign` work, so this check will be done as soft check.
> - SigningOptionsTest which requires "Xcode with command line developer tools" on some older macOS versions was modified to skip certain tests which might fail if Xcode is not installed.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java line 784:

> 782:         }
> 783: 
> 784:         return false;

I'd use jpackage `Executor` class to run all external commands.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21628#discussion_r1811272622

From eirbjo at openjdk.org  Tue Oct 22 19:33:14 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 22 Oct 2024 19:33:14 GMT
Subject: RFR: 8342807: Update links in java.base to use https://
In-Reply-To: <LSUjvZKdRaTQGHr4zTBGQiWEmgc3sphcfoWZWSXsbUM=.a3f90c43-6a72-44cd-af65-cf5a0e7b2191@github.com>
References: <lIsOxkqyR-lZisq4klVPhm2os2y7Mn74PSHsrDy_NBw=.ab174a2e-9463-4b72-a0e1-7531d7a7f5c4@github.com>
 <LSUjvZKdRaTQGHr4zTBGQiWEmgc3sphcfoWZWSXsbUM=.a3f90c43-6a72-44cd-af65-cf5a0e7b2191@github.com>
Message-ID: <ujYjv4sGeiTr7U16tEdbVH-qLr6DoTRuK13Nhw6B218=.0336b47a-b833-442f-a2ff-55714e419981@github.com>

On Tue, 22 Oct 2024 18:22:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> For PortConfig.java - it would be good to have someone involved in the AIX port comment on the proposed changes. Removing the obsolete link altogether is also a possibility.

The context for the link in PortConfig.java is: 


// The ephemeral port is OS version dependent on AIX:
// http://publib.boulder.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.rsct315.admin/bl503_ephport.htm
// However, on AIX 5.3 / 6.1 / 7.1 we always see the
// settings below by using:
// /usr/sbin/no -a | fgrep ephemeral
defaultLower = 32768;
defaultUpper = 65535;


So while the FAQ link I changed this to confirms the port numbers here, it probably makes the comment "The ephemeral port is OS version dependent on AIX" somewhat stale. Seems the original linked document somehow contradicted the observed settings? So if we use my suggested FAQ link, perhaps it is better to remove the surrounding comment altogether, as it seems stale. 

For `ProcessImpl_md.c`, the obsolete link was to a request for clarification to what I think may be an early version of some POSIX standard. If I'm right, the current version is https://www.iso.org/standard/50516.html, which is not publicly available (requires paid access).

But yes, would be nice if some AIX people could have a look at this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21633#issuecomment-2430082439

From asemenyuk at openjdk.org  Tue Oct 22 19:39:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Oct 2024 19:39:06 GMT
Subject: RFR: 8341939: SigningOptionsTest fails without Xcode with command
 line developer tools after JDK-8341443
In-Reply-To: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
References: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
Message-ID: <M_hNvuRQJJ04YNbLgPCBoTORqJsWodwuejmRAHFkNTs=.671cdaeb-07a8-4033-bf7a-272010ed81ac@github.com>

On Tue, 22 Oct 2024 01:46:45 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Removed hard check for "Xcode with command line developer tools" when `--mac-sign` is specified and instead we will show information message if `codesign` fails for any reason that possible root cause of failure is missing Xcode with command line developer tools.
> - Reason for this is that `codesign` works fine on recent macOS versions and it looks like dependency on Xcode with command line developer tools is no longer required. Unfortunately it is unknown which macOS versions are require Xcode with command line developer tools in order to `codesign` work, so this check will be done as soft check.
> - SigningOptionsTest which requires "Xcode with command line developer tools" on some older macOS versions was modified to skip certain tests which might fail if Xcode is not installed.

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/macosx/base/SigningCheck.java line 104:

> 102:         } catch (IOException | InterruptedException ex) {
> 103:             throw new RuntimeException(ex);
> 104:         }

Can be reduced to:


public static void isXcodeDevToolsInstalled() {
  if (Executor.of("/usr/bin/xcrun", "--help").execute().getExitCode() != 0) {
    TKit.throwSkippedException("Missing Xcode with command line developer tools");
  }
}


Also will add a log record to help evaluate potential test failure.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21628#pullrequestreview-2386121638
PR Review Comment: https://git.openjdk.org/jdk/pull/21628#discussion_r1811280576

From darcy at openjdk.org  Tue Oct 22 20:05:57 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Oct 2024 20:05:57 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v4]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <j--kv0Vh-HsLgzmwud4OP8gwiLZe3huppthP7J5uO3U=.3071b2fe-75cb-4dd7-a879-b5b920b4af77@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:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/0328e217..3c40f7ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=02-03

  Stats: 24 lines in 1 file changed: 0 ins; 0 del; 24 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 Oct 22 20:06:00 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Oct 2024 20:06:00 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v3]
In-Reply-To: <XH7y_mjnCS_xZktPvUH_1HrS6itVKZxsklbCf0Hq3tw=.1d367e86-c1a7-4604-bb4a-64095f1cb942@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@github.com>
 <XH7y_mjnCS_xZktPvUH_1HrS6itVKZxsklbCf0Hq3tw=.1d367e86-c1a7-4604-bb4a-64095f1cb942@github.com>
Message-ID: <3nCbm52Sxt3-8k6iGWJ6YHDsVAuxG6dWXLNs9B-JUPQ=.ba1353fa-7035-4a6d-8e6b-cb534adc461c@github.com>

On Tue, 22 Oct 2024 14:18:33 GMT, Raffaello Giulietti <rgiulietti 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:
>> 
>>  - Add @since tag, respond to review feedback.
>>  - Merge branch 'master' into JDK-8341260
>>  - Remove comments for intrinsics per review feedback.
>>  - Update with changes from lworld+fp16 Float16.
>>  - Merge branch 'master' into JDK-8341260
>>  - Add support for BigDecimal -> Float16 conversion.
>>  - JDK-8341260: Add Float16 to jdk.incubator.vector
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 471:
> 
>> 469: //                     }
>> 470: //                 }
>> 471: //             }
> 
> Suggestion:
> 
>              int scale = bd.scale();
>              BigInteger unscaledValue = bd.unscaledValue();
> 
>              if (unscaledValue.abs().compareTo(BigInteger.valueOf(Long.MAX_VALUE)) <= 0) {
>                  long intCompact = unscaledValue.longValue();
>                  Float16 v = Float16.valueOf(intCompact);
>                  if (scale == 0) {
>                      return v;
>                  }
>                  /*
>                   * The discussion for the double case also applies here. That is,
>                   * the following test is precise for all long values, but here
>                   * Long.MAX_VALUE is not an issue.
>                   */
>                  if (v.longValue() == intCompact) {
>                      if (0 < scale && scale < FLOAT16_10_POW.length) {
>                          return Float16.divide(v, FLOAT16_10_POW[scale]);
>                      }
>                      if (0 > scale && scale > -FLOAT16_10_POW.length) {
>                          return Float16.multiply(v, FLOAT16_10_POW[-scale]);
>                      }
>                  }
>              }

That does the trick; thanks for tracking down the mistake.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811306593

From psandoz at openjdk.org  Tue Oct 22 20:08:11 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 22 Oct 2024 20:08:11 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v3]
In-Reply-To: <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@github.com>
Message-ID: <Tn8-zGxqi7cOw-CkGi3cfB3OMAX-coOsEKZxobz0JCw=.6e83e6f0-3956-47bf-8641-38cdfcea830e@github.com>

On Mon, 21 Oct 2024 17:07:35 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 seven additional commits since the last revision:
> 
>  - Add @since tag, respond to review feedback.
>  - Merge branch 'master' into JDK-8341260
>  - Remove comments for intrinsics per review feedback.
>  - Update with changes from lworld+fp16 Float16.
>  - Merge branch 'master' into JDK-8341260
>  - Add support for BigDecimal -> Float16 conversion.
>  - JDK-8341260: Add Float16 to jdk.incubator.vector

Looking good, although i am not expert on the floating point aspects. Some of the more substantive comments could be addressed if chosen to in subsequent PRs.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 70:

> 68: 
> 69: // Currently Float16 is a value based class but in future will be aligned with
> 70: // Enhanced Primitive Boxes described by JEP-402 (https://openjdk.org/jeps/402)

It will be aligned with JEP 401: Value Classes and Objects. `Float16` will eventually become a value class, it will not become a primitive type. JEP 402 is about treating (the existing) primitive types more like reference types. Note as per JEP 401 value class types are reference types.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 72:

> 70: // Enhanced Primitive Boxes described by JEP-402 (https://openjdk.org/jeps/402)
> 71: // @jdk.internal.MigratedValueClass
> 72: //@jdk.internal.ValueBased

We can modify the module info in `java.base` to export `jdk.internal` to `jdk.incubator.vector` then we can annotate `Float16` with `ValueBased`, and then we can get some diagnostic checking e.g., if there is an attempt to synchronize on it.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 78:

> 76:     implements Comparable<Float16> {
> 77:     private final short value;
> 78:     private static final long serialVersionUID = 16; // Not needed for a value class?

Unsure if this field needed. Perhaps a wider question to be thought and answered about later is whether we should extend from `Number`.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 89:

> 87:     * @param  bits a short value.
> 88:     */
> 89:     private Float16 (short bits ) {

Suggestion:

    private Float16(short bits) {

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 690:

> 688:     // public int hashCode()
> 689:     // public static int hashCode(Float16 value)
> 690:     // public boolean equals(Object obj)

I think we should add these methods in a subsequent PR. e.g., (although i may be ignorant of some details)

    @Override
    public int hashCode() {
        return Float16.hashCode(value);
    }

    public static int hashCode(float value) {
        return float16ToShortBits(value); 
    }

    public static int float16ToShortBits(float value) {
        if (!isNaN(value)) {
            return float16ToRawShortBits(value);
        }
        return Float16.NaN;
    }

    public boolean equals(Object obj) {
        return (obj instanceof Float16)
               && (float16ToShortBits(((Float16)obj).value) == float16ToShortBits(value));
    }

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1198:

> 1196:      *
> 1197:      * @param f16 the value to be negated
> 1198:      * @jls 15.15.4 Unary Minus Operator {@code -}

In prior binary operations it is just stated `* @jls 15.4 Floating-point Expressions` can we be consistent?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Consts.java line 92:

> 90:                 ((EXP_BIT_MASK & SIGNIF_BIT_MASK) == 0)) &&
> 91:                 ((SIGN_BIT_MASK | MAG_BIT_MASK) == 0xFFFF));
> 92:     }

Consider moving this to a test, perhaps in a subsequent PR when addressing refactoring the Float16 tests out of `BigDecimal/DoubleFloatValueTests`.

test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java line 34:

> 32: import static jdk.incubator.vector.Float16.*;
> 33: 
> 34: public class BasicFloat16ArithTests {

Consider transforming this to a junit test, using asserts, and possibly data providers in some cases, and factoring out the FMA tests into a separate class e.g., in subsequent PR. It will then be clearer on what is tested, with what data, and what is asserted on.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21574#pullrequestreview-2386086446
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811280538
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811287099
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811290960
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811291449
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811308765
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811301176
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811260726
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811267765

From iklam at openjdk.org  Tue Oct 22 20:35:38 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 20:35:38 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v2]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <F32HoOoJ-FD_jqo-HCGLm2uY19PGBlj_2IAn0uxN4Eg=.1382e2f7-2c6e-4dba-ad9c-3b114142bc44@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 157 commits:

 - @rose00 offline comments -- make sure the StringConcatFactory bsm does not use MethodTypes that refer to excluded classes
 - Added test case for using --module-path with -XX:+AOTClassLinking
 - @rose00 comment -- print size of MH intrinsics table
 - @stefank comment: include aotLinkedClassBulkLoader.hpp in iterator.inline.hpp
 - Merge branch 'master' into jep-483-candidate
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - Merge branch 'jep-483-step-03-8329706-implement-xx-aot-class-linking' of /jdk3/yak/open into jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap
 - @calvinccheung review comments
 - ... and 147 more: https://git.openjdk.org/jdk/compare/893266c4...3860dcf5

-------------

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=01
  Stats: 6929 lines in 102 files changed: 6051 ins; 560 del; 318 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 honkar at openjdk.org  Tue Oct 22 20:52:28 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 20:52:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <CkRcFjfurFSz7TjPgF5jqUyjfutH-vBHQvmHLYXNB7Y=.cd1bac46-fd00-4186-aca8-91476983b976@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

@prsadhuk Addressed review comments in the following jep486 branch commit: 
https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e

1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2430237067

From mchung at openjdk.org  Tue Oct 22 20:56:12 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Oct 2024 20:56:12 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v6]
In-Reply-To: <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>
Message-ID: <LTGqJcssvdD2558NQAENXT-K5kOmRVJgohwZCFHVUaA=.ebf3ad00-2804-4a11-936a-8113eda98b68@github.com>

On Tue, 22 Oct 2024 04:50:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Relax displayName spec

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 278:

> 276: 
> 277:     /**
> 278:      * {@return a human-readable name for this {@code ClassDesc}}

I don't see the merit of making the string representation unspecified.   The implSpec already specifies the string representation for the display name.   Why not just promoting it to normal spec text?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1811374200

From honkar at openjdk.org  Tue Oct 22 20:58:31 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 20:58:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
Message-ID: <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>

On Tue, 22 Oct 2024 08:16:38 GMT, Prasanta Sadhukhan <psadhukhan 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
> 
>> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>> 48:     }
>> 49: 
> 
> Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...

Updated

> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 48:
> 
>> 46:         test.setupUI();
>> 47:         test.testApplication();
>> 48:         test.testApplet();
> 
> I guess we can only remove this `testApplet` as SM is invoked there only....we can still test `testApplication`, right?

Updated. Repurposed the test.

> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:
> 
>> 115:             }
>> 116:             popup.setVisible(false);
>> 117:             frame.dispose();
> 
> The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..

Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811381885
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811382077
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811382336

From darcy at openjdk.org  Tue Oct 22 21:01:22 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Oct 2024 21:01:22 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v3]
In-Reply-To: <Tn8-zGxqi7cOw-CkGi3cfB3OMAX-coOsEKZxobz0JCw=.6e83e6f0-3956-47bf-8641-38cdfcea830e@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@github.com>
 <Tn8-zGxqi7cOw-CkGi3cfB3OMAX-coOsEKZxobz0JCw=.6e83e6f0-3956-47bf-8641-38cdfcea830e@github.com>
Message-ID: <c1dRFIuqSFvC9WMJLYmREl6kwTpdp9Y1eOYwED6CFmA=.9e284537-a681-4c82-9e21-613672ea6b8c@github.com>

On Tue, 22 Oct 2024 19:41:57 GMT, Paul Sandoz <psandoz 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:
>> 
>>  - Add @since tag, respond to review feedback.
>>  - Merge branch 'master' into JDK-8341260
>>  - Remove comments for intrinsics per review feedback.
>>  - Update with changes from lworld+fp16 Float16.
>>  - Merge branch 'master' into JDK-8341260
>>  - Add support for BigDecimal -> Float16 conversion.
>>  - JDK-8341260: Add Float16 to jdk.incubator.vector
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 72:
> 
>> 70: // Enhanced Primitive Boxes described by JEP-402 (https://openjdk.org/jeps/402)
>> 71: // @jdk.internal.MigratedValueClass
>> 72: //@jdk.internal.ValueBased
> 
> We can modify the module info in `java.base` to export `jdk.internal` to `jdk.incubator.vector` then we can annotate `Float16` with `ValueBased`, and then we can get some diagnostic checking e.g., if there is an attempt to synchronize on it.

Will update to refer to JEP 401.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 78:
> 
>> 76:     implements Comparable<Float16> {
>> 77:     private final short value;
>> 78:     private static final long serialVersionUID = 16; // Not needed for a value class?
> 
> Unsure if this field needed. Perhaps a wider question to be thought and answered about later is whether we should extend from `Number`.

For now, I think the svuid is fine; we can update to whatever the right answer will be under value classes at that time. Likewise, leaving the Number superclass is fine for now, but may change later.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1198:
> 
>> 1196:      *
>> 1197:      * @param f16 the value to be negated
>> 1198:      * @jls 15.15.4 Unary Minus Operator {@code -}
> 
> In prior binary operations it is just stated `* @jls 15.4 Floating-point Expressions` can we be consistent?

I'll add more precise tags as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811383428
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811388882
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811381891

From darcy at openjdk.org  Tue Oct 22 21:01:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Oct 2024 21:01:21 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v5]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <Zjyh7cf6umqlYPWnEACq0dom6JXZQX0PTQLCHqCqKsM=.db8eefe6-c6d4-4eb3-801d-959a2ed65c66@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:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/3c40f7ba..0c592776

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=03-04

  Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 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 honkar at openjdk.org  Tue Oct 22 21:04:30 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 21:04:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
Message-ID: <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>

On Tue, 22 Oct 2024 09:29:38 GMT, Prasanta Sadhukhan <psadhukhan 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
> 
>> 43:         JTable table = new JTable();
>> 44:         TableCellEditor de = table.getDefaultEditor(Double.class);
>> 45:         if (de == null) {
> 
> I guess we can test this without SM since it tests SwingLazyValue?

I believe I had removed this test because it wasn't testing anything significant. But I have re-added it please re-review and let me know if it holds value to be retained.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811400040

From jlu at openjdk.org  Tue Oct 22 21:24:05 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Oct 2024 21:24:05 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5
In-Reply-To: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
Message-ID: <MC05LCmlB4ub4bTzW1KWC0oox0kN-vqyaLNGXAT6FlM=.4a362765-7137-4bf6-9484-f101ecc92a8b@github.com>

On Tue, 22 Oct 2024 18:09:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.

Looks correct. `initDefault(Locale.Category category)` pulls the _country/variant_format/display_ values directly from `StaticProperty`, so the _user.region_ override is getting ignored if it exists because only `initDefault()` is reading it.
I think ideally the logic could stay in `Locale`, but since the fallback of _country/variant_format/display_ `StaticProperty` is based on region, it makes sense to move the logic to when the fallback is set.

test/jdk/java/util/Locale/UserRegionTest.java line 31:

> 29:  * @modules jdk.localedata
> 30:  * @run junit/othervm
> 31:  *      -Duser.region=DE_POSIX

It might be nice to check the logic for all 3 cases: `country`, `country_variant`, or` _variant`.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21645#pullrequestreview-2386404393
PR Review Comment: https://git.openjdk.org/jdk/pull/21645#discussion_r1811456591

From rriggs at openjdk.org  Tue Oct 22 21:31:05 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Oct 2024 21:31:05 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5
In-Reply-To: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
Message-ID: <DSzwrw34Vhoo6aBsRxoABGlDrb6w3cNLDEtXBg5cFp4=.66707224-e17d-406b-ae46-0b37f9a8efda@github.com>

On Tue, 22 Oct 2024 18:09:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 104:

> 102:         USER_REGION = getProperty(props, "user.region", "");
> 103:         if (!USER_REGION.isEmpty()) {
> 104:             // region can be of form country, country_variant, or _variant

typo "of form"? "region can be from"...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21645#discussion_r1811465459

From mchung at openjdk.org  Tue Oct 22 21:39:31 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Oct 2024 21:39:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.

test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java line 31:

> 29:  * @summary test that all fields returned by getDeclaredFields() can be
> 30:  *          set accessible if the right permission is granted; this test
> 31:  *          also verifies that Class.classLoader final private field is

"if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".

test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 338:

> 336: 
> 337:     public static enum TestCase {
> 338:         UNSECURE;

Better to drop this enum entirely.   Simply call `FieldSetAccessibleTest::run` as it's the only test case.

test/jdk/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java line 45:

> 43: 
> 44:     public static void main(String... args) throws Throwable {
> 45:         System.err.println("Test without security manager.");

Security manager is not relevant any more.  Suggest to drop this println.

test/jdk/java/lang/invoke/RevealDirectTest.java line 33:

> 31:  * @test
> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest

line 36 can also be removed.


* $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest

test/jdk/java/lang/invoke/callerSensitive/csm/jdk/test/MethodInvokeTest.java line 77:

> 75:             @Override
> 76:             public boolean implies(ProtectionDomain domain, Permission p) {
> 77:                 return perms.implies(p) || DEFAULT_POLICY.implies(domain, p);

static variable `DEFAULT_POLICY` (line 48) can be removed.

test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java line 83:

> 81:     }
> 82: 
> 83:     private static final String NEW_PROXY_IN_PKG = "newProxyInPackage.";

This constant is no longer needed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2383401067
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809627796
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809631220
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811445313
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811458290
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811462419
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809602637

From bpb at openjdk.org  Tue Oct 22 21:45:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 21:45:19 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v5]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <i873XNVLl7N5-C88RFZWG54aKbKt_aESzsvZk0sc9rs=.174ce148-05f2-4a13-9ce9-e7108f9fd646@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8233451: Add --enable-native-access=ALL-UNNAMED; clean up formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/ead1b59b..f4ab451b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

PR: https://git.openjdk.org/jdk/pull/21508

From bpb at openjdk.org  Tue Oct 22 21:45:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Oct 2024 21:45:20 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v4]
In-Reply-To: <zcxNbI4rEvbmjCTnFvq8J8b8RccqBD8hOovbA3-duB0=.770c4f47-a9f1-4757-be79-8c1a7f37f586@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <rlPdYrsjRAH6eAn0Qp33NFuXAQjOW9lCQ7oCQoAfvp4=.b643f421-cb91-44c3-acab-a5d976b0dc0b@github.com>
 <IA-Slxozzhw7LeW8ZC8r_zsEvosb2wAZL5DMUNYCGTo=.3496009b-be9b-4e1b-b202-bc52943e9d7d@github.com>
 <zcxNbI4rEvbmjCTnFvq8J8b8RccqBD8hOovbA3-duB0=.770c4f47-a9f1-4757-be79-8c1a7f37f586@github.com>
Message-ID: <OKVLXCNKBuI3uS3YUHPzfiTY9LxUdy-nIRrsx6RVnVE=.91c4c2b0-b274-4b03-8eb1-98b5ac14a4f5@github.com>

On Tue, 22 Oct 2024 16:22:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I assume you'll run the test many tests on all platforms to ensure its stability before integrating.

I ran the version of commit f4ab451 30 times on all platforms without failures.

>> test/jdk/java/nio/file/Files/InputStreamTest.java line 29:
>> 
>>> 27:  * @library .. /test/lib
>>> 28:  * @build jdk.test.lib.Platform
>>> 29:  * @run junit InputStreamTest
>> 
>> I think this will need --enable-native-access=ALL-UNNAMED.
>
> It works as is in the CI.

Changed in f4ab451.

>> test/jdk/java/nio/file/Files/InputStreamTest.java line 99:
>> 
>>> 97:                     try {
>>> 98:                         try (FileOutputStream fos = new FileOutputStream(PIPE);)
>>> 99:                         {
>> 
>> The formatting is a bit messed up, I think a previous iteration has a second resource that is now removed.
>
> Thanks, I'll clean it up.

Cleaned up in f4ab451.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2430365919
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1811476591
PR Review Comment: https://git.openjdk.org/jdk/pull/21508#discussion_r1811476822

From naoto at openjdk.org  Tue Oct 22 22:12:11 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 22:12:11 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5 [v2]
In-Reply-To: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
Message-ID: <I0yBSMGxBPGDVqBOfLEA9S0ejrmey2Q-h8zDSt01bfA=.59ed5bd2-d135-4ad5-be0e-d956516f3f66@github.com>

> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21645/files
  - new: https://git.openjdk.org/jdk/pull/21645/files/ca2b84ad..2e5f2e0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21645&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21645&range=00-01

  Stats: 20 lines in 1 file changed: 18 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21645/head:pull/21645

PR: https://git.openjdk.org/jdk/pull/21645

From naoto at openjdk.org  Tue Oct 22 22:12:11 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 22:12:11 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5 [v2]
In-Reply-To: <MC05LCmlB4ub4bTzW1KWC0oox0kN-vqyaLNGXAT6FlM=.4a362765-7137-4bf6-9484-f101ecc92a8b@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
 <MC05LCmlB4ub4bTzW1KWC0oox0kN-vqyaLNGXAT6FlM=.4a362765-7137-4bf6-9484-f101ecc92a8b@github.com>
Message-ID: <XxRjluoGbwJDsMvw-A3pH51j5fjOHHIJutcx-S8Mbe0=.8d9f0d8b-2f59-4884-a94f-6034ae40c572@github.com>

On Tue, 22 Oct 2024 21:21:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> I think ideally the logic could stay in `Locale`, but since the fallback of _country/variant_format/display_ `StaticProperty` is based on user.region, it makes sense to move the logic to when the fallback is set.

Since `*_DISPLAY/FORMAT` static properties need to be calculated in `StaticProperty`, the override logic has to move in there.

> test/jdk/java/util/Locale/UserRegionTest.java line 31:
> 
>> 29:  * @modules jdk.localedata
>> 30:  * @run junit/othervm
>> 31:  *      -Duser.region=DE_POSIX
> 
> It might be nice to check the logic for all 3 cases: `country`, `country_variant`, or` _variant`.

Good point. Added all three cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21645#issuecomment-2430404191
PR Review Comment: https://git.openjdk.org/jdk/pull/21645#discussion_r1811500015

From naoto at openjdk.org  Tue Oct 22 22:12:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 22:12:12 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5 [v2]
In-Reply-To: <DSzwrw34Vhoo6aBsRxoABGlDrb6w3cNLDEtXBg5cFp4=.66707224-e17d-406b-ae46-0b37f9a8efda@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
 <DSzwrw34Vhoo6aBsRxoABGlDrb6w3cNLDEtXBg5cFp4=.66707224-e17d-406b-ae46-0b37f9a8efda@github.com>
Message-ID: <dNFG0pwfy1ud08Zz17yBAEt8pouyqcVizFuQxRMjCdo=.92c6a092-9170-4675-979d-0c66e4da6cff@github.com>

On Tue, 22 Oct 2024 21:28:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 104:
> 
>> 102:         USER_REGION = getProperty(props, "user.region", "");
>> 103:         if (!USER_REGION.isEmpty()) {
>> 104:             // region can be of form country, country_variant, or _variant
> 
> typo "of form"? "region can be from"...

I am not the author of this comment, but I think they meant it, like "one of forms".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21645#discussion_r1811500994

From naoto at openjdk.org  Tue Oct 22 22:17:11 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 22:17:11 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5 [v3]
In-Reply-To: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
Message-ID: <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>

> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Corrected wrong assumption in the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21645/files
  - new: https://git.openjdk.org/jdk/pull/21645/files/2e5f2e0b..2ce3643c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21645&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21645&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21645/head:pull/21645

PR: https://git.openjdk.org/jdk/pull/21645

From almatvee at openjdk.org  Tue Oct 22 22:17:56 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 22 Oct 2024 22:17:56 GMT
Subject: RFR: 8341939: SigningOptionsTest fails without Xcode with command
 line developer tools after JDK-8341443 [v2]
In-Reply-To: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
References: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
Message-ID: <mdocTjIgnuOgWO5Vm-UhCn4jSdru4OLr9i80SUPt2tk=.6be46d7c-cc20-4740-8fd6-bc80958ce696@github.com>

> - Removed hard check for "Xcode with command line developer tools" when `--mac-sign` is specified and instead we will show information message if `codesign` fails for any reason that possible root cause of failure is missing Xcode with command line developer tools.
> - Reason for this is that `codesign` works fine on recent macOS versions and it looks like dependency on Xcode with command line developer tools is no longer required. Unfortunately it is unknown which macOS versions are require Xcode with command line developer tools in order to `codesign` work, so this check will be done as soft check.
> - SigningOptionsTest which requires "Xcode with command line developer tools" on some older macOS versions was modified to skip certain tests which might fail if Xcode is not installed.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8341939: SigningOptionsTest fails without Xcode with command line developer tools after JDK-8341443 [v2]

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21628/files
  - new: https://git.openjdk.org/jdk/pull/21628/files/97307d5c..b0b5909b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21628&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21628&range=00-01

  Stats: 20 lines in 2 files changed: 0 ins; 11 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21628/head:pull/21628

PR: https://git.openjdk.org/jdk/pull/21628

From almatvee at openjdk.org  Tue Oct 22 22:17:57 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 22 Oct 2024 22:17:57 GMT
Subject: RFR: 8341939: SigningOptionsTest fails without Xcode with command
 line developer tools after JDK-8341443 [v2]
In-Reply-To: <M_hNvuRQJJ04YNbLgPCBoTORqJsWodwuejmRAHFkNTs=.671cdaeb-07a8-4033-bf7a-272010ed81ac@github.com>
References: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
 <M_hNvuRQJJ04YNbLgPCBoTORqJsWodwuejmRAHFkNTs=.671cdaeb-07a8-4033-bf7a-272010ed81ac@github.com>
Message-ID: <Xf-S0dMq9vNMl3u0nY744kYtw4TItgvLw2JxxU5SFRE=.8fa68692-2beb-4664-af2a-830371e93629@github.com>

On Tue, 22 Oct 2024 19:35:55 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8341939: SigningOptionsTest fails without Xcode with command line developer tools after JDK-8341443 [v2]
>
> test/jdk/tools/jpackage/macosx/base/SigningCheck.java line 104:
> 
>> 102:         } catch (IOException | InterruptedException ex) {
>> 103:             throw new RuntimeException(ex);
>> 104:         }
> 
> Can be reduced to:
> 
> 
> public static void isXcodeDevToolsInstalled() {
>   if (Executor.of("/usr/bin/xcrun", "--help").execute().getExitCode() != 0) {
>     TKit.throwSkippedException("Missing Xcode with command line developer tools");
>   }
> }
> 
> 
> Also will add a log record to help evaluate potential test failure.

Fixed, but I am using `executeWithoutExitCodeCheck()` instead of  `execute()`, `execute()` throws exception if command returns non-zero value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21628#discussion_r1811505327

From almatvee at openjdk.org  Tue Oct 22 22:17:56 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 22 Oct 2024 22:17:56 GMT
Subject: RFR: 8341939: SigningOptionsTest fails without Xcode with command
 line developer tools after JDK-8341443
In-Reply-To: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
References: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
Message-ID: <qHX5aUzl0NVM-MMqvznj_T9Ih83IjElc8nC6jVUI5Sg=.f711095c-1d3e-4884-926c-dbcc64a553a6@github.com>

On Tue, 22 Oct 2024 01:46:45 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Removed hard check for "Xcode with command line developer tools" when `--mac-sign` is specified and instead we will show information message if `codesign` fails for any reason that possible root cause of failure is missing Xcode with command line developer tools.
> - Reason for this is that `codesign` works fine on recent macOS versions and it looks like dependency on Xcode with command line developer tools is no longer required. Unfortunately it is unknown which macOS versions are require Xcode with command line developer tools in order to `codesign` work, so this check will be done as soft check.
> - SigningOptionsTest which requires "Xcode with command line developer tools" on some older macOS versions was modified to skip certain tests which might fail if Xcode is not installed.

8341939: SigningOptionsTest fails without Xcode with command line developer tools after JDK-8341443 [v2]
- `Executor` will be used instead of `ProcessBuilder`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21628#issuecomment-2430414137

From asemenyuk at openjdk.org  Tue Oct 22 22:38:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 22 Oct 2024 22:38:06 GMT
Subject: RFR: 8341939: SigningOptionsTest fails without Xcode with command
 line developer tools after JDK-8341443 [v2]
In-Reply-To: <mdocTjIgnuOgWO5Vm-UhCn4jSdru4OLr9i80SUPt2tk=.6be46d7c-cc20-4740-8fd6-bc80958ce696@github.com>
References: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
 <mdocTjIgnuOgWO5Vm-UhCn4jSdru4OLr9i80SUPt2tk=.6be46d7c-cc20-4740-8fd6-bc80958ce696@github.com>
Message-ID: <TYoz_Dy9bo1kPR2xhYfDJpIOHHQaCzCXkq17w50wOeU=.786dba1a-0ba4-4f93-a50b-df1725fb33dc@github.com>

On Tue, 22 Oct 2024 22:17:56 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Removed hard check for "Xcode with command line developer tools" when `--mac-sign` is specified and instead we will show information message if `codesign` fails for any reason that possible root cause of failure is missing Xcode with command line developer tools.
>> - Reason for this is that `codesign` works fine on recent macOS versions and it looks like dependency on Xcode with command line developer tools is no longer required. Unfortunately it is unknown which macOS versions are require Xcode with command line developer tools in order to `codesign` work, so this check will be done as soft check.
>> - SigningOptionsTest which requires "Xcode with command line developer tools" on some older macOS versions was modified to skip certain tests which might fail if Xcode is not installed.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8341939: SigningOptionsTest fails without Xcode with command line developer tools after JDK-8341443 [v2]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21628#pullrequestreview-2386518121

From jlu at openjdk.org  Tue Oct 22 22:38:05 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Oct 2024 22:38:05 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5 [v3]
In-Reply-To: <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
 <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>
Message-ID: <q7Vv4iMy_m1KvEGC-57dYd9umHzXYTiDhvPxwDj658I=.cfc9ca29-626c-4143-bd0f-7c6a610acfa2@github.com>

On Tue, 22 Oct 2024 22:17:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected wrong assumption in the test

I wonder if _user.region_ can be deprecated for removal in the future. AFAICT it is not specified anywhere besides the older L10n guides. I don't know the history, but if it is a compatibility workaround from ~JDK1.1 era it seems like a reasonable candidate.

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21645#pullrequestreview-2386518067

From naoto at openjdk.org  Tue Oct 22 22:47:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 22 Oct 2024 22:47:05 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5 [v3]
In-Reply-To: <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
 <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>
Message-ID: <Z-J-94r9I9Oj6TR2lcGxXZ5JZ1YZYSAOZdIUkZfaS98=.ebdc91fc-ca2f-420b-b5b0-352149d451f4@github.com>

On Tue, 22 Oct 2024 22:17:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected wrong assumption in the test

In fact, those locale related system properties were not described anywhere before https://bugs.openjdk.org/browse/JDK-8320919, which is quite recent. I think we can deprecate `user.region` (I believe which predates `user.country` and `user.variant`), but actually I was surprised by the fact that this was reported by a customer. So we might want to keep it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21645#issuecomment-2430452740

From duke at openjdk.org  Tue Oct 22 23:01:06 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 22 Oct 2024 23:01:06 GMT
Subject: RFR: 8342206: Convenience method to check if a ClassEntry matches
 a ClassDesc [v3]
In-Reply-To: <JXcDw2p-JNjXPEjYGmWXQVCSyZFHmJhImXKwmwBAT68=.d5c8e49f-ab8c-4e5c-b13a-a4ad36be7c62@github.com>
References: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
 <JXcDw2p-JNjXPEjYGmWXQVCSyZFHmJhImXKwmwBAT68=.d5c8e49f-ab8c-4e5c-b13a-a4ad36be7c62@github.com>
Message-ID: <2XDMg4V6kyuwiIFGoWi2IOeRZigKchVVOHUxruuSu-k=.02657e84-69a3-405d-ae3d-6f03ecb1dd6b@github.com>

On Tue, 22 Oct 2024 14:43:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, to efficiently check if a `ClassEntry`, such as one from an `InvokeInstruction`, is of a particular class, we use such a pattern (as seen in JEP 486 [Appendix](https://openjdk.org/jeps/486#Appendix)):
>> 
>> inst.owner().name().equalsString("java/lang/System")
>> 
>> This pattern has a few issues:
>> 
>> 1. This is not straightforward. Users may be tempted to write
>> 
>> inst.owner().asSymbol().equals(CD_System)
>> 
>> unaware of the degraded performance from extra conversions.
>> 
>> 2. We aim to reduce the use of "internal names" with encapsulation. Direct use of `"java/lang/System"` goes against this, and we have no constants offered to reduce such error-prone use of internal name.
>> 
>> Thus, I propose a new API in `ClassEntry`:
>> 
>> boolean equalsSymbol(ClassDesc)
>> 
>> that can be used conveniently to check the identity of a class entry with a clean syntax and better performance.
>
> 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 five additional commits since the last revision:
> 
>  - Merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-equalssym
>  - Reuse cache for arrays, replace some use cases
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-equalssym
>  - 8342206: Convenience method to check if a ClassEntry matches a ClassDesc

I?think it?might be?a?good?idea to?also?have `equalsSymbol(?)`?methods for?the?other pool?entries.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21526#issuecomment-2430466270

From darcy at openjdk.org  Tue Oct 22 23:16:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Oct 2024 23:16:11 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v3]
In-Reply-To: <Tn8-zGxqi7cOw-CkGi3cfB3OMAX-coOsEKZxobz0JCw=.6e83e6f0-3956-47bf-8641-38cdfcea830e@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@github.com>
 <Tn8-zGxqi7cOw-CkGi3cfB3OMAX-coOsEKZxobz0JCw=.6e83e6f0-3956-47bf-8641-38cdfcea830e@github.com>
Message-ID: <q55p8qweinN6f6eQRArwZ3FVE600VigD91j8MPZeFcM=.56b99e4a-e36a-4724-a86a-909205e74014@github.com>

On Tue, 22 Oct 2024 20:01:45 GMT, Paul Sandoz <psandoz 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:
>> 
>>  - Add @since tag, respond to review feedback.
>>  - Merge branch 'master' into JDK-8341260
>>  - Remove comments for intrinsics per review feedback.
>>  - Update with changes from lworld+fp16 Float16.
>>  - Merge branch 'master' into JDK-8341260
>>  - Add support for BigDecimal -> Float16 conversion.
>>  - JDK-8341260: Add Float16 to jdk.incubator.vector
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 690:
> 
>> 688:     // public int hashCode()
>> 689:     // public static int hashCode(Float16 value)
>> 690:     // public boolean equals(Object obj)
> 
> I think we should add these methods in a subsequent PR. e.g., (although i may be ignorant of some details)
> 
>     @Override
>     public int hashCode() {
>         return Float16.hashCode(value);
>     }
> 
>     public static int hashCode(float value) {
>         return float16ToShortBits(value); 
>     }
> 
>     public static int float16ToShortBits(float value) {
>         if (!isNaN(value)) {
>             return float16ToRawShortBits(value);
>         }
>         return Float16.NaN;
>     }
> 
>     public boolean equals(Object obj) {
>         return (obj instanceof Float16)
>                && (float16ToShortBits(((Float16)obj).value) == float16ToShortBits(value));
>     }

Hmm. Yes, adding at least explicit hashCode/equals methods from Object is reasonable. Back when the type was in the Valhalla repo, I wasn't sure what the recommended practice regarding Object methods vis a vis JEP 401/402.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811550800

From liach at openjdk.org  Tue Oct 22 23:23:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 23:23:04 GMT
Subject: RFR: 8342206: Convenience method to check if a ClassEntry matches
 a ClassDesc [v3]
In-Reply-To: <2XDMg4V6kyuwiIFGoWi2IOeRZigKchVVOHUxruuSu-k=.02657e84-69a3-405d-ae3d-6f03ecb1dd6b@github.com>
References: <NzCZhIoiJ9ozbmGf0aUMw5bwJ_lPIb-HZqq-d5Ifc1w=.4263b81b-8724-42b5-9617-ded8ce79db33@github.com>
 <JXcDw2p-JNjXPEjYGmWXQVCSyZFHmJhImXKwmwBAT68=.d5c8e49f-ab8c-4e5c-b13a-a4ad36be7c62@github.com>
 <2XDMg4V6kyuwiIFGoWi2IOeRZigKchVVOHUxruuSu-k=.02657e84-69a3-405d-ae3d-6f03ecb1dd6b@github.com>
Message-ID: <5TONRCVzSsrlE8XvB8oZEph0NTaFtKLMomlRWtDx4Us=.8a5f417c-f4c6-449d-bf60-3a4208fbd011@github.com>

On Tue, 22 Oct 2024 22:58:10 GMT, ExE Boss <duke at openjdk.org> wrote:

> I?think it?might be?a?good?idea to?also?have `equalsSymbol(?)`?methods for?the?other pool?entries.

Indeed, this can avoid promotion to String state for all applicable symbols. I decide to start with the ClassEntry as this is the most error-prone and worth optimization. (Feel free to submit a ticket through bugs.java.com)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21526#issuecomment-2430493219

From liach at openjdk.org  Tue Oct 22 23:32:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 23:32:07 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v6]
In-Reply-To: <LTGqJcssvdD2558NQAENXT-K5kOmRVJgohwZCFHVUaA=.ebf3ad00-2804-4a11-936a-8113eda98b68@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>
 <LTGqJcssvdD2558NQAENXT-K5kOmRVJgohwZCFHVUaA=.ebf3ad00-2804-4a11-936a-8113eda98b68@github.com>
Message-ID: <gG2_B8dF5cGGu4wua4BM8y9Lc1m05c3_EBNLAHKyeo4=.7657a7f2-596f-49b2-a4ca-3a3c8fbfce2e@github.com>

On Tue, 22 Oct 2024 20:53:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Relax displayName spec
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 278:
> 
>> 276: 
>> 277:     /**
>> 278:      * {@return a human-readable name for this {@code ClassDesc}}
> 
> I don't see the merit of making the string representation unspecified.   The implSpec already specifies the string representation for the display name.   Why not just promoting it to normal spec text?

I believe the specification for class or interface display name is too tight: if we have `java.awt.List` versus `java.util.List`, our current implementation prints `List` for both cases. It makes sense for an implementation to print something like `j.a.List` versus `j.u.List`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1811560821

From liach at openjdk.org  Tue Oct 22 23:37:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 23:37:10 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v2]
In-Reply-To: <F32HoOoJ-FD_jqo-HCGLm2uY19PGBlj_2IAn0uxN4Eg=.1382e2f7-2c6e-4dba-ad9c-3b114142bc44@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <F32HoOoJ-FD_jqo-HCGLm2uY19PGBlj_2IAn0uxN4Eg=.1382e2f7-2c6e-4dba-ad9c-3b114142bc44@github.com>
Message-ID: <GUv4VHuVpvx73tYpt363tKmnoEdt1DOhlG54ccEzEBA=.e594738e-0f26-430d-b87a-f30e4c446b2d@github.com>

On Tue, 22 Oct 2024 20:35:38 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 157 commits:
> 
>  - @rose00 offline comments -- make sure the StringConcatFactory bsm does not use MethodTypes that refer to excluded classes
>  - Added test case for using --module-path with -XX:+AOTClassLinking
>  - @rose00 comment -- print size of MH intrinsics table
>  - @stefank comment: include aotLinkedClassBulkLoader.hpp in iterator.inline.hpp
>  - Merge branch 'master' into jep-483-candidate
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - Merge branch 'jep-483-step-03-8329706-implement-xx-aot-class-linking' of /jdk3/yak/open into jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap
>  - @calvinccheung review comments
>  - ... and 147 more: https://git.openjdk.org/jdk/compare/893266c4...3860dcf5

The java file changes look good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2386587967

From darcy at openjdk.org  Tue Oct 22 23:47:33 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Oct 2024 23:47:33 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@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:

  Add equals/hashCode implementation; tests to follow.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/0c592776..be72e76e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=04-05

  Stats: 54 lines in 1 file changed: 50 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 mchung at openjdk.org  Tue Oct 22 23:51:12 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Oct 2024 23:51:12 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v6]
In-Reply-To: <gG2_B8dF5cGGu4wua4BM8y9Lc1m05c3_EBNLAHKyeo4=.7657a7f2-596f-49b2-a4ca-3a3c8fbfce2e@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>
 <LTGqJcssvdD2558NQAENXT-K5kOmRVJgohwZCFHVUaA=.ebf3ad00-2804-4a11-936a-8113eda98b68@github.com>
 <gG2_B8dF5cGGu4wua4BM8y9Lc1m05c3_EBNLAHKyeo4=.7657a7f2-596f-49b2-a4ca-3a3c8fbfce2e@github.com>
Message-ID: <WNBz-lTUzDRS-dumPb5bZTvH8ICjika6BbOvY_rVcZk=.6c05b7df-b50d-4da7-8c05-5f3a67a726bd@github.com>

On Tue, 22 Oct 2024 23:29:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 278:
>> 
>>> 276: 
>>> 277:     /**
>>> 278:      * {@return a human-readable name for this {@code ClassDesc}}
>> 
>> I don't see the merit of making the string representation unspecified.   The implSpec already specifies the string representation for the display name.   Why not just promoting it to normal spec text?
>
> I believe the specification for class or interface display name is too tight: if we have `java.awt.List` versus `java.util.List`, our current implementation prints `List` for both cases. It makes sense for an implementation to print something like `j.a.List` versus `j.u.List`.

Returning the fully-qualified class name could also be an option.   Since the implementation is not changed, I would suggest promoting the implSpec text to normal spec text.   For a proposal to change the specification as well as the implementation to return something different with incompatibility, it'd good to do it as a separate RFE and discuss what was considered when the implSpec was decided to print the unqualified class name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1811573420

From coleenp at openjdk.org  Wed Oct 23 00:02:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 00:02:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
Message-ID: <i_kRTAV64HcQosNOwa19e2Ezu5advIOT9r6KQ9lfRnA=.f2194af6-509c-4cdf-8f29-0b78071114a0@github.com>

On Tue, 22 Oct 2024 19:01:02 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:
> 
>   Make lea with RIP-relative addressing more general

> 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2430528701

From bpb at openjdk.org  Wed Oct 23 00:09:25 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Oct 2024 00:09:25 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v6]
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8233451: Added test of readNBytes(int)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21508/files
  - new: https://git.openjdk.org/jdk/pull/21508/files/f4ab451b..2876d9fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21508&range=04-05

  Stats: 21 lines in 1 file changed: 19 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21508/head:pull/21508

PR: https://git.openjdk.org/jdk/pull/21508

From darcy at openjdk.org  Wed Oct 23 00:25:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 00:25:07 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v3]
In-Reply-To: <q55p8qweinN6f6eQRArwZ3FVE600VigD91j8MPZeFcM=.56b99e4a-e36a-4724-a86a-909205e74014@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <gi5_nuw19ylbVVFISvhwLqrDskkY647U9zFu6_SMkeg=.456c955b-e748-4cec-bd69-33f65a09556b@github.com>
 <Tn8-zGxqi7cOw-CkGi3cfB3OMAX-coOsEKZxobz0JCw=.6e83e6f0-3956-47bf-8641-38cdfcea830e@github.com>
 <q55p8qweinN6f6eQRArwZ3FVE600VigD91j8MPZeFcM=.56b99e4a-e36a-4724-a86a-909205e74014@github.com>
Message-ID: <RhRpd9tmi4NQ0vhp2HnwIxiAxDsabQH8FzNEg8ZoJa0=.9420d80a-4cd4-482b-926c-09d0343a3185@github.com>

On Tue, 22 Oct 2024 23:13:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 690:
>> 
>>> 688:     // public int hashCode()
>>> 689:     // public static int hashCode(Float16 value)
>>> 690:     // public boolean equals(Object obj)
>> 
>> I think we should add these methods in a subsequent PR. e.g., (although i may be ignorant of some details)
>> 
>>     @Override
>>     public int hashCode() {
>>         return Float16.hashCode(value);
>>     }
>> 
>>     public static int hashCode(float value) {
>>         return float16ToShortBits(value); 
>>     }
>> 
>>     public static int float16ToShortBits(float value) {
>>         if (!isNaN(value)) {
>>             return float16ToRawShortBits(value);
>>         }
>>         return Float16.NaN;
>>     }
>> 
>>     public boolean equals(Object obj) {
>>         return (obj instanceof Float16)
>>                && (float16ToShortBits(((Float16)obj).value) == float16ToShortBits(value));
>>     }
>
> Hmm. Yes, adding at least explicit hashCode/equals methods from Object is reasonable. Back when the type was in the Valhalla repo, I wasn't sure what the recommended practice regarding Object methods vis a vis JEP 401/402.

Pushed equals/hashCode implementations. One slightly subtle point: the bit pattern for the "canonical" NaN is not defined. At runtime, the bit pattern of Float16.NaN is used for that purpose. Also, the exact bits returned for hashing is not defined, although I think it would be reasonable to add a requirement that "all distinct Float16 values have distinct hash codes."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811592134

From pchilanomate at openjdk.org  Wed Oct 23 00:35:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:35:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
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: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@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:

  Address David's comments to ObjectMonitor.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/81e5c6d0..b6bc98e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=03-04

  Stats: 147 lines in 11 files changed: 10 ins; 7 del; 130 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 Oct 23 00:35:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:35:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <ERnhebjKvn3xuNnBLCTfZXgc4ak-2z3Cpl5l5y8K3js=.031eb960-544a-4149-b930-aa37b31b0219@github.com>

On Tue, 22 Oct 2024 06:27:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596618
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596855

From pchilanomate at openjdk.org  Wed Oct 23 00:41:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:41:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>

On Tue, 22 Oct 2024 06:31:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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 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 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 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600012
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600739
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_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

From liach at openjdk.org  Wed Oct 23 01:12:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 01:12:09 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]
In-Reply-To: <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
Message-ID: <-YmH55zDMO2AcS9t0Z5lqxFgkvtrdeiefUri-x369CI=.d07ef844-07f2-4894-8864-c553b0da6c8c@github.com>

On Tue, 22 Oct 2024 23:47:33 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:
> 
>   Add equals/hashCode implementation; tests to follow.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 60:

> 58:  * either {@link Float}/{@link Double} or {@link Math}/{@link
> 59:  * StrictMath}. Unless otherwise specified, the handling of special
> 60:  * floating-point values such as {@linkplain #isNaN(Float16) NaN}

That said, and given Float has "equivalenceRelation" and "decimalToBinaryConversion" anchors, do we need similar anchors here that redirects to the Double ones?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 90:

> 88:     * @param  bits a short value.
> 89:     */
> 90:     private Float16(short bits ) {

Suggestion:

    private Float16(short bits) {

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 405:

> 403:      * @return the {@code Float16} value represented by the string
> 404:      *         argument.
> 405:      * @throws NullPointerException  if the string is null

Should we move this NPE clause to the class specification, i.e. `Unless otherwise specified, all methods in this class throw {@code NullPointerException} when passed a {@code null}`? I think this applies to the APIs taking `BigDecimal` and static methods taking `Float16`. (Note we need to explicitly exclude `equals`)

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 865:

> 863:     public static Float16 min(Float16 a, Float16 b) {
> 864:         return shortBitsToFloat16(floatToFloat16(Math.min(a.floatValue(),
> 865:                                                           b.floatValue()) ));

I assume we will optimize these min/max implementations in the future. Otherwise, the extra space should be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811609773
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811611334
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811614031
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811615209

From liach at openjdk.org  Wed Oct 23 01:17:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 01:17:12 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v6]
In-Reply-To: <WNBz-lTUzDRS-dumPb5bZTvH8ICjika6BbOvY_rVcZk=.6c05b7df-b50d-4da7-8c05-5f3a67a726bd@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>
 <LTGqJcssvdD2558NQAENXT-K5kOmRVJgohwZCFHVUaA=.ebf3ad00-2804-4a11-936a-8113eda98b68@github.com>
 <gG2_B8dF5cGGu4wua4BM8y9Lc1m05c3_EBNLAHKyeo4=.7657a7f2-596f-49b2-a4ca-3a3c8fbfce2e@github.com>
 <WNBz-lTUzDRS-dumPb5bZTvH8ICjika6BbOvY_rVcZk=.6c05b7df-b50d-4da7-8c05-5f3a67a726bd@github.com>
Message-ID: <Nhjb_aqLobgSrJtMXeFamHwLKMdb8VLTsrKLo_CpOgc=.a82c44d3-a439-40b1-99bf-b5368f408ab3@github.com>

On Tue, 22 Oct 2024 23:48:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I believe the specification for class or interface display name is too tight: if we have `java.awt.List` versus `java.util.List`, our current implementation prints `List` for both cases. It makes sense for an implementation to print something like `j.a.List` versus `j.u.List`.
>
> Returning the fully-qualified class name could also be an option.   Since the implementation is not changed, I would suggest promoting the implSpec text to normal spec text.   For a proposal to change the specification as well as the implementation to return something different with incompatibility, it'd be good to do it as a separate RFE and discuss what was considered when the implSpec was decided to print the unqualified class name.

I have promoted the implementation specification to API specification, describing that we will investigate in another RFE. Please review the latest revision and the CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1811620985

From coleenp at openjdk.org  Wed Oct 23 01:22:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
Message-ID: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.784030c7-ecc1-4b8f-ae85-cbd2e68304b0@github.com>

On Tue, 22 Oct 2024 19:01:02 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:
> 
>   Make lea with RIP-relative addressing more general

I've done a first pass over the first commit and have some comments and questions.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2386614214

From coleenp at openjdk.org  Wed Oct 23 01:22:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>
Message-ID: <vc7yb0rPrCsvTFxlSjVuCowEFqyXNl89l6Ls2eVYS4g=.beb72a45-9822-41cd-8b96-ed74a2472532@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 coleenp at openjdk.org  Wed Oct 23 01:22:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
Message-ID: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>

On Tue, 22 Oct 2024 15:49:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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 coleenp at openjdk.org  Wed Oct 23 01:22:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>

On Wed, 23 Oct 2024 00:35:06 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:
> 
>   Address David's comments to ObjectMonitor.hpp

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/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 ?

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/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/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 1014:

> 1012:   assert_mark_word_consistency();
> 1013:   UnlinkAfterAcquire(current, currentNode);
> 1014:   if (is_succesor(current)) clear_succesor();

successor has two 's'.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811590155
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_r1811611376
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811613400
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811614453

From coleenp at openjdk.org  Wed Oct 23 01:22:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
Message-ID: <eXYawRQQVqA8NLFgpPr-H1F1oLdu1Ka-Yk4npkyi298=.8acffd05-cd72-4377-8732-2e453e3181c7@github.com>

On Wed, 23 Oct 2024 00:37:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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_r1811616558

From jiangli at openjdk.org  Wed Oct 23 01:44:08 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Oct 2024 01:44:08 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <HqG0Q7lavlhlPNp6BJKIori-X7CHK7hfbZ5TPyMCsa0=.b19903ef-b490-4909-8142-37da8d5b9ffc@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <HqG0Q7lavlhlPNp6BJKIori-X7CHK7hfbZ5TPyMCsa0=.b19903ef-b490-4909-8142-37da8d5b9ffc@github.com>
Message-ID: <N2aJZCe4omsgw1E7s46gAKTEJ_h5xUKeOVxYrkf4EFA=.2b9e15c2-4154-48ca-a75d-4fa04323a710@github.com>

On Mon, 21 Oct 2024 13:17:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.
> 
> I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.
> 
> @jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.

@magicus I just noticed your above notes now (I'm been chasing an unrelated long G1 Evacuation Pause issue). I'll test your changes tomorrow. Will update you in the thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2430624032

From darcy at openjdk.org  Wed Oct 23 02:10:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 02:10:46 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals methods of
 wrapper classes
Message-ID: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>

Noticed this refactoring opportunity while doing some other work in the area.

-------------

Commit messages:
 - JDK-8342863: Use pattern matching for instanceof in equals methods of wrapper classes

Changes: https://git.openjdk.org/jdk/pull/21652/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21652&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342863
  Stats: 17 lines in 8 files changed: 0 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21652/head:pull/21652

PR: https://git.openjdk.org/jdk/pull/21652

From liach at openjdk.org  Wed Oct 23 02:17:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 02:17:07 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
Message-ID: <NAXG_BI1NeWRx1ZO5eqGMFNjDXeLT2Uz_pijXMKPpPA=.60ffd425-aae2-42c6-b42f-79696befbd12@github.com>

On Wed, 23 Oct 2024 02:06:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Noticed this refactoring opportunity while doing some other work in the area.

src/java.base/share/classes/java/lang/Long.java line 1249:

> 1247:     public boolean equals(Object obj) {
> 1248:         if (obj instanceof Long ell) {
> 1249:             return value == ell.longValue();

Suggestion:

        if (obj instanceof Long l) {
            return value == l.longValue();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21652#discussion_r1811668798

From psadhukhan at openjdk.org  Wed Oct 23 03:10:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:10:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
Message-ID: <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>

On Tue, 22 Oct 2024 16:44:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.
>
> Agreed. This is not a "clean up / update tests" task.
> If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
> Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.

I know this is not relevant to SM and would not have pointed it out had it not been modified in the PR..
In some tests as I am going to point out below, the order is changed intentionally even though it does not have anything to do with SM, all I am asking it to restore it back in those tests (and since it will look odd to have different order in different tests, I generalize it all for all javax_swing tests in this PR which is what I reviewed)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811704257

From psadhukhan at openjdk.org  Wed Oct 23 03:10:32 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:10:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <BhXyfrLOvAdzoIDfhbCHSeahv9kA7Yt6g9bTufm394k=.cb3057f8-aeef-42cf-8a23-71602c0531cb@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 36:

> 34: import javax.swing.SwingUtilities;
> 35: 
> 36: /*

this here the order is changed...

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 24:

> 22:  */
> 23: 
> 24: /**

again here the import and tag order is changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811705627
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811706135

From liach at openjdk.org  Wed Oct 23 03:11:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 03:11:48 GMT
Subject: RFR: 8342865: Use type parameter for Class::getPrimitiveClass
Message-ID: <ZFNgOt0pnCOr-DkBOH56m8Aq5gaotUEpKnaXW7xAAqk=.cbe53786-955e-4f17-90ed-3204d03704a0@github.com>

Discovered this small cleanup while looking at wrapper class code.

-------------

Commit messages:
 - 8342865: Use type parameter for Class::getPrimitiveClass

Changes: https://git.openjdk.org/jdk/pull/21653/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342865
  Stats: 20 lines in 10 files changed: 0 ins; 9 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21653/head:pull/21653

PR: https://git.openjdk.org/jdk/pull/21653

From psadhukhan at openjdk.org  Wed Oct 23 03:19:28 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:19:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
Message-ID: <hBSgrNiQ1XrBiepIl60-kesAatcE7Flw6_cRwQRDIpA=.846ab6c0-0855-4f0d-a9d8-91831587dfae@github.com>

On Tue, 22 Oct 2024 16:46:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Not specific to JEP 486, this should be done as part of a different issue.
>
> agreed

there were many tests modified in javax_swing in this PR where the author tag is removed, only this is missed so I pointed it out...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811724308

From mchung at openjdk.org  Wed Oct 23 04:12:07 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 23 Oct 2024 04:12:07 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v6]
In-Reply-To: <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>
Message-ID: <iyTP-ulJpApM1Iw8F8CdVqMFVLQZjDB4yXwimbnHWfs=.3e65c912-2b70-41b6-8a32-280b4693be1c@github.com>

On Tue, 22 Oct 2024 04:50:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Relax displayName spec

src/java.base/share/classes/java/lang/constant/ClassDesc.java line 278:

> 276: 
> 277:     /**
> 278:      * {@return a human-readable name for this {@code ClassDesc}}

Suggestion:

     * {@return a human-readable name for this {@code ClassDesc}}
     * For primitive types, this method returns the simple name (for example {@code int}).
     * For class or interface types, this method returns the unqualified class name.
     * For array types, this method returns the human-readable name of the component 
     * type suffixed with the appropriate number of {@code []} pairs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1811799147

From liach at openjdk.org  Wed Oct 23 04:20:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 04:20:49 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v7]
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <HHOEp_36jtfEmQiBX3Dr7Oz_XaHKZx_asr_0SUcrxw8=.0ab1766e-3c18-4b21-8605-0d76ed05cba7@github.com>

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Restore the impl spec to the API spec
 - Relax displayName spec
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Merge
 - object array desc constant
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - Mandy reviews
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
 - mlchung suggestions: elementType, improve utility methods
 - ... and 9 more: https://git.openjdk.org/jdk/compare/d6eddcda...bf9ff94c

-------------

Changes: https://git.openjdk.org/jdk/pull/20665/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=06
  Stats: 838 lines in 19 files changed: 445 ins; 255 del; 138 mod
  Patch: https://git.openjdk.org/jdk/pull/20665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20665/head:pull/20665

PR: https://git.openjdk.org/jdk/pull/20665

From liach at openjdk.org  Wed Oct 23 04:20:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 04:20:49 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v6]
In-Reply-To: <iyTP-ulJpApM1Iw8F8CdVqMFVLQZjDB4yXwimbnHWfs=.3e65c912-2b70-41b6-8a32-280b4693be1c@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <Y-y9-h8PYj80Igrdy71DAireAlYCrfYhsYsOnliUugc=.5494d555-06ed-48c9-baf4-86884ad11df9@github.com>
 <iyTP-ulJpApM1Iw8F8CdVqMFVLQZjDB4yXwimbnHWfs=.3e65c912-2b70-41b6-8a32-280b4693be1c@github.com>
Message-ID: <9vEf2JfZExyPSU_CSSSAzhqe4GrJklogddVII6C9EIs=.6eba9784-80af-4773-b1fb-72f6e6eadd36@github.com>

On Wed, 23 Oct 2024 04:09:37 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Relax displayName spec
>
> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 278:
> 
>> 276: 
>> 277:     /**
>> 278:      * {@return a human-readable name for this {@code ClassDesc}}
> 
> Suggestion:
> 
>      * {@return a human-readable name for this {@code ClassDesc}}
>      * For primitive types, this method returns the simple name (for example {@code int}).
>      * For class or interface types, this method returns the unqualified class name.
>      * For array types, this method returns the human-readable name of the component 
>      * type suffixed with the appropriate number of {@code []} pairs.

Oops Mandy, just noticed that I forgot to push my latest commit. Pushed and I hope you can re-review.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1811803700

From liach at openjdk.org  Wed Oct 23 04:27:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 04:27:06 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v7]
In-Reply-To: <D2vdYEM8PocZDY5vUsxrB6T_E7xc5tgmN0nSIZ-eJm4=.624522cc-599b-49ad-b9d9-a77c4a1547e7@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <mFWB4NbqeDN7VsWr2pFMq3mYlx-Pm1Hjh7OkLLkugJg=.a0597e0b-c55c-414a-a429-7da7866ee62e@github.com>
 <gnGD55EqH3a5xpN5TPdf1zfMLg7VDUxMu-iglw0NMBU=.8ef4b834-562d-45ee-86e4-9f34da999a12@github.com>
 <IQcb7ziiEnShoto3oMu1WjHcDUDPuMQ5_lM3VODIi9o=.9f762441-e078-410e-bb1a-95260af63de0@github.com>
 <D2vdYEM8PocZDY5vUsxrB6T_E7xc5tgmN0nSIZ-eJm4=.624522cc-599b-49ad-b9d9-a77c4a1547e7@github.com>
Message-ID: <Ma8VwgLNbFWMnmmTznQSPDHrxla_1AH6XWpOj5CMY6U=.abaaeeef-41c7-4d2b-bc37-8d6ee945a516@github.com>

On Tue, 8 Oct 2024 01:24:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> That said, can you leave a quick review on CSR https://bugs.openjdk.org/browse/JDK-8340963 too?
>
> I think I will do this in another patch that adds it to `ConstantDescs` - there's a place in `ConstantDescs` that could have used it, but if I put it in `ConstantUtils` I fear we are at risk of circular initialization dependencies.

Done in 28e8f2917c8ce7c85f6850a78d8f8b865a3a3793 - added to `ConstantUtils`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20665#discussion_r1811808531

From jwaters at openjdk.org  Wed Oct 23 04:45:42 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Oct 2024 04:45:42 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after 8339120
 in core libs
Message-ID: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@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

-------------

Commit messages:
 - 8342868

Changes: https://git.openjdk.org/jdk/pull/21654/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21654&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342868
  Stats: 11 lines in 4 files changed: 6 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21654.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21654/head:pull/21654

PR: https://git.openjdk.org/jdk/pull/21654

From iklam at openjdk.org  Wed Oct 23 04:46:51 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 23 Oct 2024 04:46:51 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v3]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <aEW1gzlt54nr-O9B236ddY5FzO8X1JUr0IjIKGqgOuU=.729b1434-35ac-4427-8648-bf7a520fd487@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 three additional commits since the last revision:

 - fixed test failure with "jtreg -Dtest.dynamic.cds.archive=true ..."
 - simplified the archiving of cpCache::resolved_references() -- we rely on AOTConstantPoolResolver::is_indy_resolution_deterministic() to do the filtering before indys are linked; there is no need to try to undo the resolved_references afterwards
 - Fixed bug where the BSM oops for resolved indies are not archived

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21642/files
  - new: https://git.openjdk.org/jdk/pull/21642/files/3860dcf5..1b6c3e28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=01-02

  Stats: 78 lines in 5 files changed: 28 ins; 39 del; 11 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 jwaters at openjdk.org  Wed Oct 23 05:12:43 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Oct 2024 05:12:43 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after 8339120
 in awt
Message-ID: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@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

-------------

Commit messages:
 - 8342869

Changes: https://git.openjdk.org/jdk/pull/21655/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21655&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342869
  Stats: 19 lines in 8 files changed: 5 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21655/head:pull/21655

PR: https://git.openjdk.org/jdk/pull/21655

From jwaters at openjdk.org  Wed Oct 23 05:12:43 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Oct 2024 05:12:43 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: <IjtVUCMSg55gDqZhTmOpUY_B9-kp0LyaWk8YboyGI7c=.8d604f0a-04ce-485d-8786-5de879a06fe8@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

src/java.desktop/share/native/common/awt/debug/debug_trace.h line 66:

> 64: /* each file includes this flag indicating module trace status */
> 65: #ifdef __cplusplus
> 66: [[maybe_unused]]

I don't really know what to do about this one. The solution is messy, but it's the only one I could come up with. A static global in a header is just begging for an unused-variable error to happen

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21655#discussion_r1811859559

From psadhukhan at openjdk.org  Wed Oct 23 05:14:36 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 05:14:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
> 
>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
> 
>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
> 
>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
> 
>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
> 
> 
> Left out comments that fall into out-of-scope/clean-up for jep486.

looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2430919687

From dholmes at openjdk.org  Wed Oct 23 05:21:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 05:21:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
Message-ID: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@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 jwaters at openjdk.org  Wed Oct 23 05:26:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Oct 2024 05:26:05 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
Message-ID: <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>

On Tue, 22 Oct 2024 18:03:12 GMT, Chris Plummer <cjplummer 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
>
> src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 47:
> 
>> 45: {
>> 46:     void *mappedMemory;
>> 47:  // HANDLE memHandle;
> 
> Why comment out this one but not the one at line 88? It seems they are both equally problematic and are hiding the static memHandle. I'm not sure why the 2nd one isn't flagged. I'd actually suggest getting rid of the static memHandle. It does not seem to be needed.

I wasn't sure whether the global memHandle not being used was a bug, so I commented out the local one. I missed the line 88 one because it wasn't flagged. If it really isn't needed I'll remove that one instead

> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 53:
> 
>> 51: #ifndef _WIN32
>> 52: static MUTEX_T my_mutex = MUTEX_INIT;
>> 53: #endif
> 
> The reason for no reference on windows is because of the following on windows:
> 
> 
> #define MUTEX_LOCK(x)           /* FIXUP? */
> #define MUTEX_UNLOCK(x)         /* FIXUP? */
> 
> 
> So looks like this mutex support is something we never got around to. I think your current workaround is fine.

I'm curious now, how to implement mutex support on Windows? I think I prefer that to just making it completely unavailable on Windows

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1811884490
PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1811885815

From aboldtch at openjdk.org  Wed Oct 23 05:38:11 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 23 Oct 2024 05:38:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
 <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
Message-ID: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@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 forax at openjdk.org  Wed Oct 23 05:48:04 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 23 Oct 2024 05:48:04 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
Message-ID: <rK9UXp5kMwblo1tpxpBQliPOipXXlIUo5WQaGywY4QQ=.54a3b925-9850-4364-8bf8-1efddab1583b@github.com>

On Wed, 23 Oct 2024 02:06:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Noticed this refactoring opportunity while doing some other work in the area.

src/java.base/share/classes/java/lang/Boolean.java line 259:

> 257:     public boolean equals(Object obj) {
> 258:         if (obj instanceof Boolean b) {
> 259:             return value == b.booleanValue();

I would go even a step further and use `value` instead of `booleanValue()`, `intValue()` etc because there is no need to call a method to get the value.


  if (obj instanceof Boolean b) {
            return value == b.value;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21652#discussion_r1811914553

From dholmes at openjdk.org  Wed Oct 23 05:52:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 05:52:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>

On Wed, 23 Oct 2024 00:35:06 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:
> 
>   Address David's comments to ObjectMonitor.hpp

Thanks for those updates.

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:   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 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.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2387241944
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811912133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811913172
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811914377

From aboldtch at openjdk.org  Wed Oct 23 05:59:09 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 23 Oct 2024 05:59:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
Message-ID: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@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 dholmes at openjdk.org  Wed Oct 23 06:10:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:10:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
Message-ID: <7tG1N819A95VfA37K3PK5PejcHkaBPHzWdO6wGA06w0=.10223953-863f-4ca6-ae1b-085112085c3d@github.com>

On Wed, 23 Oct 2024 00:35:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811933408
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811935087

From dholmes at openjdk.org  Wed Oct 23 06:14:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:14:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
Message-ID: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@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` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811937674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811938604

From liach at openjdk.org  Wed Oct 23 06:14:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 06:14:53 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v7]
In-Reply-To: <HHOEp_36jtfEmQiBX3Dr7Oz_XaHKZx_asr_0SUcrxw8=.0ab1766e-3c18-4b21-8605-0d76ed05cba7@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <HHOEp_36jtfEmQiBX3Dr7Oz_XaHKZx_asr_0SUcrxw8=.0ab1766e-3c18-4b21-8605-0d76ed05cba7@github.com>
Message-ID: <4HCr4YFuhHVHEooSXwc0-2haLxCr1SU697BqJjjHZfs=.dd87bd3c-0022-4dc0-8d92-9a58be8785f3@github.com>

On Wed, 23 Oct 2024 04:20:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Restore the impl spec to the API spec
>  - Relax displayName spec
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Merge
>  - object array desc constant
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - Mandy reviews
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/array-cd
>  - mlchung suggestions: elementType, improve utility methods
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/d6eddcda...bf9ff94c

Just noticed that the `ArrayClassDesc::displayName` was buggy - existing tests had no coverage and I have added test coverage for `displayName` and a few other missed methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20665#issuecomment-2430998033

From liach at openjdk.org  Wed Oct 23 06:14:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 06:14:52 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v8]
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix displayName
  
  Turns out ArrayClassDesc::displayName was incorrect. Added a test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20665/files
  - new: https://git.openjdk.org/jdk/pull/20665/files/bf9ff94c..f6bfa12c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20665&range=06-07

  Stats: 40 lines in 3 files changed: 31 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20665.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20665/head:pull/20665

PR: https://git.openjdk.org/jdk/pull/20665

From dholmes at openjdk.org  Wed Oct 23 06:18:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:18:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>

On Wed, 23 Oct 2024 00:35:06 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:
> 
>   Address David's comments to ObjectMonitor.hpp

> 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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431004707

From alanb at openjdk.org  Wed Oct 23 06:41:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 06:41:13 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v6]
In-Reply-To: <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>
Message-ID: <eCawAsDX_owZu-vk5k_vJhSlteriE1Jw6hYK7W9frxY=.894c8f13-a98b-41d6-aad3-925daf2364f6@github.com>

On Wed, 23 Oct 2024 00:09:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233451: Added test of readNBytes(int)

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21508#pullrequestreview-2387435769

From alanb at openjdk.org  Wed Oct 23 07:27:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 07:27:15 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v8]
In-Reply-To: <15ZEmA1D4X71LAEk66t2yPYmkdYvOI5W1ySny1-k9TI=.14eb1bd0-d75a-4a93-899c-a563a53bb058@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <15ZEmA1D4X71LAEk66t2yPYmkdYvOI5W1ySny1-k9TI=.14eb1bd0-d75a-4a93-899c-a563a53bb058@github.com>
Message-ID: <ak89_CLmtt00JS8ZiVpHDo8cAihMalDuWRZvTuu1YLQ=.0ef6c740-02ef-4659-8d52-b762961d6b18@github.com>

On Tue, 22 Oct 2024 19:16:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn 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
>  - review: explain better what methods can be annotated with JvmtiMountTransition
>  - review: clarify the use of annotation @JvmtiMountTransition in yield/yield0
>  - review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller
>  - review: tweaked disabler for carrier threads; more hiddenjvmti_mount_transition frames
>  - Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>  - review: 1. Minor tweaks in new test; 2. Refactor skip_hidden_frames in two
>  - fix one more place with trailing spaces
>  - fix trailing spaces
>  - add new test coverage with  vthread/CheckHiddenFrames
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/d6eddcda...54dc2b4a

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java line 32:

> 30: /**
> 31:  * A method may be annotated as "jvmti mount transition" to hint
> 32:  * it is desirable to omit it from JVMTI stack traces.

Might be better to replace both usages of "jvmti mount transition" with JvmtiMountTransition.

"virtual thread mount state transition (VTMS transition)" should probably be "Virtual Thread Mount State (VTMS) transition".

The updated wording is better but I think this still hard to audit to know if you've got the usages in the right place. Maybe we can re-visit it in the future.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21397#pullrequestreview-2387552132
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1812046832

From alanb at openjdk.org  Wed Oct 23 07:37:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 07:37:11 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence)
In-Reply-To: <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <hB8NxWbGkwCasVL1G0TIE7bC7_SSYeCMTS6Y3lLWJnw=.7b33d699-7a7b-4e3a-8bae-026e64f3ffc7@github.com>
 <9n5ywA6OBlMrKFLnIVz8ZJ5DUgHJO4TfIZ2ieIQtAMg=.49b1096f-160a-44c2-bfb8-726469c94139@github.com>
 <nuA_YB3E5MRMfKrtKUXEvXCwpZouJyO3eMSd5TRHNcI=.1ed707b4-e619-40d3-b908-17f5c444bb15@github.com>
Message-ID: <rmStIfLdeCVySM7lLfvfLOHsX0zK72FdEMFpaSwPem8=.b0916b53-b6d9-4385-b0d2-a07ba448deed@github.com>

On Wed, 9 Oct 2024 10:40:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> @AlanBateman Can you please review [the CSR request](https://bugs.openjdk.org/browse/JDK-8341596) so I can finish it? Thanks!
>> 
>> Latest API docs looks good, will you update the CSR?
>
>> @AlanBateman WDYT?
> 
> A title like "Add Reader.of(CharSequence)" would make it clear to everyone what this issue, and the CSR, is about.

> @AlanBateman As the CSR is approved, kindly asking for your review of this PR to finally integrate the changes. Thanks.

I suggested this factory method so my interest/focus has been in its specification, I have not had cycles to look at the implementation or tests but you've got plenty of eyes on it. Minor edits would be make "The reader is initially .." the second sentence of the first paragraph rather than a new paragraph. Also "The returned reader supports the mark and reset ..." could move up to become the second paragraph. Otherwise happy that this ended up a static factory method rather than a new implementation class in the API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2431153332

From jvos at openjdk.org  Wed Oct 23 08:26:07 2024
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 23 Oct 2024 08:26:07 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <yDZJc66GqRWwaNORthZ6yepgT6iJPCI29-l_opf33OI=.a310dfa1-11a2-4243-8ed4-2adae0e878ee@github.com>

On Tue, 15 Oct 2024 20:22:52 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:
> 
>   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");

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2431273631

From duke at openjdk.org  Wed Oct 23 08:58:30 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 23 Oct 2024 08:58:30 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

Markus KARG has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
 - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21371/files
  - new: https://git.openjdk.org/jdk/pull/21371/files/a668f24e..97e3144c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21371&range=13-14

  Stats: 7 lines in 1 file changed: 1 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21371/head:pull/21371

PR: https://git.openjdk.org/jdk/pull/21371

From alanb at openjdk.org  Wed Oct 23 09:01:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 09:01:21 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <WmRdpEmuZHVrS2gGP0bH3kqOPmshzsVJ1mR5FAmEezM=.f3d28b54-e918-48b4-bbd7-a62d827da2e9@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2387831134

From duke at openjdk.org  Wed Oct 23 09:05:17 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 23 Oct 2024 09:05:17 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <uehaoD8r2T9d701uAHkzDxifvwYyYZtKiGDzfn_kXGI=.2637a1ac-d85d-4c13-a34d-0d510f92065d@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

Thank you, Alan. I now have adjusted the JavaDocs to your exact proposals.

Kindly requesting final reviews from everybody, so we can finally move this PR through the door. Thank you! :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2431383758

From duke at openjdk.org  Wed Oct 23 09:11:11 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 23 Oct 2024 09:11:11 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v14]
In-Reply-To: <4udJymYBv2T-qavcN683i1agExGsVVQkeZdE0Z3JmOQ=.6e24639c-54d0-44a9-8a90-bd6a0640bc1e@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <VelSA_jnWC6n1Y9oih-xMdumjQo3IwGjzveK0C96X0c=.fe5ea778-4644-476d-b144-dcad667acf24@github.com>
 <3XmMc58Yw09rGZUxh49MRD9UzIF8AkEGMgJ68v2-ufk=.f0ac56a8-434f-469a-88c9-a61ee13e18d9@github.com>
 <4udJymYBv2T-qavcN683i1agExGsVVQkeZdE0Z3JmOQ=.6e24639c-54d0-44a9-8a90-bd6a0640bc1e@github.com>
Message-ID: <fZc_UXEfxUgHzm1vSF6u_npZeBDUcBSM7b1MBpSr6Ic=.4a29a59a-ffa1-4e2f-9af6-6ee99a662b85@github.com>

On Mon, 21 Oct 2024 17:06:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Will the Reader need to catch IndexOutOfBoundsException and BufferUnderFlowException then wrap them as EOFException? I would think these errors should not escape the Reader as is if a source CharBuffer limit is tampered with.  Or is this not an issue?
>
> @jmehrens We have this in our specification:
> 
>>  If the sequence changes while the reader is open, e.g. the length changes, the behavior is undefined.
> 
> Thus your scenario is not an issue.

@liach Alan's latest minor edit request auto-removed your approval from this PR. Kindly asking to reapply your approval. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2431406810

From aph at openjdk.org  Wed Oct 23 09:36:58 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 23 Oct 2024 09:36:58 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v5]
In-Reply-To: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
Message-ID: <baYDBrUTPFMRmRuHjY6HDkW_tCuaH0YUgMYTZFfdYOY=.f40eb788-2385-470e-9acc-c59372a0fcf3@github.com>

> The fourth preview of scoped values.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  API change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21456/files
  - new: https://git.openjdk.org/jdk/pull/21456/files/052553ea..7ec8e8de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Wed Oct 23 09:50:12 2024
From: duke at openjdk.org (duke)
Date: Wed, 23 Oct 2024 09:50:12 GMT
Subject: Withdrawn: 8317980: Optimization for Integer.parseInt and
 Long.parseLong
In-Reply-To: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
Message-ID: <PyNgu1tuRQ4O1zgfD6uOJyz25UmzjEkLJZpFNraXLLM=.44d4fef4-acec-47dd-a564-c14ef093b2c1@github.com>

On Fri, 12 Jul 2024 23:53:23 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
> 
> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20168

From alanb at openjdk.org  Wed Oct 23 09:56:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 09:56:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
Message-ID: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@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 rrich at openjdk.org  Wed Oct 23 09:56:12 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 23 Oct 2024 09:56:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>

On Wed, 23 Oct 2024 00:35:06 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:
> 
>   Address David's comments to ObjectMonitor.hpp

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()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377293

From alanb at openjdk.org  Wed Oct 23 09:57:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 09:57:06 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v5]
In-Reply-To: <baYDBrUTPFMRmRuHjY6HDkW_tCuaH0YUgMYTZFfdYOY=.f40eb788-2385-470e-9acc-c59372a0fcf3@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
 <baYDBrUTPFMRmRuHjY6HDkW_tCuaH0YUgMYTZFfdYOY=.f40eb788-2385-470e-9acc-c59372a0fcf3@github.com>
Message-ID: <1lF3OozTRR10_CNf2kTpHBy_ZX3WNSeVQfkrF93wOMg=.e1a2e09f-dcc0-43c5-a31f-f6207455edf3@github.com>

On Wed, 23 Oct 2024 09:36:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The fourth preview of scoped values.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   API change

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21456#pullrequestreview-2388019011

From alanb at openjdk.org  Wed Oct 23 10:01:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:01:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
Message-ID: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>

On Wed, 23 Oct 2024 09:53:53 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> 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 Oct 23 10:04:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:04:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
Message-ID: <_NABF4JJUlSQ9_XfNtXtDGFIkqOPpDcUaoL6wAaJFkY=.df72d7c2-f9a1-431d-984d-2b99febcbed2@github.com>

On Wed, 23 Oct 2024 00:56:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> 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 Oct 23 10:09:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:09:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>
Message-ID: <ekXIc0jjx_4MlD-GhPzW5S5LA4GARcY2WSXvLmnRl04=.3cc80103-51c0-476b-ac36-9568f0b5cb53@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 redestad at openjdk.org  Wed Oct 23 10:28:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 23 Oct 2024 10:28:07 GMT
Subject: RFR: 8342040: Further improve entry lookup performance for
 multi-release JARs [v3]
In-Reply-To: <XcMWXJAQDY59g8JqkZHFIP3e9Wxi4CeiTiN36HaEG5E=.1f5b3900-7e0d-419c-a936-523c55565be2@github.com>
References: <msIxVCgaWRojCWF6PyZ5tnwWZzPJ5AyqkXtcLfV_vo0=.09e22db6-56f1-4e1a-8f70-00fbe7e2d9fa@github.com>
 <3AnmGVaQ0FToNg2uNrw-kkc_EQ9rceGbDIDVLVDi_hw=.524f6110-c5c4-43b9-bc0c-bc4e4b7e51e7@github.com>
 <cINvSoS5l3VqY6Qmtgw-yg6Vs9sv7v2U22ZiaMVMlMc=.815a783a-a74d-4baf-9dc4-509d53f8ebbf@github.com>
 <XcMWXJAQDY59g8JqkZHFIP3e9Wxi4CeiTiN36HaEG5E=.1f5b3900-7e0d-419c-a936-523c55565be2@github.com>
Message-ID: <hCwGhn4F4_jL9vO729HL_YcsEB93ytafMbmqMSpkaKw=.85cf0a76-f911-4721-a3b0-1e11126298f9@github.com>

On Fri, 18 Oct 2024 16:02:26 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1796:
>> 
>>> 1794:                                 if (metaVersions == null)
>>> 1795:                                     metaVersions = new HashMap<>();
>>> 1796:                                 metaVersions.computeIfAbsent(hashCode, _ -> new BitSet()).set(version);
>> 
>> Does this hashCode ever collide? Tried reading ZipCoder and can't rule that out. If yes, we need a fallback mechanism if this `computeIfAbsent` encountered an existing entry.
>
> Yes it may collide. This is an overapproximation of the version set where a hash collision just results?in an extra lookup being performed for a version entry which?does not exist for that name. See the comment on the `metaVersions` field declaration.
> 
> This is a trade-off against the initial alternative?proposed in this PR which was to map using the entry name string. That would minimize lookups, but it would also require allocating the String name and storing those strings in the map. So we decided a few extra lookups on hash collisions was an okay trade-off for faster parsing and less memory used.   
> 
> In fact, if we a use constant hash code like '1', such that _all_ hash codes collide, we get the behavior of the current mainline, where a search for any name will result in searches being performed for each version discovered in the ZIP.

In principle the `metaVersions` map acts as a filter to reduce entry lookups, so it's ok to give false positives but not false negatives. 

Other alternatives such as mapping from entry length to a `BitSet` would also be semantically fine, would carry less of a footprint and per-versioned-entry-`initCEN` overhead, but might degrade to more false positives as the number of versioned entries in a jar file grows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21489#discussion_r1812437330

From redestad at openjdk.org  Wed Oct 23 10:35:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 23 Oct 2024 10:35:06 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v8]
In-Reply-To: <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>
Message-ID: <et5Ar_Ghz-wklNb1dXhuTz76YgH7-cwYDy3s87CsGAU=.950992a8-96e5-43ee-a7c4-06fd99fcf2f4@github.com>

On Wed, 23 Oct 2024 06:14:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix displayName
>   
>   Turns out ArrayClassDesc::displayName was incorrect. Added a test.

Updates since last review looks good

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2388154491

From alanb at openjdk.org  Wed Oct 23 11:35:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:35:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
Message-ID: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812537648

From liach at openjdk.org  Wed Oct 23 11:44:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 11:44:12 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <19eWcQu1tAY7YvBlwmCswqlazFQKJv97LDN0onxQyLU=.3caa6677-3456-4bf5-961f-0005c9ec260b@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

The javadoc text changes look fine; since this does not constitute specification changes, we don't need to re-draft our CSR to reflect the text changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2431842305

From liach at openjdk.org  Wed Oct 23 11:48:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 11:48:13 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <SyPPVlBjjDnzo-E8fDnunbpbvBBB5hJKwYVSAd3Wfv0=.3ac66865-997b-4afc-bfe6-b972bf239c55@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

The diff from Jaikiran and Roger's latest review is: https://github.com/openjdk/jdk/compare/487b93864274f5a27449e8ce0d925be333db6600...97e3144cde798090a113d5cd3176cbc7fb3ef759

There's no implementation change, so assuming the previous reviewers' approvals hold.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2388339303

From alanb at openjdk.org  Wed Oct 23 11:52:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:52:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
 <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>
Message-ID: <EEdxqnOAo9_wdmwyW4F-nsSKR-G1K_Lgy-TQHEfPB74=.38278323-1010-4b56-955e-4ad3fe4b0c91@github.com>

On Mon, 21 Oct 2024 17:20:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.
> 
> Fixed, will be in next drop. There are a couple of other micro tests that test the performance of `AccessController.doPrivileged` and `getContext` which probably don't make sense anymore, but I've left them for now to be looked at later.

I checked the commit in the sandbox and it looks okay. It may be some future maintenance in these micros may do some pruning as aren't too useful now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2431865182

From alanb at openjdk.org  Wed Oct 23 11:57:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:57:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:

> 340:         throws Exception
> 341:     {
> 342:         action.run();

testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812582305

From alanb at openjdk.org  Wed Oct 23 12:01:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:01:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>

On Tue, 22 Oct 2024 21:20:59 GMT, Mandy Chung <mchung 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
> 
>> 31:  * @test
>> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
>> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest
> 
> line 36 can also be removed.
> 
> 
> * $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest

hasSM and the code that only runs when true can be deleted too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812587449

From alanb at openjdk.org  Wed Oct 23 12:17:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:17:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:

> 239:         Properties props = System.getProperties();
> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
> 241:         System.setSecurityManager(new SecurityMan());

I assume SecurityMan should be removed too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812614134

From duke at openjdk.org  Wed Oct 23 12:21:12 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 23 Oct 2024 12:21:12 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <aO0cDgDdbdVpEQLYCYUx-vOntAETvYVbCg3msaYARIM=.ad2284d2-6f2f-4245-bd9c-aec8a14ae572@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

I do share Chen's assumption, therefore requesting integration now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2431937765

From duke at openjdk.org  Wed Oct 23 12:21:12 2024
From: duke at openjdk.org (duke)
Date: Wed, 23 Oct 2024 12:21:12 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <pGw8-NSA33VDqa6cZcHutggYXTiucnDUATv7bQkRIys=.75434a99-2e85-4884-8583-f04e40f9692f@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

@mkarg 
Your change (at version 97e3144cde798090a113d5cd3176cbc7fb3ef759) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2431939399

From liach at openjdk.org  Wed Oct 23 12:29:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 12:29:11 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <XLPRBf6keFw0bH73vLwnKbITMyoIJysBAOpJgRvPDG4=.b26eba56-f294-4d59-8aed-fbf2452c12a4@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

Please allow us to run some internal testing to ensure there won't be intermittent test failures before anyone sponsors this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2431975009

From rgiulietti at openjdk.org  Wed Oct 23 12:35:11 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Oct 2024 12:35:11 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]
In-Reply-To: <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
Message-ID: <bEapKDu-Gzs3676Ce4vWoFwbFscqpWG_hWwrh7rWk4o=.91cef148-484b-42b2-be7a-73572c269153@github.com>

On Tue, 22 Oct 2024 23:47:33 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:
> 
>   Add equals/hashCode implementation; tests to follow.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 472:

> 470:                      }
> 471:                  }
> 472:              }

(nit)
Then indents are not "multiples of 4" in the lines of this method's body.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1812653888

From coleenp at openjdk.org  Wed Oct 23 12:47:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 12:47:34 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/hotspot/share/prims/jvm.cpp line 1272:

> 1270: 
> 1271: 
> 1272: // Returns the inherited_access_control_context field of the running thread.

There's some code in this file in 
static void trace_class_resolution_impl(Klass* to_class, TRAPS) {

That does this:


    while (!vfst.at_end()) {
      Method* m = vfst.method();
      if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
          !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
          !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
        break;
      }
      last_caller = m;
      vfst.next();
    }


Is this dead code that should be removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812677985

From rgiulietti at openjdk.org  Wed Oct 23 12:56:08 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 23 Oct 2024 12:56:08 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]
In-Reply-To: <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
Message-ID: <t6pGegyDnR74WQH2jyD44FCn4w8C4_iVgjgS1ZyGuTU=.8bf700a6-8ab1-4d92-b0d0-03230830f984@github.com>

On Tue, 22 Oct 2024 23:47:33 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:
> 
>   Add equals/hashCode implementation; tests to follow.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 708:

> 706:     public static int hashCode(Float16 value) {
> 707:         Float16 f16 = isNaN(value) ? Float16.NaN : value;
> 708:         return (int)float16ToRawShortBits(f16);

What about randomizing the returned value? IIUC, JEP 401 does not speak against.
The purpose would not be to conceal anything, but to ensure that clients cannot rely on specific values.


    private static final int HASH_MASK = RandomGenerator.getDefault().nextInt();
    
    /**
     * Returns a hash code for a {@code Float16} value; compatible with
     * {@code Float16.hashCode()}.
     *
     * @param value the value to hash
     * @return a hash code value for a {@code Float16} value.
     */
    public static int hashCode(Float16 value) {
        Float16 f16 = isNaN(value) ? Float16.NaN : value;
        int bits = float16ToRawShortBits(f16);
        return (bits << 16 | bits & 0xFFFF) ^ HASH_MASK;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1812694738

From alanb at openjdk.org  Wed Oct 23 12:56:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:56:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
Message-ID: <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>

On Wed, 23 Oct 2024 12:44:53 GMT, Coleen Phillimore <coleenp 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/hotspot/share/prims/jvm.cpp line 1272:
> 
>> 1270: 
>> 1271: 
>> 1272: // Returns the inherited_access_control_context field of the running thread.
> 
> There's some code in this file in 
> static void trace_class_resolution_impl(Klass* to_class, TRAPS) {
> 
> That does this:
> 
> 
>     while (!vfst.at_end()) {
>       Method* m = vfst.method();
>       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
>           !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
>           !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
>         break;
>       }
>       last_caller = m;
>       vfst.next();
>     }
> 
> 
> Is this dead code that should be removed?

This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812694528

From asotona at openjdk.org  Wed Oct 23 13:10:07 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 23 Oct 2024 13:10:07 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction
In-Reply-To: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
Message-ID: <_rFfmi1HTvWvupnonQzf2FzIiKsmUCJXYHslnXCEdKQ=.55218ae2-ef5f-4c2e-9dfa-03ffdcab46c3@github.com>

On Mon, 21 Oct 2024 22:43:42 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.

Great job done!
It would be good to have another pair of eyes to read the new doc, however it looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21625#pullrequestreview-2388632892

From dfuchs at openjdk.org  Wed Oct 23 13:10:37 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Oct 2024 13:10:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
Message-ID: <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>

On Wed, 23 Oct 2024 11:54:39 GMT, Alan Bateman <alanb 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:
> 
>> 340:         throws Exception
>> 341:     {
>> 342:         action.run();
> 
> testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?

Good point. Similarly, the URLPermission[] parameter is now always unused, so maybe I should get rid of that too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812727202

From jlahoda at openjdk.org  Wed Oct 23 13:13:20 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 23 Oct 2024 13:13:20 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v3]
In-Reply-To: <6t6044s7pqcy0dM-zUTzDTXjd1IVwMoge7ckm9WpvSs=.0f4027e4-f0c3-43cc-9f62-97d51fa446a6@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <GjcdUHXVg4sit42DFter0mQ9IO2zutsJp7Fv55H8_-w=.34464e66-0049-4e01-9a99-09ece065fd12@github.com>
 <6t6044s7pqcy0dM-zUTzDTXjd1IVwMoge7ckm9WpvSs=.0f4027e4-f0c3-43cc-9f62-97d51fa446a6@github.com>
Message-ID: <xFAXPbo_z4l7YbO6SgRt-dmbhN8etgyXf1LZJDoyB6c=.f5b7bba2-9daa-4b1c-bd51-e4da434bd143@github.com>

On Mon, 21 Oct 2024 11:03:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge branch 'master' into JDK-8335989
>>  - Reflecting review feedback.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing tests
>>  - Adding a separate scope for module imports.
>>  - Cleanup.
>>  - Make very sure java.base is completed.
>>  - Keep jdk.internal.javac qualified export from java.base.
>>  - Adding forgotten change.
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/15815089...b5f9df2a
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 1141:
> 
>> 1139:             return true;
>> 1140:         } else if (sym.kind == TYP && toplevel != null) {
>> 1141:             for (Scope scope : new Scope[] {toplevel.namedImportScope,
> 
> I wonder if we could deal with this with a compound scope? (and avoid the loop)

In principle, we could, but the `CompoundScope` is a bit heavier, so it might be better to keep the loop here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21431#discussion_r1812730863

From jpai at openjdk.org  Wed Oct 23 13:13:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 23 Oct 2024 13:13:24 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <dvbElysdgmQfBPQv4_vJ7_fU6FzbCTtvVvnw-7I5mpQ=.9c5e8412-4366-4543-82ba-1cc61ed93eea@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2388639623

From darcy at openjdk.org  Wed Oct 23 15:40:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 15:40:08 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <rK9UXp5kMwblo1tpxpBQliPOipXXlIUo5WQaGywY4QQ=.54a3b925-9850-4364-8bf8-1efddab1583b@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
 <rK9UXp5kMwblo1tpxpBQliPOipXXlIUo5WQaGywY4QQ=.54a3b925-9850-4364-8bf8-1efddab1583b@github.com>
Message-ID: <mZcfjAQQlO2vS_30HXc0eu-YfbF_A3Emz1cBOpfZIoM=.66f759ff-8782-46e2-9ab8-af1dbf246cfa@github.com>

On Wed, 23 Oct 2024 05:45:33 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Noticed this refactoring opportunity while doing some other work in the area.
>
> src/java.base/share/classes/java/lang/Boolean.java line 259:
> 
>> 257:     public boolean equals(Object obj) {
>> 258:         if (obj instanceof Boolean b) {
>> 259:             return value == b.booleanValue();
> 
> I would go even a step further and use `value` instead of `booleanValue()`, `intValue()` etc because there is no need to call a method to get the value.
> 
> 
>   if (obj instanceof Boolean b) {
>             return value == b.value;

Hi @forax,
Yes, I had considered that before sending out the PR. It shouldn't matter from a performance perspective, so it would come to down to which version of the code was marginally easier to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21652#discussion_r1813056177

From darcy at openjdk.org  Wed Oct 23 15:40:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 15:40:09 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <NAXG_BI1NeWRx1ZO5eqGMFNjDXeLT2Uz_pijXMKPpPA=.60ffd425-aae2-42c6-b42f-79696befbd12@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
 <NAXG_BI1NeWRx1ZO5eqGMFNjDXeLT2Uz_pijXMKPpPA=.60ffd425-aae2-42c6-b42f-79696befbd12@github.com>
Message-ID: <T8fYzke-4H6050LxvrMvOr5lvsGmrQbR07Wr4V3Jy2I=.2633e188-b332-4683-8f4c-e0b19bd322b2@github.com>

On Wed, 23 Oct 2024 02:14:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Noticed this refactoring opportunity while doing some other work in the area.
>
> src/java.base/share/classes/java/lang/Long.java line 1249:
> 
>> 1247:     public boolean equals(Object obj) {
>> 1248:         if (obj instanceof Long ell) {
>> 1249:             return value == ell.longValue();
> 
> Suggestion:
> 
>         if (obj instanceof Long l) {
>             return value == l.longValue();

In other place in the code, I've written out "ell" to avoid any confusion between lowercase "l" and a number "1", etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21652#discussion_r1813057470

From darcy at openjdk.org  Wed Oct 23 15:43:14 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 15:43:14 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]
In-Reply-To: <t6pGegyDnR74WQH2jyD44FCn4w8C4_iVgjgS1ZyGuTU=.8bf700a6-8ab1-4d92-b0d0-03230830f984@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
 <t6pGegyDnR74WQH2jyD44FCn4w8C4_iVgjgS1ZyGuTU=.8bf700a6-8ab1-4d92-b0d0-03230830f984@github.com>
Message-ID: <KoEhJ8MA5YRXU1NZ0RELlN6lQA0zc_2LVNRayf_klBY=.8b133b50-0322-4aac-a4a5-55a5ffd527c4@github.com>

On Wed, 23 Oct 2024 12:53:20 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add equals/hashCode implementation; tests to follow.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 708:
> 
>> 706:     public static int hashCode(Float16 value) {
>> 707:         Float16 f16 = isNaN(value) ? Float16.NaN : value;
>> 708:         return (int)float16ToRawShortBits(f16);
> 
> What about randomizing the returned value? IIUC, JEP 401 does not speak against.
> The purpose would not be to conceal anything, but to ensure that clients cannot rely on specific values.
> 
> 
>     private static final int HASH_MASK = RandomGenerator.getDefault().nextInt();
>     
>     /**
>      * Returns a hash code for a {@code Float16} value; compatible with
>      * {@code Float16.hashCode()}.
>      *
>      * @param value the value to hash
>      * @return a hash code value for a {@code Float16} value.
>      */
>     public static int hashCode(Float16 value) {
>         Float16 f16 = isNaN(value) ? Float16.NaN : value;
>         int bits = float16ToRawShortBits(f16);
>         return (bits << 16 | bits & 0xFFFF) ^ HASH_MASK;
>     }

Hmm. Certainly at this point, I don't think hash randomization is necessary; although it might be helpful at a later point. Set.of() uses randomized iteration order as a precedent in that direction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813063677

From duke at openjdk.org  Wed Oct 23 15:43:22 2024
From: duke at openjdk.org (duke)
Date: Wed, 23 Oct 2024 15:43:22 GMT
Subject: Withdrawn: 8338931: ZipEntry.flag could be made internal to
 ZipOutputStream
In-Reply-To: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>
References: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>
Message-ID: <4M50KGsAU3pGKHrshlr12axTHV6r6sP5ZYfYJLFhJX0=.aee7b72f-4abc-4a3b-9091-0193a6bf4c6f@github.com>

On Sat, 24 Aug 2024 10:49:56 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this refactoring PR which moves the `ZipEntry.flag` field back to `ZipOutputStream.XEntry`.
> 
> Moving this field will save four bytes from the `ZipEntry` object size and also saves an unneccessary read in `ZipFile.getZipEntry`.
> 
> Testing:
> 
> This PR is a refactoring of existing code and does not update any tests. I added the label `noreg-cleanup` to the JBS issue.
> 
> The following runs clean:
> 
> 
> make test TEST="test/jdk/java/util/zip"
> make test TEST="test/jdk/java/util/jar"
> 
> 
> Performance:
> 
> The JMH benchmark `java.util.zip.ZipFileGetEntry.getEntryHit` show a small but consistent improvement (2-3%).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20702

From darcy at openjdk.org  Wed Oct 23 15:49:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 15:49:08 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]
In-Reply-To: <-YmH55zDMO2AcS9t0Z5lqxFgkvtrdeiefUri-x369CI=.d07ef844-07f2-4894-8864-c553b0da6c8c@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
 <-YmH55zDMO2AcS9t0Z5lqxFgkvtrdeiefUri-x369CI=.d07ef844-07f2-4894-8864-c553b0da6c8c@github.com>
Message-ID: <aophYsBfdkioGZDPrpKYNDWciZHDdjVbnQGqQ-pM1Wc=.bb9d7f24-c65e-4043-98e3-0d6d86246e51@github.com>

On Wed, 23 Oct 2024 01:03:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add equals/hashCode implementation; tests to follow.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 865:
> 
>> 863:     public static Float16 min(Float16 a, Float16 b) {
>> 864:         return shortBitsToFloat16(floatToFloat16(Math.min(a.floatValue(),
>> 865:                                                           b.floatValue()) ));
> 
> I assume we will optimize these min/max implementations in the future. Otherwise, the extra space should be removed.

The general intention is that the back-end intrinsification efforts that use native hardware instructions, where present, will provide the main speed boost. Therefore, the preference has been to keep the Java sources in Float16 as straightforward and "obviously correct" as possible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813074826

From bpb at openjdk.org  Wed Oct 23 15:59:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Oct 2024 15:59:06 GMT
Subject: RFR: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files [v6]
In-Reply-To: <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
 <B3hrFJxByp8MeR-AxevDuMGoAa1G0URO0o9v2AliArk=.a3fa956a-c219-4978-b107-d6cdf1fd8ec6@github.com>
Message-ID: <_-6pzdPmIivCoYx6V5LdK3nm-BzF8rPDv4VqhatVygM=.51450c30-f082-45c3-85a5-67ea2363269f@github.com>

On Wed, 23 Oct 2024 00:09:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8233451: Added test of readNBytes(int)

30 repeats on all platforms succeeded also after the most recent commit, 2876d9f.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21508#issuecomment-2432715348

From rriggs at openjdk.org  Wed Oct 23 16:05:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Oct 2024 16:05:12 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
Message-ID: <hZyEsKlfQuzLNstV5EGUUP-sajAG81OrZsABBph_9Aw=.24028dee-c4c0-4b3d-8017-42e9bd7aa55e@github.com>

On Wed, 23 Oct 2024 02:06:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Noticed this refactoring opportunity while doing some other work in the area.

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21652#pullrequestreview-2389308583

From mchung at openjdk.org  Wed Oct 23 16:07:10 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 23 Oct 2024 16:07:10 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v8]
In-Reply-To: <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>
Message-ID: <FC0M6mZopSWCWhG8NF58BHijFTSndN-kfws9-LIVj_Y=.d20eb3c2-1305-4520-85a5-5544066cbf57@github.com>

On Wed, 23 Oct 2024 06:14:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix displayName
>   
>   Turns out ArrayClassDesc::displayName was incorrect. Added a test.

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2389320019

From rriggs at openjdk.org  Wed Oct 23 16:12:15 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Oct 2024 16:12:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <K_HHf6OgNoOa01gm8SUzyaFjWAR7FGYTLTy1QuxJ2Fc=.37bc08e8-6ed7-4eb2-8a06-cadba3bb97b9@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21371#pullrequestreview-2389333089

From liach at openjdk.org  Wed Oct 23 16:13:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 16:13:09 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <T8fYzke-4H6050LxvrMvOr5lvsGmrQbR07Wr4V3Jy2I=.2633e188-b332-4683-8f4c-e0b19bd322b2@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
 <NAXG_BI1NeWRx1ZO5eqGMFNjDXeLT2Uz_pijXMKPpPA=.60ffd425-aae2-42c6-b42f-79696befbd12@github.com>
 <T8fYzke-4H6050LxvrMvOr5lvsGmrQbR07Wr4V3Jy2I=.2633e188-b332-4683-8f4c-e0b19bd322b2@github.com>
Message-ID: <O5KdRqMhlCEpOPmZpBP3MruSMFppgpStsQWRnYKkXZA=.7e2e02f4-29df-4cf3-8736-81914f0bbb46@github.com>

On Wed, 23 Oct 2024 15:37:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Long.java line 1249:
>> 
>>> 1247:     public boolean equals(Object obj) {
>>> 1248:         if (obj instanceof Long ell) {
>>> 1249:             return value == ell.longValue();
>> 
>> Suggestion:
>> 
>>         if (obj instanceof Long l) {
>>             return value == l.longValue();
>
> In other place in the code, I've written out "ell" to avoid any confusion between lowercase "l" and a number "1", etc.

What does "ell" stand for? Looks like "eel" to me.
That aside, if there's no good name, we usually use `that` or `o` for the casted variable, like

return obj instanceof Long that && this.value == that.value;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21652#discussion_r1813114216

From weijun at openjdk.org  Wed Oct 23 16:44:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 23 Oct 2024 16:44:12 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <vkFXDrfqmjr7DCBmg3owJbqmXtyLTT-caPh4uAoP6e8=.49c1ee9d-6a70-4686-9e67-b761a1a1da38@github.com>

On Mon, 21 Oct 2024 14:34:30 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

The `security.cpp` looks fine to me. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2432824930

From cjplummer at openjdk.org  Wed Oct 23 16:50:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 23 Oct 2024 16:50:10 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
 <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
Message-ID: <E-Bf06aA-4rDKiEguZePf70RDhRM2y0cJbc0BFunkfg=.174159ca-f410-4035-9c77-d98dd6088d09@github.com>

On Wed, 23 Oct 2024 05:23:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 53:
>> 
>>> 51: #ifndef _WIN32
>>> 52: static MUTEX_T my_mutex = MUTEX_INIT;
>>> 53: #endif
>> 
>> The reason for no reference on windows is because of the following on windows:
>> 
>> 
>> #define MUTEX_LOCK(x)           /* FIXUP? */
>> #define MUTEX_UNLOCK(x)         /* FIXUP? */
>> 
>> 
>> So looks like this mutex support is something we never got around to. I think your current workaround is fine.
>
> I'm curious now, how to implement mutex support on Windows? I think I prefer that to just making it completely unavailable on Windows

We've gone 20 years without it on Windows, so I'm inclined not to worry about the lack of support on Windows. Logging is not used often in the debug agent. I've turned in on once in a while but usually find it too noisy and hard to read. What I usually opt for is changing some of the log_message() calls to instead just use tty_message().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1813176284

From cjplummer at openjdk.org  Wed Oct 23 16:54:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 23 Oct 2024 16:54:10 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
 <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
Message-ID: <PVYkac0hz2kZm06cfLm0wmoScou2H1ALnkUMLcGAW3s=.7ef6e0df-8950-4aa5-bb8f-bf1a33830221@github.com>

On Wed, 23 Oct 2024 05:22:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 47:
>> 
>>> 45: {
>>> 46:     void *mappedMemory;
>>> 47:  // HANDLE memHandle;
>> 
>> Why comment out this one but not the one at line 88? It seems they are both equally problematic and are hiding the static memHandle. I'm not sure why the 2nd one isn't flagged. I'd actually suggest getting rid of the static memHandle. It does not seem to be needed.
>
> I wasn't sure whether the global memHandle not being used was a bug, so I commented out the local one. I missed the line 88 one because it wasn't flagged. If it really isn't needed I'll remove that one instead

I'm not sure what you mean by "that one". It's the static one that should be removed. The local variables always hide the static, and there seems to be no reason for the value of memHandle to survive outside of the local scope it is used in.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1813181393

From psandoz at openjdk.org  Wed Oct 23 17:07:07 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 23 Oct 2024 17:07:07 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]
In-Reply-To: <aophYsBfdkioGZDPrpKYNDWciZHDdjVbnQGqQ-pM1Wc=.bb9d7f24-c65e-4043-98e3-0d6d86246e51@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
 <-YmH55zDMO2AcS9t0Z5lqxFgkvtrdeiefUri-x369CI=.d07ef844-07f2-4894-8864-c553b0da6c8c@github.com>
 <aophYsBfdkioGZDPrpKYNDWciZHDdjVbnQGqQ-pM1Wc=.bb9d7f24-c65e-4043-98e3-0d6d86246e51@github.com>
Message-ID: <lkFUhcBxIOoyaoaV-Zj6Y6b1y13zEHNKKlTrU1xjPR8=.e1c59010-d949-4f42-ac7f-62600e92a949@github.com>

On Wed, 23 Oct 2024 15:46:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 865:
>> 
>>> 863:     public static Float16 min(Float16 a, Float16 b) {
>>> 864:         return shortBitsToFloat16(floatToFloat16(Math.min(a.floatValue(),
>>> 865:                                                           b.floatValue()) ));
>> 
>> I assume we will optimize these min/max implementations in the future. Otherwise, the extra space should be removed.
>
> The general intention is that the back-end intrinsification efforts that use native hardware instructions, where present, will provide the main speed boost. Therefore, the preference has been to keep the Java sources in Float16 as straightforward and "obviously correct" as possible.

Yes, C2 optimizations and hardware instruction generation using intrinsics and other means where needed will follow in one or more subsequent PRs, where the auto-vectorizer and Vector API can utilize a common backend.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813197718

From pchilanomate at openjdk.org  Wed Oct 23 17:26:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
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: <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@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:

 - Rename timedWaitNonce to timedWaitSeqNo
 - Fix comment in Thread.java
 - Clear oops when thawing lockstack + add thaw_lockstack()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/b6bc98e2..e232b7f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=04-05

  Stats: 77 lines in 5 files changed: 29 ins; 18 del; 30 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 Oct 23 17:26:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <IhkGdT3usE5UZqOTAqS-hBQ2FE_2Lc_2pZK5hM_mkdg=.6ea43f0e-f158-414e-a675-ec9682fac8d8@github.com>

On Mon, 21 Oct 2024 12:32:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Rename timedWaitNonce to timedWaitSeqNo
>>  - Fix comment in Thread.java
>>  - Clear oops when thawing lockstack + add thaw_lockstack()
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813222417

From pchilanomate at openjdk.org  Wed Oct 23 17:26:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
 <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
 <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@github.com>
Message-ID: <21HfKDagatsu-A7zva9eZ_ndGye37_BRkJ3cyAKQoN0=.b256c1ad-c2d4-44e8-bc39-3201c5a29481@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 kizune at openjdk.org  Wed Oct 23 17:27:42 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 23 Oct 2024 17:27:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <cYDFZ0hXc_bXKTrCftDs1-Xd-Rr4iOpngFb3pB8zi2U=.6d408fe5-63bc-45a3-8ff4-264671975ed1@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Finished reviewing of accessibility (both in com.sun and jdk.javax), jdk.javax.sound and jdk.java.awt.Desktop. Looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2432939145

From rriggs at openjdk.org  Wed Oct 23 17:35:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Oct 2024 17:35:07 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v6]
In-Reply-To: <w4Vh3lJ2QKCEi-Y6LJTAl0mBSzYt8xchPfxbhhFKMks=.a5dccfd8-445a-47d3-be27-a5b204f414d6@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <w4Vh3lJ2QKCEi-Y6LJTAl0mBSzYt8xchPfxbhhFKMks=.a5dccfd8-445a-47d3-be27-a5b204f414d6@github.com>
Message-ID: <PihUjaSGOpZaUv2WFwywl0c0MKn75nRl_XILSJeDU_o=.61a6fab0-91cf-4f06-9607-451e2f94894a@github.com>

On Tue, 22 Oct 2024 18:55:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a typo

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21569#pullrequestreview-2389550580

From rriggs at openjdk.org  Wed Oct 23 17:36:11 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Oct 2024 17:36:11 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5 [v3]
In-Reply-To: <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
 <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>
Message-ID: <S6BJX9DQvSgI-_a3nt3JxIywV4Mt8EW_NdCke3Df3V4=.abf2d124-0631-4a13-b0d2-8b531cc48613@github.com>

On Tue, 22 Oct 2024 22:17:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected wrong assumption in the test

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21645#pullrequestreview-2389555515

From pchilanomate at openjdk.org  Wed Oct 23 17:36:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:36:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>

On Tue, 22 Oct 2024 07:03:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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/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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237094
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

From pchilanomate at openjdk.org  Wed Oct 23 17:36:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:36:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@github.com>
Message-ID: <v_7OhzC9sq5rI3jGQjn-W8sPfuqFRlaFWPwvxylxDYM=.f3de1cfd-c8dc-4fbb-8a44-a08e4555905f@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 naoto at openjdk.org  Wed Oct 23 17:47:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Oct 2024 17:47:12 GMT
Subject: RFR: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln [v6]
In-Reply-To: <w4Vh3lJ2QKCEi-Y6LJTAl0mBSzYt8xchPfxbhhFKMks=.a5dccfd8-445a-47d3-be27-a5b204f414d6@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
 <w4Vh3lJ2QKCEi-Y6LJTAl0mBSzYt8xchPfxbhhFKMks=.a5dccfd8-445a-47d3-be27-a5b204f414d6@github.com>
Message-ID: <uK0d5DHpyMyRbnHbxoCY_cUvbXpkplVE_-b5f0CQsJ0=.7ff3a85e-90d1-4c12-9938-79f30dad34fc@github.com>

On Tue, 22 Oct 2024 18:55:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a typo

Thank you for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21569#issuecomment-2432982750

From naoto at openjdk.org  Wed Oct 23 17:47:15 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Oct 2024 17:47:15 GMT
Subject: RFR: 8342582: user.region for formatting number no longer works
 for 21.0.5 [v3]
In-Reply-To: <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
 <Dsa9jmnANLArBPfD2Zk9KdT8rASzdzudUIwSIoKhm9s=.25ea1ed7-44aa-45cc-ac58-58b7566fdfe7@github.com>
Message-ID: <ewJn9flBhIPxfp1fiGdKWwQRtGbmSyu5fwnEmMvu2kI=.e8b844b5-4f95-4077-aa9b-259c9c140234@github.com>

On Tue, 22 Oct 2024 22:17:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected wrong assumption in the test

Thank you for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21645#issuecomment-2432983371

From naoto at openjdk.org  Wed Oct 23 17:47:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Oct 2024 17:47:13 GMT
Subject: Integrated: 8341975: Unable to set encoding for IO.println,
 IO.print and IO.readln
In-Reply-To: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
References: <Fv__nvLDWrZNpQieGAF2ft4M6eePESObumpd3KMCbK0=.a982306b-eb87-490e-b4ab-7a8a8261287a@github.com>
Message-ID: <k4rM5VD5ZTNGFgUKoBwWoFQWWBwLrGDsgjUC5d6CoW0=.2261b113-c461-40ce-9fc6-70f870cdb834@github.com>

On Thu, 17 Oct 2024 20:01:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Changing the charset initialization of `java.io.Console` class, which is the basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt encoding. This change will also have the capability to override the default charset used in `IO` methods with `stdout.encoding` system property. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 426da4bb
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/426da4bbad3a3eac15e8b17026ebad52b7c568ea
Stats:     113 lines in 5 files changed: 57 ins; 46 del; 10 mod

8341975: Unable to set encoding for IO.println, IO.print and IO.readln

Reviewed-by: rriggs, iris, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21569

From naoto at openjdk.org  Wed Oct 23 17:47:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Oct 2024 17:47:17 GMT
Subject: Integrated: 8342582: user.region for formatting number no longer works
 for 21.0.5
In-Reply-To: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
References: <OnpqbsXx4YvTZeLL6TVUiu1XMZDDjYby0J6A9ifgkPE=.341430a0-5f67-4392-8285-e8be76df4784@github.com>
Message-ID: <DCYNeukBiaqYww52KsAcMllvf-i9dsJhsIMaKZZEQsw=.702a115b-eeb7-4007-afaa-8d6c328ce289@github.com>

On Tue, 22 Oct 2024 18:09:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8321206](https://bugs.openjdk.org/browse/JDK-8321206), where the default locale with `user.region` creation is inadvertently broken. Fix is to restore the user.region override within StaticProperty initialization.

This pull request has now been integrated.

Changeset: e64f0798
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e64f0798be64d334b3ec2a918687aafc2031a8b7
Stats:     118 lines in 3 files changed: 91 ins; 20 del; 7 mod

8342582: user.region for formatting number no longer works for 21.0.5

Reviewed-by: jlu, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/21645

From honkar at openjdk.org  Wed Oct 23 18:06:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 18:06:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
Message-ID: <-GbMPbwNI--hHPZyyPgdU-pOMZh0Z4tZ_tLdbv-LL2E=.1494bfd4-7941-4c2e-af9b-82a29a4b2427@github.com>

On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan <psadhukhan 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
>> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
>> 
>>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
>> 
>>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
>> 
>>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
>> 
>>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
>> 
>> 
>> Left out comments that fall into out-of-scope/clean-up for jep486.
> 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

@prsadhuk 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud

Thanks! I didn't notice it happened again with the new changes. This was probably due to IDE settings. Since this was a recent change I have updated in the latest commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433031866

From prr at openjdk.org  Wed Oct 23 18:14:35 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 23 Oct 2024 18:14:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
Message-ID: <nTh2g7Sw6iv8lfDeUFsAru4vij3UTDzgCvhC8pwp3JU=.4546e9fb-99d9-48f9-8948-c6c1172355ea@github.com>

On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan <psadhukhan 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
>> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
>> 
>>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
>> 
>>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
>> 
>>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
>> 
>>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
>> 
>> 
>> Left out comments that fall into out-of-scope/clean-up for jep486.
> 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

> @prsadhuk
> 
> > looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud
> 
> Thanks! I didn't notice it happened again with the new changes. This was probably due to IDE settings. Since this was a recent change I have updated in the latest commit.

I also didn't realise you had "changed" it. I'm finding it very painful to navigate to the related files in this huge PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433046255

From prr at openjdk.org  Wed Oct 23 18:14:35 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 23 Oct 2024 18:14:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <ZLiF5TADkOkZ9p142_bjFkSO5cM4DKmqd7j3mnJxnhs=.2d8f316d-a604-4f17-be07-1a917491d5b3@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

I've reviewed all jdk/java/awt and jdk/javax/imageio tests.
I've either commented or proactively fixed in the jep sandbox branch. Or both.
Next sync from there should resolve those.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433048411

From darcy at openjdk.org  Wed Oct 23 18:28:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 18:28:40 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <O5KdRqMhlCEpOPmZpBP3MruSMFppgpStsQWRnYKkXZA=.7e2e02f4-29df-4cf3-8736-81914f0bbb46@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
 <NAXG_BI1NeWRx1ZO5eqGMFNjDXeLT2Uz_pijXMKPpPA=.60ffd425-aae2-42c6-b42f-79696befbd12@github.com>
 <T8fYzke-4H6050LxvrMvOr5lvsGmrQbR07Wr4V3Jy2I=.2633e188-b332-4683-8f4c-e0b19bd322b2@github.com>
 <O5KdRqMhlCEpOPmZpBP3MruSMFppgpStsQWRnYKkXZA=.7e2e02f4-29df-4cf3-8736-81914f0bbb46@github.com>
Message-ID: <EzLMsADP9BSqKh-qJVf7ETC9Sqf0J8Z2OPFXHUtvkWI=.ab7a93e8-2d95-41c4-8a31-c1046d1d4c0c@github.com>

On Wed, 23 Oct 2024 16:10:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In other place in the code, I've written out "ell" to avoid any confusion between lowercase "l" and a number "1", etc.
>
> What does "ell" stand for? Looks like "eel" to me.
> That aside, if there's no good name, we usually use `that` or `o` for the casted variable, like
> 
> return obj instanceof Long that && this.value == that.value;

"ell" is a way to write out the name for the letter "L" phonetically.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21652#discussion_r1813316500

From darcy at openjdk.org  Wed Oct 23 18:28:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 18:28:40 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <hZyEsKlfQuzLNstV5EGUUP-sajAG81OrZsABBph_9Aw=.24028dee-c4c0-4b3d-8017-42e9bd7aa55e@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
 <hZyEsKlfQuzLNstV5EGUUP-sajAG81OrZsABBph_9Aw=.24028dee-c4c0-4b3d-8017-42e9bd7aa55e@github.com>
Message-ID: <4DFpAfGdKeCcDlO-prxjVAEQ7bRLuxa-VCOtJ3dhmds=.500e9ff8-6379-4e16-976c-ffca6e15051a@github.com>

On Wed, 23 Oct 2024 16:02:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> lgtm

Thanks @RogerRiggs. I'm going to push this PR as-is; any further refinements can be done next time someone is updating these classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21652#issuecomment-2433088864

From darcy at openjdk.org  Wed Oct 23 18:28:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 18:28:40 GMT
Subject: Integrated: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
Message-ID: <prCJPNj-xQSSzk7VSYrQN3_jr9iP1-DWL9Im4SpgVeE=.d92e7ca1-4080-4f68-bdc2-db903be13165@github.com>

On Wed, 23 Oct 2024 02:06:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Noticed this refactoring opportunity while doing some other work in the area.

This pull request has now been integrated.

Changeset: a21c5586
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a21c558699646d44d071945c82203e2d68a4dcc3
Stats:     17 lines in 8 files changed: 0 ins; 1 del; 16 mod

8342863: Use pattern matching for instanceof in equals methods of wrapper classes

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/21652

From vklang at openjdk.org  Wed Oct 23 18:44:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 23 Oct 2024 18:44:32 GMT
Subject: [jdk23] RFR: 8342905: Thread.setContextClassloader from thread in FJP
 commonPool task no longer works after JDK-8327501 redux
Message-ID: <ajQ_02ARas5U2alcVSBntwVT1bmaFqOlyk5TiDxoP80=.8eb6a4cc-8887-415f-a23c-1555e0f1b846@github.com>

Having opted in to allow setting an SM is a clearer signal.

-------------

Commit messages:
 - Better fix for Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501

Changes: https://git.openjdk.org/jdk/pull/21668/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21668&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342905
  Stats: 7 lines in 1 file changed: 4 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21668/head:pull/21668

PR: https://git.openjdk.org/jdk/pull/21668

From bpb at openjdk.org  Wed Oct 23 18:56:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Oct 2024 18:56:10 GMT
Subject: Integrated: 8233451: (fs) Files.newInputStream() cannot be used with
 character special files
In-Reply-To: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
References: <WucLwgvugyFQQome757PSarZo1m9zgahablfVBaOJps=.5c4140a4-4fae-4870-adc0-60b569a53545@github.com>
Message-ID: <cEjhQFNTqxN3w9YXOoseCGi7-uwOxEssKdQab81yRwU=.3bf86fae-46ad-46f5-a666-ad5b6b62c26c@github.com>

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces to native code and use these in `ChannelInputStream` to work around cases where a wrapped `FileChannelImpl` is not really seekable.

This pull request has now been integrated.

Changeset: de92fe37
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de92fe375771315452fc5318abfd228fdd31c454
Stats:     413 lines in 8 files changed: 384 ins; 0 del; 29 mod

8233451: (fs) Files.newInputStream() cannot be used with character special files

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21508

From coleenp at openjdk.org  Wed Oct 23 19:18:33 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 19:18:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
Message-ID: <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>

On Wed, 23 Oct 2024 12:53:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1272:
>> 
>>> 1270: 
>>> 1271: 
>>> 1272: // Returns the inherited_access_control_context field of the running thread.
>> 
>> There's some code in this file in 
>> static void trace_class_resolution_impl(Klass* to_class, TRAPS) {
>> 
>> That does this:
>> 
>> 
>>     while (!vfst.at_end()) {
>>       Method* m = vfst.method();
>>       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
>>           !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
>>           !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
>>         break;
>>       }
>>       last_caller = m;
>>       vfst.next();
>>     }
>> 
>> 
>> Is this dead code that should be removed?
>
> This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.

but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813400810

From coleenp at openjdk.org  Wed Oct 23 19:25:17 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 19:25:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>
Message-ID: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.30bd0702-7c5b-4806-babe-fc33027928b9@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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2433252605

From honkar at openjdk.org  Wed Oct 23 19:41:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 19:41:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
Message-ID: <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>

On Mon, 21 Oct 2024 21:12:29 GMT, Phil Race <prr 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:
> 
>> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
>> 75: 
>> 76:         if (args.length > 1) {
> 
> The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?
> 
> Also the messing around with exceptions at the end of the test is pointless

@prrace I might have missed removing this check which was in the original test. The latest update to this test has two run tags but it fails when isFileCacheExpected is set to true.

Did you mean to keep only one run tag? https://github.com/openjdk/jdk-sandbox/commit/1bf77a393c5756bca65760402077617d37be72d2

I'll be rename the test as suggested when I update this test next.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813429265

From almatvee at openjdk.org  Wed Oct 23 19:46:10 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 23 Oct 2024 19:46:10 GMT
Subject: Integrated: 8341939: SigningOptionsTest fails without Xcode with
 command line developer tools after JDK-8341443
In-Reply-To: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
References: <q3VrnVpimGsqc7qVB1lCaXTyZW3zVbUIoKUIli3zg2s=.547b7981-d102-4d3d-8504-868a1e4f26a1@github.com>
Message-ID: <4Ux_F2DMODuzv60oG9cG6vJ8UIT3DEtYdSzfbvc4Tvc=.f06fcad8-f90a-4280-8122-ef1d9ec4d7b6@github.com>

On Tue, 22 Oct 2024 01:46:45 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Removed hard check for "Xcode with command line developer tools" when `--mac-sign` is specified and instead we will show information message if `codesign` fails for any reason that possible root cause of failure is missing Xcode with command line developer tools.
> - Reason for this is that `codesign` works fine on recent macOS versions and it looks like dependency on Xcode with command line developer tools is no longer required. Unfortunately it is unknown which macOS versions are require Xcode with command line developer tools in order to `codesign` work, so this check will be done as soft check.
> - SigningOptionsTest which requires "Xcode with command line developer tools" on some older macOS versions was modified to skip certain tests which might fail if Xcode is not installed.

This pull request has now been integrated.

Changeset: 9a7a850e
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a7a850e2892990cf6755a0ccb19711816ad1b51
Stats:     85 lines in 8 files changed: 51 ins; 26 del; 8 mod

8341939: SigningOptionsTest fails without Xcode with command line developer tools after JDK-8341443

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/21628

From honkar at openjdk.org  Wed Oct 23 20:20:35 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 20:20:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
 <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>
Message-ID: <vmkpLn9nL1RxwBDfE6plkj6ja6Ks2R7_V355BH4mVGQ=.8b4c1433-acd9-4180-9169-5997f934125b@github.com>

On Wed, 23 Oct 2024 19:38:10 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:
>> 
>>> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
>>> 75: 
>>> 76:         if (args.length > 1) {
>> 
>> The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?
>> 
>> Also the messing around with exceptions at the end of the test is pointless
>
> @prrace I might have missed removing this check which was in the original test. The latest update to this test has two run tags but it fails when isFileCacheExpected is set to true.
> 
> Did you mean to keep only one run tag? https://github.com/openjdk/jdk-sandbox/commit/1bf77a393c5756bca65760402077617d37be72d2
> 
> I'll be rename the test as suggested when I update this test next.

No changes required for this test. The test was failing due to IDE config issue of tmp dir.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813474346

From pchilanomate at openjdk.org  Wed Oct 23 20:22:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:22:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
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: <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@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:

  Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/e232b7f3..baf7ffab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=05-06

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 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 darcy at openjdk.org  Wed Oct 23 20:26:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 20:26:09 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v7]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <N32DKZcdfqs12zm9cX_eLD-O5l_4mnvuc1ZcVie0jl0=.1fbf7799-85fc-41ff-ae2f-5abd61f145b6@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 12 additional commits since the last revision:

 - Add tests, improve hashing spec.
 - Merge branch 'master' into JDK-8341260
 - Add equals/hashCode implementation; tests to follow.
 - Respond to review feedback.
 - Respond to review feedback.
 - Add @since tag, respond to review feedback.
 - Merge branch 'master' into JDK-8341260
 - Remove comments for intrinsics per review feedback.
 - Update with changes from lworld+fp16 Float16.
 - Merge branch 'master' into JDK-8341260
 - ... and 2 more: https://git.openjdk.org/jdk/compare/fe134ef4...ea7a72fa

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/be72e76e..ea7a72fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=05-06

  Stats: 91884 lines in 153 files changed: 87918 ins; 3576 del; 390 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 pchilanomate at openjdk.org  Wed Oct 23 20:47:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
 <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@github.com>
Message-ID: <gGm48Cxs1mgNeICqJxSkVYxDdT4gGogR9QP6rIcrDVQ=.093b0c5a-ffbe-44b0-b75b-d480321490b1@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 pchilanomate at openjdk.org  Wed Oct 23 20:47:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
 <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@github.com>
Message-ID: <793XB62tkVT9w5ix7Ie1Hhxse4WnmnA7baNi__fs0Dw=.849e94b4-6aa7-4035-9304-525109dbba4c@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 pchilanomate at openjdk.org  Wed Oct 23 20:47:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
Message-ID: <1fIoKFEkaZWw0x3eG4cdDbHX_RVga-A6ovBsZnwVgbk=.bc2d26c6-c9a2-4ebe-9e95-9bf9733b947c@github.com>

On Wed, 23 Oct 2024 00:19:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> 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/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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813516395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813519648

From pchilanomate at openjdk.org  Wed Oct 23 20:47:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
Message-ID: <FmKOCSsujrPLhOUfXlnZeAeUrWiLQLMmseBgvHuWrsA=.fcdb55a8-3bde-407a-a26f-b8515ab7407a@github.com>

On Tue, 22 Oct 2024 15:50:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> 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 pchilanomate at openjdk.org  Wed Oct 23 20:47:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
Message-ID: <C-L8sN_XwQ1SS3e4G6zpF26t_3yG-xHVrrISzYKBqMs=.2b4870e8-f12b-47b8-9ba8-fe3281ecefcb@github.com>

On Wed, 23 Oct 2024 05:42:34 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:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813525449

From pchilanomate at openjdk.org  Wed Oct 23 20:47:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
Message-ID: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@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 pchilanomate at openjdk.org  Wed Oct 23 20:47:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
Message-ID: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@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 darcy at openjdk.org  Wed Oct 23 21:07:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 21:07:21 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v8]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <yJyukxdwQVcDLjnUgM0Fy1oVSUQ5OInCAN8C_fAJcnY=.8cb878be-f637-413b-a377-59f6fc5a75a0@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:

  Improve specification per code review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/ea7a72fa..96c05b5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=06-07

  Stats: 19 lines in 1 file changed: 18 ins; 0 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  Wed Oct 23 21:07:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 21:07:21 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v6]
In-Reply-To: <-YmH55zDMO2AcS9t0Z5lqxFgkvtrdeiefUri-x369CI=.d07ef844-07f2-4894-8864-c553b0da6c8c@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <YunqU93pLU7MWJsWy7rePhvNMwq-RB4bZtcNeujF8vI=.1ad51846-be02-472c-8c19-7d52a3a92b48@github.com>
 <-YmH55zDMO2AcS9t0Z5lqxFgkvtrdeiefUri-x369CI=.d07ef844-07f2-4894-8864-c553b0da6c8c@github.com>
Message-ID: <uohEUsu8F3lIE2ju-l1L3FetwnMaQiXc7Xc5ezjZ5SE=.eed2a40c-9fe4-4ba3-b6f7-1d154fc376a1@github.com>

On Wed, 23 Oct 2024 00:53:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add equals/hashCode implementation; tests to follow.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 60:
> 
>> 58:  * either {@link Float}/{@link Double} or {@link Math}/{@link
>> 59:  * StrictMath}. Unless otherwise specified, the handling of special
>> 60:  * floating-point values such as {@linkplain #isNaN(Float16) NaN}
> 
> That said, and given Float has "equivalenceRelation" and "decimalToBinaryConversion" anchors, do we need similar anchors here that redirects to the Double ones?

Reasonable suggestion; I'll put the same kind of pointers into java.lang.Double sections as java.lang.Float has.

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 405:
> 
>> 403:      * @return the {@code Float16} value represented by the string
>> 404:      *         argument.
>> 405:      * @throws NullPointerException  if the string is null
> 
> Should we move this NPE clause to the class specification, i.e. `Unless otherwise specified, all methods in this class throw {@code NullPointerException} when passed a {@code null}`? I think this applies to the APIs taking `BigDecimal` and static methods taking `Float16`. (Note we need to explicitly exclude `equals`)

Hmm. I'm trying to keep parity between Float16 and java.lang.{Float, Double}. Float/Double don't include the class-level statement so I wouldn't include on in Float16 until they do. Writing Float16 has prompted several other improvements to Float/Double, so a null-handling statement is something worth considering.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813577592
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813570930

From naoto at openjdk.org  Wed Oct 23 21:40:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 23 Oct 2024 21:40:06 GMT
Subject: RFR: 8340554: Improve MessageFormat readObject checks [v2]
In-Reply-To: <B6ZSy_Z5YC4sCTUm5CiwA6t7dWil93bGB4dsR47ctd8=.382b49d9-23a4-4a4f-8fd9-6916cbb9eb7d@github.com>
References: <0hSlYistdp3kSZMl2Frm65PSONFmtwpkx0EcJb_x1-E=.8f597ec0-df3c-499b-a555-92ede1bb1cfb@github.com>
 <B6ZSy_Z5YC4sCTUm5CiwA6t7dWil93bGB4dsR47ctd8=.382b49d9-23a4-4a4f-8fd9-6916cbb9eb7d@github.com>
Message-ID: <vLLPVTUL4d-pknJdAIu6HnZjtei1TE0Ff4vyIveWe1w=.915f13b0-9108-4cea-bf8c-37be3c2b5aa3@github.com>

On Fri, 18 Oct 2024 19:39:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves the readObject logic for _j.text.MessageFormat_.
>> 
>> No offset should be larger than the pattern length. We already ensure the offsets when consumed backwards are equal/descending. The existing first/initial check was off by 1 since it was checking against the pattern length + 1; (see L2040 and L2043).
>> 
>> Please see the JBS issue for further info and other test details.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: clarify test comments

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21570#pullrequestreview-2390700285

From mullan at openjdk.org  Wed Oct 23 21:57:34 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 23 Oct 2024 21:57:34 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
Message-ID: <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>

On Wed, 23 Oct 2024 12:14:24 GMT, Alan Bateman <alanb 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:
> 
>> 239:         Properties props = System.getProperties();
>> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
>> 241:         System.setSecurityManager(new SecurityMan());
> 
> I assume SecurityMan should be removed too.

Yes, and the comments that say "no SM" should be updated. @RogerRiggs can you take a look at this? Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813724467

From duke at openjdk.org  Wed Oct 23 22:19:15 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Wed, 23 Oct 2024 22:19:15 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <ljCruquhKjftFURuiiphQM4qBL-m2lEsUcjZgZ4VGHI=.058a2479-ee90-4c1f-a00d-a1e55e7831a3@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

An issue with the simple name `of` is that we may encounter calls like this:

`Reader.of("/usr/share/dict/words")`

... that may look like they do something different. I can't say whether we should consider this a serious issue or not, though. I don't know if it justifies a big ugly name like `ofCharSequence` or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2433568127

From jiangli at openjdk.org  Wed Oct 23 22:19:21 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 23 Oct 2024 22:19:21 GMT
Subject: RFR: 8342642: Class loading failure due to archived map issue in
 ModuleLoaderMap.Mapper
Message-ID: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>

Please review the fix that uses String type for the mapped value in ModuleLoaderMap.Mapper map (Map<String, String>). Please see details in https://bugs.openjdk.org/browse/JDK-8342642, thanks.

-------------

Commit messages:
 - Use String instances as the loader indexes in ModuleLoaderMap.Mapper map.

Changes: https://git.openjdk.org/jdk/pull/21672/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21672&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342642
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21672.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21672/head:pull/21672

PR: https://git.openjdk.org/jdk/pull/21672

From mullan at openjdk.org  Wed Oct 23 22:21:35 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 23 Oct 2024 22:21:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <-WUk0E4MRJ1CB84NKT6g7L3pmv-IFpgTnJsrjsjSavA=.53352f0c-6c82-4a45-86c8-b3468c842d9e@github.com>

On Tue, 22 Oct 2024 21:36:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.

Thanks for the comprehensive review. I have incorporated all of your comments except for removing the enum from `java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java` which is a bit more involved. I plan on posting an updated PR with these and other changes tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433572062

From bpb at openjdk.org  Wed Oct 23 22:58:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Oct 2024 22:58:28 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices
Message-ID: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>

Modify `FileInputStream` (FIS) to fall back to the superclass implementations of `readAllBytes()`, `readNBytes(int)`, `skip()`, and `transferTo` when the input source would otherwise fail with "Illegal Seek" in the FIS implementation, such as for the standard input or a named pipe.

-------------

Commit messages:
 - 8341666: FileInputStream doesn't support readAllBytes() or readNBytes(int) on pseudo devices

Changes: https://git.openjdk.org/jdk/pull/21673/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21673&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341666
  Stats: 262 lines in 7 files changed: 257 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21673/head:pull/21673

PR: https://git.openjdk.org/jdk/pull/21673

From dl at openjdk.org  Wed Oct 23 22:58:22 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 23 Oct 2024 22:58:22 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v4]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <Jga-82tT91Q974kadpd_U_nr33GQtKvgmdPd0ckSC5Y=.5fa9850f-b767-486a-8103-cbce9a63d26e@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:

  For starvation check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/0bf0bfa0..dcbfc1f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=02-03

  Stats: 15 lines in 1 file changed: 2 ins; 0 del; 13 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  Wed Oct 23 23:47:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 23 Oct 2024 23:47:16 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <CZT-NKCHUQ1m7qS3AKNP4IqRWjkZGoRvH6DI3v1JReo=.d5a011f6-3347-43aa-bd40-adfb29ccffeb@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

I think this scenario has a close analogy with java.util.Scanner constructors. Does such a fault happen to Scanner often?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2433790822

From darcy at openjdk.org  Wed Oct 23 23:59:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 23 Oct 2024 23:59:04 GMT
Subject: RFR: 8342865: Use type parameter for Class::getPrimitiveClass
In-Reply-To: <ZFNgOt0pnCOr-DkBOH56m8Aq5gaotUEpKnaXW7xAAqk=.cbe53786-955e-4f17-90ed-3204d03704a0@github.com>
References: <ZFNgOt0pnCOr-DkBOH56m8Aq5gaotUEpKnaXW7xAAqk=.cbe53786-955e-4f17-90ed-3204d03704a0@github.com>
Message-ID: <YCMq5WlTo4Qtnzca8nfqy2ALnWFDgMNWe6_7RhdFw48=.37290afc-881f-4859-94b8-99e7d31c6928@github.com>

On Wed, 23 Oct 2024 03:06:39 GMT, Chen Liang <liach at openjdk.org> wrote:

> Discovered this small cleanup while looking at wrapper class code.

src/java.base/share/classes/java/lang/Class.java line 3284:

> 3282:      * primitive type.
> 3283:      */
> 3284:     static native <T> Class<T> getPrimitiveClass(String name);

I checked the code in java.base and this method is only called by the wrapper classes (and void), as expected.

I think the refactoring is good, but would like to see a comment here along the lines of "Use of type variable is acceptable since only used within java.lang," etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21653#discussion_r1813996652

From henryjen at openjdk.org  Thu Oct 24 00:10:13 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 24 Oct 2024 00:10:13 GMT
Subject: Integrated: 8335912: Add an operation mode to the jar command when
 extracting to not overwriting existing files
In-Reply-To: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
References: <ifSTSAUl4gGHkznyD-vJA9N5w26ROKxmMXtYNTUx65s=.b0110bea-d58b-4520-821a-27d4317ebc1c@github.com>
Message-ID: <a9UceRc3sUTxT8BHq19E9XdR6UA3KYC3Cbu0-uTPRQQ=.d7ed7113-7ad2-44e3-b8ac-3ffe85ebd312@github.com>

On Mon, 23 Sep 2024 17:32:10 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> This PR support a -k, --keep options like tar that allows jar to avoid override existing files.

This pull request has now been integrated.

Changeset: 158b93d1
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/158b93d19a518d2b9d3d185e2d4c4dbff9c82aab
Stats:     527 lines in 5 files changed: 525 ins; 0 del; 2 mod

8335912: Add an operation mode to the jar command when extracting to not overwriting existing files

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/21141

From liach at openjdk.org  Thu Oct 24 02:40:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 02:40:07 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v8]
In-Reply-To: <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>
Message-ID: <LL6Ns8bpohckNoR8O1zkXJC3tO2Uu_rOIrDkObqQ-Y8=.281c7831-3dc5-4836-88a5-1de3fb0fde51@github.com>

On Wed, 23 Oct 2024 06:14:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix displayName
>   
>   Turns out ArrayClassDesc::displayName was incorrect. Added a test.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20665#issuecomment-2434116665

From liach at openjdk.org  Thu Oct 24 02:43:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 02:43:12 GMT
Subject: Integrated: 8338544: Dedicated Array class descriptor implementation
In-Reply-To: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
Message-ID: <t7sSYPgBXtIv9F79r7GCE4SLrundUsT24OFM2rqhxYQ=.eac55767-b6e3-46cc-809a-aa55f54e93de@github.com>

On Wed, 21 Aug 2024 20:25:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
> 
> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.

This pull request has now been integrated.

Changeset: 25c2f48d
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25c2f48d458bfd92423c311a887679ad3e1e4041
Stats:     873 lines in 20 files changed: 476 ins; 255 del; 142 mod

8338544: Dedicated Array class descriptor implementation

Reviewed-by: redestad, mchung, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/20665

From iklam at openjdk.org  Thu Oct 24 03:01:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 24 Oct 2024 03:01:54 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@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 two additional commits since the last revision:

 - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
 - disable test that fails with hotspot_runtime_non_cds_mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21642/files
  - new: https://git.openjdk.org/jdk/pull/21642/files/1b6c3e28..dd59b5f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=02-03

  Stats: 103 lines in 4 files changed: 100 ins; 0 del; 3 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  Thu Oct 24 03:14:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 03:14:47 GMT
Subject: RFR: 8342865: Use type parameter for Class::getPrimitiveClass [v2]
In-Reply-To: <ZFNgOt0pnCOr-DkBOH56m8Aq5gaotUEpKnaXW7xAAqk=.cbe53786-955e-4f17-90ed-3204d03704a0@github.com>
References: <ZFNgOt0pnCOr-DkBOH56m8Aq5gaotUEpKnaXW7xAAqk=.cbe53786-955e-4f17-90ed-3204d03704a0@github.com>
Message-ID: <nQ9apozTP1UoSvT7lxc4vkQfTvwCPkVXnEjf9_PkC4w=.e087ec69-4765-4c8d-bdba-87dd6106f8a2@github.com>

> Discovered this small cleanup while looking at wrapper class code.

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 four additional commits since the last revision:

 - Comment about the type parameter
 - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/class-getprimitiveclass
 - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/class-getprimitiveclass
 - 8342865: Use type parameter for Class::getPrimitiveClass

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21653/files
  - new: https://git.openjdk.org/jdk/pull/21653/files/d21ae621..854e224e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21653&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21653&range=00-01

  Stats: 2715 lines in 103 files changed: 1783 ins; 466 del; 466 mod
  Patch: https://git.openjdk.org/jdk/pull/21653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21653/head:pull/21653

PR: https://git.openjdk.org/jdk/pull/21653

From liach at openjdk.org  Thu Oct 24 03:14:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 03:14:47 GMT
Subject: RFR: 8342865: Use type parameter for Class::getPrimitiveClass [v2]
In-Reply-To: <YCMq5WlTo4Qtnzca8nfqy2ALnWFDgMNWe6_7RhdFw48=.37290afc-881f-4859-94b8-99e7d31c6928@github.com>
References: <ZFNgOt0pnCOr-DkBOH56m8Aq5gaotUEpKnaXW7xAAqk=.cbe53786-955e-4f17-90ed-3204d03704a0@github.com>
 <YCMq5WlTo4Qtnzca8nfqy2ALnWFDgMNWe6_7RhdFw48=.37290afc-881f-4859-94b8-99e7d31c6928@github.com>
Message-ID: <EHx6DdOt1FcKovG9Q1F_Udrlf04E6OrglWU4WjfwP14=.85cf9dc8-06c2-4ceb-ba4a-a04014a323bd@github.com>

On Wed, 23 Oct 2024 23:56:33 GMT, Joe Darcy <darcy 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 four additional commits since the last revision:
>> 
>>  - Comment about the type parameter
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/class-getprimitiveclass
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/class-getprimitiveclass
>>  - 8342865: Use type parameter for Class::getPrimitiveClass
>
> src/java.base/share/classes/java/lang/Class.java line 3284:
> 
>> 3282:      * primitive type.
>> 3283:      */
>> 3284:     static native <T> Class<T> getPrimitiveClass(String name);
> 
> I checked the code in java.base and this method is only called by the wrapper classes (and void), as expected.
> 
> I think the refactoring is good, but would like to see a comment here along the lines of "Use of type variable is acceptable since only used within java.lang," etc.

Done. I added a comment "Type parameter T avoids redundant casts for trusted code." and removed "Virtual Machine's" as all Class objects are created by the JVM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21653#discussion_r1814177633

From darcy at openjdk.org  Thu Oct 24 03:25:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 24 Oct 2024 03:25:07 GMT
Subject: RFR: 8342865: Use type parameter for Class::getPrimitiveClass [v2]
In-Reply-To: <nQ9apozTP1UoSvT7lxc4vkQfTvwCPkVXnEjf9_PkC4w=.e087ec69-4765-4c8d-bdba-87dd6106f8a2@github.com>
References: <ZFNgOt0pnCOr-DkBOH56m8Aq5gaotUEpKnaXW7xAAqk=.cbe53786-955e-4f17-90ed-3204d03704a0@github.com>
 <nQ9apozTP1UoSvT7lxc4vkQfTvwCPkVXnEjf9_PkC4w=.e087ec69-4765-4c8d-bdba-87dd6106f8a2@github.com>
Message-ID: <-BPD4ieHCw8j-iRslMqya-dtUaHRdQ__cCvpdD5MwUE=.30cbf003-8b65-4589-94f9-25d96b8eb5a8@github.com>

On Thu, 24 Oct 2024 03:14:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Discovered this small cleanup while looking at wrapper class code.
>
> 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 four additional commits since the last revision:
> 
>  - Comment about the type parameter
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/class-getprimitiveclass
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/class-getprimitiveclass
>  - 8342865: Use type parameter for Class::getPrimitiveClass

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21653#pullrequestreview-2391129627

From jwaters at openjdk.org  Thu Oct 24 03:36:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Oct 2024 03:36:04 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <6bgDWzW7hPhgXiKPtf691dw78Fywzz7xpNfI7AixFsM=.ebc2cc90-ebc1-4187-ae38-3f0979a97dc9@github.com>

On Mon, 21 Oct 2024 14:34:30 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

Thanks Weijun for the ok on security (Though it still makes me uneasy because it smells like a bug, but I guess it's alright). I haven't pushed yet to remove the changes to the other files in this Pull Request because the way I did it I'd have to force push and that would destroy all the review comments, I'll do that once the comments have been fully addressed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2434176106

From jwaters at openjdk.org  Thu Oct 24 03:36:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Oct 2024 03:36:05 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <PVYkac0hz2kZm06cfLm0wmoScou2H1ALnkUMLcGAW3s=.7ef6e0df-8950-4aa5-bb8f-bf1a33830221@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
 <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
 <PVYkac0hz2kZm06cfLm0wmoScou2H1ALnkUMLcGAW3s=.7ef6e0df-8950-4aa5-bb8f-bf1a33830221@github.com>
Message-ID: <TtWY-ZqfMHIKg1LuPv0g5QiOA72gspX4swBV7x_mYaQ=.10226be1-eeff-4515-a01e-029d8ca1d861@github.com>

On Wed, 23 Oct 2024 16:51:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I wasn't sure whether the global memHandle not being used was a bug, so I commented out the local one. I missed the line 88 one because it wasn't flagged. If it really isn't needed I'll remove that one instead
>
> I'm not sure what you mean by "that one". It's the static one that should be removed. The local variables always hide the static, and there seems to be no reason for the value of memHandle to survive outside of the local scope it is used in.

Oh, I was referring to the static global one. In that case I'll remove it (Or rather, comment it so it isn't lost to time and someone can bring it back if need be)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1814187989

From pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
 <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@github.com>
Message-ID: <Q4NNfZ8Vuzy9966oDBrXA3pf4818J5MEL13_l_KLmzQ=.e1697634-4105-4bee-8d20-0a375fd190e8@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 pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
 <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>
Message-ID: <uhUjIm6NwTlveCt80zVVVMHSs2D2aVRo0oGpZfuiKyk=.6f63f256-5046-43ff-b2e1-49fd7602fffd@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 pchilanomate at openjdk.org  Thu Oct 24 03:38:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
Message-ID: <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>

On Wed, 23 Oct 2024 05:43:53 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:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> 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 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187730
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187856

From pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
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: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@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 comment in objectMonitor.hpp and javaThread.hpp
 - Skip printing tid when not available

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/baf7ffab..03ba6dfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=06-07

  Stats: 23 lines in 4 files changed: 17 ins; 0 del; 6 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 alanb at openjdk.org  Thu Oct 24 05:08:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 05:08:05 GMT
Subject: RFR: 8342642: Class loading failure due to archived map issue in
 ModuleLoaderMap.Mapper
In-Reply-To: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
References: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
Message-ID: <Uy7sY_UaGyqS8dliTx1fbvEy_4_HuEDVgb2ZiirMIbw=.afbc0f19-1431-47a6-aec7-b71d1c686773@github.com>

On Wed, 23 Oct 2024 22:14:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix that uses String type for the mapped value in ModuleLoaderMap.Mapper map (Map<String, String>). Please see details in https://bugs.openjdk.org/browse/JDK-8342642, thanks.

@iklam Would it be possible to comment on this?  If the system properties to configure the range of integer cache are set at runtime, does it just not use this archived object graph? I'm wondering if it should disable CDS?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21672#issuecomment-2434308744

From forax at openjdk.org  Thu Oct 24 05:44:11 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 24 Oct 2024 05:44:11 GMT
Subject: RFR: 8342863: Use pattern matching for instanceof in equals
 methods of wrapper classes
In-Reply-To: <mZcfjAQQlO2vS_30HXc0eu-YfbF_A3Emz1cBOpfZIoM=.66f759ff-8782-46e2-9ab8-af1dbf246cfa@github.com>
References: <SFkvQ6GDjPbEZfSIBRFBwAesQtoWOfex6fwmMVC-rPE=.b068bcfb-0a7f-4e21-8408-d2b443f1ce76@github.com>
 <rK9UXp5kMwblo1tpxpBQliPOipXXlIUo5WQaGywY4QQ=.54a3b925-9850-4364-8bf8-1efddab1583b@github.com>
 <mZcfjAQQlO2vS_30HXc0eu-YfbF_A3Emz1cBOpfZIoM=.66f759ff-8782-46e2-9ab8-af1dbf246cfa@github.com>
Message-ID: <W_QnlqNrtYoO42szzMf2JtbUOy6M154QWHHi5ypXIWw=.c9be061d-4eb5-4e89-8849-be669bc614cc@github.com>

On Wed, 23 Oct 2024 15:36:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Boolean.java line 259:
>> 
>>> 257:     public boolean equals(Object obj) {
>>> 258:         if (obj instanceof Boolean b) {
>>> 259:             return value == b.booleanValue();
>> 
>> I would go even a step further and use `value` instead of `booleanValue()`, `intValue()` etc because there is no need to call a method to get the value.
>> 
>> 
>>   if (obj instanceof Boolean b) {
>>             return value == b.value;
>
> Hi @forax,
> Yes, I had considered that before sending out the PR. It shouldn't matter from a performance perspective, so it would come to down to which version of the code was marginally easier to read.

Ah, too slow to answer ...
Anyway, the wrapper types tend to be used everywhere so there are also used in methods that are executed only a few times so only by the interpreter, in those case, accessing directly to the field is a win.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21652#discussion_r1814295461

From jrose at openjdk.org  Thu Oct 24 05:46:08 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 24 Oct 2024 05:46:08 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <6ESSOT5cMkoM_k1L32iXOAeYNLpjmeOlKPWZvYOVcc8=.c16e28d3-faee-444e-a37c-addc8e07bb54@github.com>

On Thu, 24 Oct 2024 03:01:54 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 two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

I took a closer look at the diffs in a file you renamed, from `classPrelinker.cpp` to `aotConstantPoolResolver.cpp`.  Changes still look good, notably the filtering logic on the bootstrap methods (and their arguments) that we support.

For the record, the diff I made for review is enclosed.  It makes the new indy-related logic stand out pretty well.

[classPrelinker.deleted.cpp.txt](https://github.com/user-attachments/files/17501832/classPrelinker.deleted.cpp.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2434351458

From iklam at openjdk.org  Thu Oct 24 05:54:03 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 24 Oct 2024 05:54:03 GMT
Subject: RFR: 8342642: Class loading failure due to archived map issue in
 ModuleLoaderMap.Mapper
In-Reply-To: <Uy7sY_UaGyqS8dliTx1fbvEy_4_HuEDVgb2ZiirMIbw=.afbc0f19-1431-47a6-aec7-b71d1c686773@github.com>
References: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
 <Uy7sY_UaGyqS8dliTx1fbvEy_4_HuEDVgb2ZiirMIbw=.afbc0f19-1431-47a6-aec7-b71d1c686773@github.com>
Message-ID: <uQOrLdzHHGFc7GGCBl1XGucRfBFgrgCsUKl6e429Pi4=.c6939582-9d0c-4369-a0b7-99aca94e2787@github.com>

On Thu, 24 Oct 2024 05:05:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @iklam Would it be possible to comment on this? If the system properties to configure the range of integer cache are set at runtime, does it just not use this archived object graph? I'm wondering if it should disable CDS?

A better fix would be:

If runtime java.lang.Integer.IntegerCache.high < dumptime java.lang.Integer.IntegerCache.high
  -- copy the initial elements from the dumptime cache array
  -- fill the rest of the cache array

that way, we will still preserve the object identity of the Integers created during dump time.

I think we need to do the same thing for the other box cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21672#issuecomment-2434359711

From dholmes at openjdk.org  Thu Oct 24 05:58:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>

On Thu, 24 Oct 2024 03:38:21 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:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

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/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/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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814306675
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814260043
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814294622

From dholmes at openjdk.org  Thu Oct 24 05:58:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
Message-ID: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>

On Wed, 23 Oct 2024 20:22:26 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:
> 
>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv

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/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.

-------------

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_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 dholmes at openjdk.org  Thu Oct 24 05:58:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
Message-ID: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@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  Thu Oct 24 05:58:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
Message-ID: <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>

On Wed, 23 Oct 2024 17:32:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283

From jrose at openjdk.org  Thu Oct 24 06:17:10 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 24 Oct 2024 06:17:10 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <ZlzUKcGyjkJXpZ6IbaVy90ZnxVjFkEi0a-Uf0fLVov4=.c06e3163-4cdb-46f1-9499-a28a9fcef54c@github.com>

On Thu, 24 Oct 2024 03:01:54 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 two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

A thought for a possible cleanup, after this PR is done?

The scratch mirror logic had me? scratching my head.  It seems to me that a more descriptive name would make the code explain itself better.  I suggest (for a future cleanup) calling a mirror structure which is being aot-assembled (just for the archive) a "future mirror" (or maybe "production mirror" or "mirror asset").  This is in distinction to the current "live" mirror, which is also the AOT phase mirror.  In general, from the point of view of the assembly phase, when we build new structures not created by the JVM as a result of post-training Java execution, we might want to give them a common descriptive term.  But I suppose most items that make it into the AOT cache are faithful copies of live data, present in the VM at dump time (end of assembly phase).  In that case, it's more like "the same structure" in all cases, and there's no need to simultaneously work on both present and future versions of the same structure.

(When I say "structure" I mean mirror object for now, but perhaps the pattern might expand to something else?  Or, maybe we will get rid of the two-mirror solution, in which case every future structure is also completely present and live in the assembly-phase VM.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2434387290

From dholmes at openjdk.org  Thu Oct 24 06:21:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 06:21:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
 <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
Message-ID: <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>

On Thu, 24 Oct 2024 03:31:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814330162

From epeter at openjdk.org  Thu Oct 24 06:23:17 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:23:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
Message-ID: <TGwYvzGK2pFFJer7EghvuyiyKYvc8VGYb5vVmboyF04=.6566f83b-fca3-46d1-a973-a3d94f9366c6@github.com>

On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Factor out IR tests and Transforms to follow-up PRs.

src/hotspot/cpu/x86/x86.ad line 10725:

> 10723: %}
> 10724: 
> 10725: instruct vector_saturating_subword_mem(vec dst, vec src1, memory src2)

Nit: above you always have `add` and `sub` in the name and the `format`. I and here and in some cases below not. Would be nice if it was consistent - would also make reading the OptoAssembly easier if one knows if it is an add or sub ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814331929

From epeter at openjdk.org  Thu Oct 24 06:34:14 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:34:14 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
Message-ID: <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>

On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Factor out IR tests and Transforms to follow-up PRs.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 32:

> 30:  * @since   24
> 31:  */
> 32: public final class VectorMath {

I think this class could have been split into a separate RFE, together with its tests. I would prefer that next time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814340685

From epeter at openjdk.org  Thu Oct 24 06:34:14 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:34:14 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
Message-ID: <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>

On Thu, 24 Oct 2024 06:28:31 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Factor out IR tests and Transforms to follow-up PRs.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 32:
> 
>> 30:  * @since   24
>> 31:  */
>> 32: public final class VectorMath {
> 
> I think this class could have been split into a separate RFE, together with its tests. I would prefer that next time.

Also: why did we not add these `Long.minUnsigned` etc? I guess that was already discussed?
Because we can easily also use this with the auto-vectorizer or more generally. Saturating and unsigned ops are generally useful I think...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814343654

From jlahoda at openjdk.org  Thu Oct 24 06:40:42 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 24 Oct 2024 06:40:42 GMT
Subject: RFR: 8335989: Implement Module Import Declarations (Second
 Preview) [v4]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <cbPC1jKVJqB_Map7knWpKFf7vDG_0kRuXeOh8x4tB74=.520c8a28-9bd9-41ec-847d-90c638fc7b5b@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 18 commits:

 - Updating PreviewFeature metadata
 - Cleanup.
 - Merge branch 'master' into JDK-8335989
 - Merge branch 'master' into JDK-8335989
 - Reflecting review feedback.
 - Cleanup.
 - Cleanup.
 - Fixing tests
 - Adding a separate scope for module imports.
 - Cleanup.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/964d8d22...94b8bf6d

-------------

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=03
  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 cjplummer at openjdk.org  Thu Oct 24 06:56:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 24 Oct 2024 06:56:10 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <TtWY-ZqfMHIKg1LuPv0g5QiOA72gspX4swBV7x_mYaQ=.10226be1-eeff-4515-a01e-029d8ca1d861@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
 <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
 <PVYkac0hz2kZm06cfLm0wmoScou2H1ALnkUMLcGAW3s=.7ef6e0df-8950-4aa5-bb8f-bf1a33830221@github.com>
 <TtWY-ZqfMHIKg1LuPv0g5QiOA72gspX4swBV7x_mYaQ=.10226be1-eeff-4515-a01e-029d8ca1d861@github.com>
Message-ID: <whkGf16yIybHQHqDk0yqh_VxNdOn2hgHoaGm6IIXYqY=.a1448788-f01e-4309-af4c-0116d990a43f@github.com>

On Thu, 24 Oct 2024 03:31:31 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I'm not sure what you mean by "that one". It's the static one that should be removed. The local variables always hide the static, and there seems to be no reason for the value of memHandle to survive outside of the local scope it is used in.
>
> Oh, I was referring to the static global one. In that case I'll remove it (Or rather, comment it so it isn't lost to time and someone can bring it back if need be)

I would just remove the static. I don't see any reason for it to exist.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1814375764

From epeter at openjdk.org  Thu Oct 24 06:58:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:58:18 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
Message-ID: <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>

On Mon, 21 Oct 2024 12:25:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Factor out IR tests and Transforms to follow-up PRs.

Ok, now it looks better.

I would still have preferred the `VectorMath` class with its test to be in a separate PR. Please do that next time.

I have a few more questions / comments, but we are really close now.
I'm especially worried about only testing a few constant values - we should try to go for better coverage - of all values if possible.

src/hotspot/cpu/x86/x86.ad line 10790:

> 10788:   predicate(is_subword_type(Matcher::vector_element_basic_type(n)) &&
> 10789:             n->is_SaturatingVector() && !n->as_SaturatingVector()->is_unsigned());
> 10790:   match(Set dst (SaturatingAddV (Binary dst (LoadVector src)) mask));

Do equivalent store operations exist we could also match for?

test/jdk/jdk/incubator/vector/VectorMathTest.java line 70:

> 68:     public static short[] INPUT_SS = {Short.MIN_VALUE,   (short)(Short.MIN_VALUE + TEN_S), ZERO_S, (short)(Short.MAX_VALUE - TEN_S), Short.MAX_VALUE};
> 69:     public static int[]   INPUT_SI = {Integer.MIN_VALUE, (Integer.MIN_VALUE + TEN_I),      ZERO_I, Integer.MAX_VALUE - TEN_I,        Integer.MAX_VALUE};
> 70:     public static long[]  INPUT_SL = {Long.MIN_VALUE,    Long.MIN_VALUE + TEN_L,           ZERO_L, Long.MAX_VALUE - TEN_L,           Long.MAX_VALUE};

Ok, now we have 4 or 5 hand-crafted examples. Is that sufficient? Some random values would be nice, then we know that at least eventually we have full coverage.

test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingBinary-Masked-op.template line 8:

> 6: 
> 7:         for (int ic = 0; ic < INVOC_COUNT; ic++) {
> 8:             for (int i = 0; i < a.length; i += SPECIES.length()) {

I think this does not check if the generated vectors are too long. We had bugs in the past where we should have created say 2-element vectors, but the backend wrongly created 4-element vectors. This is especially an issue with vectors that do direct memory access.

With a simple "counting-up" test, you will probably not catch this. It could be good to have a "counting-down" example as well. What do you think?

test/jdk/jdk/incubator/vector/templates/Unit-header.template line 1244:

> 1242:                 return fill(s * BUFFER_REPS,
> 1243:                             i -> ($type$)($Boxtype$.MIN_VALUE + 100));
> 1244:             })

Not sure I see this right. But are we only providing these 4 constants as inputs, and all values in the input arrays will be identical? If that is true: we should have some random inputs, or at least dependent on `i`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2391445047
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814366518
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814355931
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814363960
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814371488

From epeter at openjdk.org  Thu Oct 24 06:58:18 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 06:58:18 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
Message-ID: <g6VkTPXiCIZyAfGBqV-mBR9szOQj5d6Y_cAh5xrQDpY=.1119ee52-5212-4220-9afe-859782e747af@github.com>

On Thu, 24 Oct 2024 06:44:36 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Factor out IR tests and Transforms to follow-up PRs.
>
> test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingBinary-Masked-op.template line 8:
> 
>> 6: 
>> 7:         for (int ic = 0; ic < INVOC_COUNT; ic++) {
>> 8:             for (int i = 0; i < a.length; i += SPECIES.length()) {
> 
> I think this does not check if the generated vectors are too long. We had bugs in the past where we should have created say 2-element vectors, but the backend wrongly created 4-element vectors. This is especially an issue with vectors that do direct memory access.
> 
> With a simple "counting-up" test, you will probably not catch this. It could be good to have a "counting-down" example as well. What do you think?

Also: all of these cases load, and directly store again. Does that not mean all tests will probably pick the "..._mem" backend operations? Or do we actually end up testing all backend operations with the tests we have here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814368049

From alanb at openjdk.org  Thu Oct 24 07:06:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:06:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@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>
Message-ID: <oOizZPpgL6-B1EjylbMiRiLpq_PH0S5AOMxAxfAOQr0=.8f3d7234-54f2-465c-a354-a651f7528d14@github.com>

On Thu, 24 Oct 2024 02:42:35 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:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940

From dholmes at openjdk.org  Thu Oct 24 07:14:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 07:14:05 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <6bgDWzW7hPhgXiKPtf691dw78Fywzz7xpNfI7AixFsM=.ebc2cc90-ebc1-4187-ae38-3f0979a97dc9@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <6bgDWzW7hPhgXiKPtf691dw78Fywzz7xpNfI7AixFsM=.ebc2cc90-ebc1-4187-ae38-3f0979a97dc9@github.com>
Message-ID: <PAXJ4c957eITw8vYHeZk2eDQ6T60wVqOAJwpa_2I344=.1eef170c-5296-47ce-b0d3-aee9124834af@github.com>

On Thu, 24 Oct 2024 03:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> the way I did it I'd have to force push

That should not be the case. You can just anti-delta changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2434475849

From alanb at openjdk.org  Thu Oct 24 07:18:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:18:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
Message-ID: <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>

On Wed, 23 Oct 2024 19:15:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.
>
> but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.

Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1814402940

From jrose at openjdk.org  Thu Oct 24 07:19:10 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 24 Oct 2024 07:19:10 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <SdrXTg7ahkXiSffKdmpzKO9TbtgZ2_8MLEx-OAZJG8w=.96dd3105-3d00-4ad1-bf89-8b63d0753b81@github.com>

On Thu, 24 Oct 2024 03:01:54 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 two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

I read it through again.  Some stylistic issues we have discussed can be saved for later.  I didn't find any new problems, and known old problems are addressed. Ship it!

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2391527792

From rotanolexandr842 at gmail.com  Thu Oct 24 07:46:53 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 24 Oct 2024 10:46:53 +0300
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oOizZPpgL6-B1EjylbMiRiLpq_PH0S5AOMxAxfAOQr0=.8f3d7234-54f2-465c-a354-a651f7528d14@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>
 <oOizZPpgL6-B1EjylbMiRiLpq_PH0S5AOMxAxfAOQr0=.8f3d7234-54f2-465c-a354-a651f7528d14@github.com>
Message-ID: <CAL5bRt_FvQtBcE0Wjswe2rXs+08RM+ymrwjxfR831cJd_figZw@mail.gmail.com>

Hi. Just wanted to express my gratitude to everyone who has been working on
this and virtual threads as a whole. I am a big fan of this technology and
seeing largest issue go away makes me incredibly happy. Thanks for loom
team and everyone else who took part in this great innovation (instead of
turning each codebase into async/await painting competition :) )

On Thu, Oct 24, 2024, 10:06 Alan Bateman <alanb at openjdk.org> wrote:

> On Thu, 24 Oct 2024 02:42:35 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:
> >>
> >>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
> >
> > 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.
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241024/c3953c3d/attachment.htm>

From alanb at openjdk.org  Thu Oct 24 07:51:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:51:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
Message-ID: <28R_1poNvjGMa9GI5z5mmudDS_3Kvzq9vJ_0sTpDJpA=.403c90e3-b158-4ccf-9875-7af3ad872d2c@github.com>

On Thu, 24 Oct 2024 05:54:11 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:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814450822

From stefank at openjdk.org  Thu Oct 24 08:11:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 08:11:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>

On Thu, 24 Oct 2024 03:38:21 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:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

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 alanb at openjdk.org  Thu Oct 24 08:29:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 08:29:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
 <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
Message-ID: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814517084

From sspitsyn at openjdk.org  Thu Oct 24 08:42:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Oct 2024 08:42:46 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v9]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <klIYtQeQbTc3LEMLI84UB5M8uvomzlp_HqufyzNth3Q=.ecd07139-fdd6-42ee-9bb0-b5d36c9e0023@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: remove jvmti annotation for yield methods; simplify frames hiding and events posting code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/54dc2b4a..58ab0057

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=07-08

  Stats: 59 lines in 5 files changed: 5 ins; 26 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From sspitsyn at openjdk.org  Thu Oct 24 08:51:47 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Oct 2024 08:51:47 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v10]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <GpAoGQeesqKsUPGRzWOoT_z5jP0J70ETrjilg-CPnvA=.ad5ef666-4e73-48a5-9d19-4cd036114d49@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: undo minor tweaks in a couple of continuation related files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/58ab0057..5d6e5c91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=08-09

  Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From alanb at openjdk.org  Thu Oct 24 09:04:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 09:04:06 GMT
Subject: [jdk23] RFR: 8342905: Thread.setContextClassloader from thread in
 FJP commonPool task no longer works after JDK-8327501 redux
In-Reply-To: <ajQ_02ARas5U2alcVSBntwVT1bmaFqOlyk5TiDxoP80=.8eb6a4cc-8887-415f-a23c-1555e0f1b846@github.com>
References: <ajQ_02ARas5U2alcVSBntwVT1bmaFqOlyk5TiDxoP80=.8eb6a4cc-8887-415f-a23c-1555e0f1b846@github.com>
Message-ID: <_hD7llkjV2r36NnmcaSf97CeM3Flv1HICfK3kwgpais=.ebf481eb-dba1-4569-9f4d-ff00018fe8be@github.com>

On Wed, 23 Oct 2024 18:36:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Having opted in to allow setting an SM is a clearer signal.

The change looks okay but the code will be removed after JEP 486 integrates. So better to re-base for jdk23u, even though this business of setting a SM mid-flight is (and always has been) unpredictable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21668#issuecomment-2434700070

From alanb at openjdk.org  Thu Oct 24 09:22:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 09:22:14 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v10]
In-Reply-To: <GpAoGQeesqKsUPGRzWOoT_z5jP0J70ETrjilg-CPnvA=.ad5ef666-4e73-48a5-9d19-4cd036114d49@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <GpAoGQeesqKsUPGRzWOoT_z5jP0J70ETrjilg-CPnvA=.ad5ef666-4e73-48a5-9d19-4cd036114d49@github.com>
Message-ID: <o3TsdTdUZMQ3IR05uoaRp8APe9E7cKWRl2NoTk91tZg=.ea1c4284-7095-4d9e-ace4-c3748579d015@github.com>

On Thu, 24 Oct 2024 08:51:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: undo minor tweaks in a couple of continuation related files

Latest update to JvmtiMountTransition looks okay. I assume wait until Alex Menkov and Leonid are finished their reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2434743507

From azvegint at openjdk.org  Thu Oct 24 09:56:37 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 24 Oct 2024 09:56:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <HoUuHVqcGME8iweQAWbnP6igoSGpoRtK7oX32sXi7fk=.a7ec909b-aa58-477f-bf1a-a9244a49df12@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

java beans changes looks good

-------------

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2391943640

From jpai at openjdk.org  Thu Oct 24 10:13:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 10:13:07 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v5]
In-Reply-To: <1lAqvR59LNaK3sSbf-ZeXgHav93nP9EVQnmu3wG0P1Q=.85613333-5df5-4d54-bf07-463c85d1a624@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <1lAqvR59LNaK3sSbf-ZeXgHav93nP9EVQnmu3wG0P1Q=.85613333-5df5-4d54-bf07-463c85d1a624@github.com>
Message-ID: <bCa_dSlhLoNTigAiaVIbLyRQ1XKMNLzZizjZ3ULVfSw=.17a40eb7-4c30-4e78-a0d2-f1e63e8ed591@github.com>

On Tue, 22 Oct 2024 11:06:44 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>
>>     a ":"-separated list of directories and JAR archives to search for class files
>>   --module-path <module path>
>>     a ":"-separated list of directories and JAR archives to search for modules
>> 
>> 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:
> 
>   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".

Hello Jan, the updated changes look good to me. 

The copyright year on the template file will need an update. I've one trivial question about the code which I've added inline.

src/java.base/share/native/libjli/java.c line 546:

> 544: 
> 545:     /* If the user specified neither a class name nor a JAR file */
> 546:     if (printUsageKind != HELP_NONE) {

Is the state check for `what` and `mode` no longer needed here?

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21411#pullrequestreview-2391994094
PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1814692281

From ihse at openjdk.org  Thu Oct 24 10:27:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 24 Oct 2024 10:27:07 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <HzglriUa-aM_fagDfIFtWwtdx0DvSTbfgi1MgbkKvFQ=.d0809b64-2b53-4c12-9664-c52097e49625@github.com>

On Tue, 15 Oct 2024 20:22:52 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:
> 
>   Don't hardcode server variant

Just to clarify, the problem:

chmod: /Users/erik/dev/jdk/build/macosx-aarch64/jdk/lib/server/libjsig.dylib: No such file or directory

mentioned in https://github.com/openjdk/jdk/pull/20837#issuecomment-2327132241 is a separate issue, fixed by  [JDK-8342858](https://bugs.openjdk.org/browse/JDK-8342858).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2434888627

From jpai at openjdk.org  Thu Oct 24 11:32:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 11:32:04 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices
In-Reply-To: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
Message-ID: <NGyEj0JwRNPj9hi0eFdOYX2KHlPA2b_642BsBcBlYXE=.5040051a-574c-4c98-8b33-c64a728e2714@github.com>

On Wed, 23 Oct 2024 22:52:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `FileInputStream` (FIS) to fall back to the superclass implementations of `readAllBytes()`, `readNBytes(int)`, `skip()`, and `transferTo` when the input source would otherwise fail with "Illegal Seek" in the FIS implementation, such as for the standard input or a named pipe.

src/java.base/share/classes/java/io/FileInputStream.java line 334:

> 332:     @Override
> 333:     public byte[] readAllBytes() throws IOException {
> 334:         if (!canSeek())

Since `canSeek()` is implemented as a native call whose result depends on the file descriptor of this `FileInputStream`, do you think we should reduce these native calls in this change and call `canSeek()` just once (and store that state) in the constructors of this class?
If we do that, we might have to consider whether the `FileInputStream(FileDescriptor fdObj)` will end up throwing an exception (from the native canSeek() implementation) if the `FileDescriptor` passed to the constructor is not `valid()` https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/FileDescriptor.html#valid()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21673#discussion_r1814797437

From coleenp at openjdk.org  Thu Oct 24 11:35:35 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 11:35:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
 <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
Message-ID: <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>

On Thu, 24 Oct 2024 07:15:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.
>
> Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?

So you're saying there will still be these frames in the stack that we want to skip?  Okay, we'll clean all that out later then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1814801818

From jpai at openjdk.org  Thu Oct 24 11:42:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 11:42:06 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

src/java.xml/share/classes/javax/xml/validation/SchemaFactoryConfigurationError.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

Hello Hans, this looks like an oversight - the copyright year update should have retained the 2013 and additionally introduced 2024.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21637#discussion_r1814810579

From mbaesken at openjdk.org  Thu Oct 24 11:55:18 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Oct 2024 11:55:18 GMT
Subject: RFR: 8342938: Problem list java/io/IO/IO.java test on Linux ppc64le
Message-ID: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>

Test java/io/IO/IO.java fails on Linux ppc64le because of issues with 'expect' .

-------------

Commit messages:
 - JDK-8342938

Changes: https://git.openjdk.org/jdk/pull/21678/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21678&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342938
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21678/head:pull/21678

PR: https://git.openjdk.org/jdk/pull/21678

From hannesw at openjdk.org  Thu Oct 24 12:17:41 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 24 Oct 2024 12:17:41 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21637/files
  - new: https://git.openjdk.org/jdk/pull/21637/files/70c1d49f..65a3ddf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21637&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21637&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21637/head:pull/21637

PR: https://git.openjdk.org/jdk/pull/21637

From hannesw at openjdk.org  Thu Oct 24 12:17:42 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 24 Oct 2024 12:17:42 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>
Message-ID: <1SSi_dzz13sxXuDmlLMHn26DDwxozHVqmzIJkon1kFA=.6ce6f3c6-1e8e-4606-87ae-2ba61302c71e@github.com>

On Thu, 24 Oct 2024 11:39:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright header
>
> src/java.xml/share/classes/javax/xml/validation/SchemaFactoryConfigurationError.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Hello Hannes, this looks like an oversight - the copyright year update should have retained the 2013 and additionally introduced 2024.

Thanks for catching this, @jaikiran!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21637#discussion_r1814857072

From lucy at openjdk.org  Thu Oct 24 12:34:08 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 24 Oct 2024 12:34:08 GMT
Subject: RFR: 8342938: Problem list java/io/IO/IO.java test on Linux
 ppc64le
In-Reply-To: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>
References: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>
Message-ID: <bqOWAeBeEEjHdhDUvJbtXnqhr_mFaXerrFLrD1v52NY=.14383a2e-461a-4726-88a9-843097583149@github.com>

On Thu, 24 Oct 2024 09:08:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Test java/io/IO/IO.java fails on Linux ppc64le because of issues with 'expect' .

LGTM.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21678#pullrequestreview-2392339879

From jpai at openjdk.org  Thu Oct 24 12:44:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 12:44:05 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <I2kDmWqE6Ca4VnWeVBXIT1oJTaBgT114GEuazR0do34=.3228f83c-9b8e-4af5-938d-08baed53bfe4@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

This doc-only change which merely reorders the `@param` tags looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2392367946

From mullan at openjdk.org  Thu Oct 24 13:19:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 13:19:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@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 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

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=02
  Stats: 65432 lines in 1867 files changed: 1137 ins; 60545 del; 3750 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 jbhateja at openjdk.org  Thu Oct 24 13:36:50 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 13:36:50 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Review resolutions.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Factor out IR tests and Transforms to follow-up PRs.
 - Replacing flag based checks with CPU feature checks in IR validation test.
 - Remove Saturating IRNode patterns.
 - Restrict IR validation to newly added UMin/UMax transforms.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - Prod build fix
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
 - New IR tests + additional IR transformations
 - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

-------------

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=31
  Stats: 9395 lines in 52 files changed: 8959 ins; 29 del; 407 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Thu Oct 24 13:36:51 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 13:36:51 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
Message-ID: <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>

On Thu, 24 Oct 2024 06:46:32 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Factor out IR tests and Transforms to follow-up PRs.
>
> src/hotspot/cpu/x86/x86.ad line 10790:
> 
>> 10788:   predicate(is_subword_type(Matcher::vector_element_basic_type(n)) &&
>> 10789:             n->is_SaturatingVector() && !n->as_SaturatingVector()->is_unsigned());
>> 10790:   match(Set dst (SaturatingAddV (Binary dst (LoadVector src)) mask));
> 
> Do equivalent store operations exist we could also match for?

ISA only supports memory operands as second source operand.

> test/jdk/jdk/incubator/vector/VectorMathTest.java line 70:
> 
>> 68:     public static short[] INPUT_SS = {Short.MIN_VALUE,   (short)(Short.MIN_VALUE + TEN_S), ZERO_S, (short)(Short.MAX_VALUE - TEN_S), Short.MAX_VALUE};
>> 69:     public static int[]   INPUT_SI = {Integer.MIN_VALUE, (Integer.MIN_VALUE + TEN_I),      ZERO_I, Integer.MAX_VALUE - TEN_I,        Integer.MAX_VALUE};
>> 70:     public static long[]  INPUT_SL = {Long.MIN_VALUE,    Long.MIN_VALUE + TEN_L,           ZERO_L, Long.MAX_VALUE - TEN_L,           Long.MAX_VALUE};
> 
> Ok, now we have 4 or 5 hand-crafted examples. Is that sufficient? Some random values would be nice, then we know that at least eventually we have full coverage.

Hand crafter cases contains delimiting and general cases, in short they sufficiently cover entire value range.

> test/jdk/jdk/incubator/vector/templates/Unit-header.template line 1244:
> 
>> 1242:                 return fill(s * BUFFER_REPS,
>> 1243:                             i -> ($type$)($Boxtype$.MIN_VALUE + 100));
>> 1244:             })
> 
> Not sure I see this right. But are we only providing these 4 constants as inputs, and all values in the input arrays will be identical? If that is true: we should have some random inputs, or at least dependent on `i`.

Most important test points in a saturating operations are the edge conditions where overflow semantics differs and operation saturates a value than wrapping it around.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814998684
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814999013
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814998545

From jbhateja at openjdk.org  Thu Oct 24 13:36:51 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 13:36:51 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
Message-ID: <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>

On Thu, 24 Oct 2024 06:31:00 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java line 32:
>> 
>>> 30:  * @since   24
>>> 31:  */
>>> 32: public final class VectorMath {
>> 
>> I think this class could have been split into a separate RFE, together with its tests. I would prefer that next time.
>
> Also: why did we not add these `Long.minUnsigned` etc? I guess that was already discussed?
> Because we can easily also use this with the auto-vectorizer or more generally. Saturating and unsigned ops are generally useful I think...

PR is specially targeting explicit vectorization flow, we plan to address scalar intrinsification and auto-vectorization later, once type system has exposure to unsigned types.

>> test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingBinary-Masked-op.template line 8:
>> 
>>> 6: 
>>> 7:         for (int ic = 0; ic < INVOC_COUNT; ic++) {
>>> 8:             for (int i = 0; i < a.length; i += SPECIES.length()) {
>> 
>> I think this does not check if the generated vectors are too long. We had bugs in the past where we should have created say 2-element vectors, but the backend wrongly created 4-element vectors. This is especially an issue with vectors that do direct memory access.
>> 
>> With a simple "counting-up" test, you will probably not catch this. It could be good to have a "counting-down" example as well. What do you think?
>
> Also: all of these cases load, and directly store again. Does that not mean all tests will probably pick the "..._mem" backend operations? Or do we actually end up testing all backend operations with the tests we have here?

To exercise non memory operand pattern we need a vector operation padding layer after load vector, this will always ensure that selector pick all register operands flavor of instruction. Since its a generic limitation, do you think we should float it as a separate PR? 

I have create an RFE https://bugs.openjdk.org/browse/JDK-8342959  for reference. Given that we have moved IR tests out this PR on the grounds of review complexity, lets not add more code here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815000046
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1814998821

From epeter at openjdk.org  Thu Oct 24 13:44:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 13:44:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
Message-ID: <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>

On Thu, 24 Oct 2024 13:36:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Review resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Factor out IR tests and Transforms to follow-up PRs.
>  - Replacing flag based checks with CPU feature checks in IR validation test.
>  - Remove Saturating IRNode patterns.
>  - Restrict IR validation to newly added UMin/UMax transforms.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Prod build fix
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - New IR tests + additional IR transformations
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

src/hotspot/cpu/x86/x86.ad line 10593:

> 10591:   match(Set dst (SaturatingAddV src1 src2));
> 10592:   match(Set dst (SaturatingSubV src1 src2));
> 10593:   format %{ "vector_addsub_saturating_subword $dst, $src1, $src2" %}

Could the `Opcode` be put into the `format` string? Not strictly necessary, but would be neat.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815010088

From epeter at openjdk.org  Thu Oct 24 13:44:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 13:44:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
 <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>
Message-ID: <_Fu-_LTHnSKDrkQR1er4Tl9jIlyh2wIWvTstUaxJVFU=.df8418f6-95c9-4c52-8704-76d1f4046023@github.com>

On Thu, 24 Oct 2024 13:30:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/jdk/jdk/incubator/vector/VectorMathTest.java line 70:
>> 
>>> 68:     public static short[] INPUT_SS = {Short.MIN_VALUE,   (short)(Short.MIN_VALUE + TEN_S), ZERO_S, (short)(Short.MAX_VALUE - TEN_S), Short.MAX_VALUE};
>>> 69:     public static int[]   INPUT_SI = {Integer.MIN_VALUE, (Integer.MIN_VALUE + TEN_I),      ZERO_I, Integer.MAX_VALUE - TEN_I,        Integer.MAX_VALUE};
>>> 70:     public static long[]  INPUT_SL = {Long.MIN_VALUE,    Long.MIN_VALUE + TEN_L,           ZERO_L, Long.MAX_VALUE - TEN_L,           Long.MAX_VALUE};
>> 
>> Ok, now we have 4 or 5 hand-crafted examples. Is that sufficient? Some random values would be nice, then we know that at least eventually we have full coverage.
>
> Hand crafter cases contains delimiting and general cases, in short they sufficiently cover entire value range.

@PaulSandoz do you think this is sufficient coverage?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815012386

From epeter at openjdk.org  Thu Oct 24 13:44:28 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 13:44:28 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
 <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
Message-ID: <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>

On Thu, 24 Oct 2024 13:30:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Also: all of these cases load, and directly store again. Does that not mean all tests will probably pick the "..._mem" backend operations? Or do we actually end up testing all backend operations with the tests we have here?
>
> To exercise non memory operand pattern we need a vector operation padding layer after load vector, this will always ensure that selector pick all register operands flavor of instruction. Since its a generic limitation, do you think we should float it as a separate PR? 
> 
> I have create an RFE https://bugs.openjdk.org/browse/JDK-8342959  for reference. Given that we have moved IR tests out this PR on the grounds of review complexity, lets not add more code here.

Ok, we can file a separate RFE. Though I really have voiced 2 concerns:
- Making sure we always test `_mem` and `_reg` variants in the backend. See your https://bugs.openjdk.org/browse/JDK-8342959
- Making sure we have tests that would detect vectors that are too long. This would require some padding between the vectors, so that we have some untouched space - and if it does get touched we know that a vector was too long. Does that make sense? This is I guess also a general concern - and would have to be applied to all vector instructions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815017678

From redestad at openjdk.org  Thu Oct 24 13:57:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 24 Oct 2024 13:57:20 GMT
Subject: RFR: 8342958: Use jvmArgs consistently in microbenchmarks
Message-ID: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>

Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM reasonable or necessary flags, but when deploying and running micros we often want to add or replace flags to tune to the machine, test different GCs, etc. The inconsistent use of the different `jvmArgs` options make it error prone, and we've had a few recent cases where we've not been testing with the expected set of flags. 

This PR suggests using `jvmArgs` consistently. I think this aligns with the intuition that when you use `jvmArgsAppend/-Prepend` intent is to add to a set of existing flags, while if you supply `jvmArgs` intent is "run with these and nothing else". Perhaps there are other opinions/preferences, and I don't feel strongly about which to consolidate to as long as we do so consistently. One argument could be made to consolidate on `jvmArgsAppend` since that one is (likely accidentally) the current most popular (143 compared to 59 `jvmArgsPrepend` and 18 `jvmArgs`).

-------------

Commit messages:
 - Change all micros to consistently use jvmArgs, leaving both jvmArgsAppend/-Prepend free for ops

Changes: https://git.openjdk.org/jdk/pull/21683/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21683&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342958
  Stats: 202 lines in 142 files changed: 0 ins; 0 del; 202 mod
  Patch: https://git.openjdk.org/jdk/pull/21683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21683/head:pull/21683

PR: https://git.openjdk.org/jdk/pull/21683

From alanb at openjdk.org  Thu Oct 24 13:59:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 13:59:07 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices
In-Reply-To: <NGyEj0JwRNPj9hi0eFdOYX2KHlPA2b_642BsBcBlYXE=.5040051a-574c-4c98-8b33-c64a728e2714@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
 <NGyEj0JwRNPj9hi0eFdOYX2KHlPA2b_642BsBcBlYXE=.5040051a-574c-4c98-8b33-c64a728e2714@github.com>
Message-ID: <97MGOglCWpHjwzAxhlEJBQMT9uR0Zu_wsewRmor6z0M=.afe4de22-4977-4afe-8ce1-f127e2b31ec2@github.com>

On Thu, 24 Oct 2024 11:29:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Modify `FileInputStream` (FIS) to fall back to the superclass implementations of `readAllBytes()`, `readNBytes(int)`, `skip()`, and `transferTo` when the input source would otherwise fail with "Illegal Seek" in the FIS implementation, such as for the standard input or a named pipe.
>
> src/java.base/share/classes/java/io/FileInputStream.java line 334:
> 
>> 332:     @Override
>> 333:     public byte[] readAllBytes() throws IOException {
>> 334:         if (!canSeek())
> 
> Since `canSeek()` is implemented as a native call whose result depends on the file descriptor of this `FileInputStream`, do you think we should reduce these native calls in this change and call `canSeek()` just once (and store that state) in the constructors of this class (of course, after the call to open())?
> If we do that, we might have to consider whether the `FileInputStream(FileDescriptor fdObj)` will end up throwing an exception (from the native canSeek() implementation) if the `FileDescriptor` passed to the constructor is not `valid()` https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/FileDescriptor.html#valid()

readAllBytes reads to EOF so there isn't any benefit to caching. I think the main thing with this PR is whether canSeek is the right thing to use.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21673#discussion_r1815043405

From duke at openjdk.org  Thu Oct 24 14:03:25 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 24 Oct 2024 14:03:25 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <ljCruquhKjftFURuiiphQM4qBL-m2lEsUcjZgZ4VGHI=.058a2479-ee90-4c1f-a00d-a1e55e7831a3@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
 <ljCruquhKjftFURuiiphQM4qBL-m2lEsUcjZgZ4VGHI=.058a2479-ee90-4c1f-a00d-a1e55e7831a3@github.com>
Message-ID: <a3vTMrcRI7XoQr_JFPN8xJSIrmLDeKpuGGzeR-m2rr0=.ac0171b9-06d7-4107-acae-fb61c4863268@github.com>

On Wed, 23 Oct 2024 22:15:34 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

> An issue with the simple name `of` is that we may encounter calls like this:
> 
> `Reader.of("/usr/share/dict/words")`
> 
> ... that may look like they do something different. I can't say whether we should consider this a serious issue or not, though. I don't know if it justifies a big ugly name like `ofCharSequence` or not.

There always will be a small group this misunderstands things and does not read JavaDocs, we can never find "the perfect API" to prevent this completely. The question is if we need to make the API worse in turn and bother all others with ugly lengthy names? I personally think the actual risk here is negligible, and the solution ("RTFM") is rather simple to implement. ;-)

To sum up, IMHO as soon as Chen finished the internal tests, we should close this discussion and merge this PR as-is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2435379880

From jbhateja at openjdk.org  Thu Oct 24 14:03:26 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 14:03:26 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
 <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>
Message-ID: <xho7AbRfmyy-_XlCUIEZI2s4m1uq6uTpmunrRp6zrI4=.7c4208a4-4657-447d-bcf3-b757675592c3@github.com>

On Thu, 24 Oct 2024 13:36:53 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Review resolutions.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>>  - Factor out IR tests and Transforms to follow-up PRs.
>>  - Replacing flag based checks with CPU feature checks in IR validation test.
>>  - Remove Saturating IRNode patterns.
>>  - Restrict IR validation to newly added UMin/UMax transforms.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>>  - Prod build fix
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>>  - New IR tests + additional IR transformations
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c
>
> src/hotspot/cpu/x86/x86.ad line 10593:
> 
>> 10591:   match(Set dst (SaturatingAddV src1 src2));
>> 10592:   match(Set dst (SaturatingSubV src1 src2));
>> 10593:   format %{ "vector_addsub_saturating_subword $dst, $src1, $src2" %}
> 
> Could the `Opcode` be put into the `format` string? Not strictly necessary, but would be neat.

Desirable future extension, but its not related to this specific PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815050398

From jpai at openjdk.org  Thu Oct 24 14:05:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 14:05:05 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices
In-Reply-To: <97MGOglCWpHjwzAxhlEJBQMT9uR0Zu_wsewRmor6z0M=.afe4de22-4977-4afe-8ce1-f127e2b31ec2@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
 <NGyEj0JwRNPj9hi0eFdOYX2KHlPA2b_642BsBcBlYXE=.5040051a-574c-4c98-8b33-c64a728e2714@github.com>
 <97MGOglCWpHjwzAxhlEJBQMT9uR0Zu_wsewRmor6z0M=.afe4de22-4977-4afe-8ce1-f127e2b31ec2@github.com>
Message-ID: <uiI6sbxL_fxtqRFyOzbzxsN_Ws6lc6FXcP7V4xMeVNA=.1273b78f-7a09-46aa-8eb3-c0ceb89d897f@github.com>

On Thu, 24 Oct 2024 13:56:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileInputStream.java line 334:
>> 
>>> 332:     @Override
>>> 333:     public byte[] readAllBytes() throws IOException {
>>> 334:         if (!canSeek())
>> 
>> Since `canSeek()` is implemented as a native call whose result depends on the file descriptor of this `FileInputStream`, do you think we should reduce these native calls in this change and call `canSeek()` just once (and store that state) in the constructors of this class (of course, after the call to open())?
>> If we do that, we might have to consider whether the `FileInputStream(FileDescriptor fdObj)` will end up throwing an exception (from the native canSeek() implementation) if the `FileDescriptor` passed to the constructor is not `valid()` https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/FileDescriptor.html#valid()
>
> readAllBytes reads to EOF so there isn't any benefit to caching. I think the main thing with this PR is whether canSeek is the right thing to use.

Hello Alan, I didn't just mean the readAllBytes. The rest of the changes in this PR calls canSeek() even in readNBytes() and skip() implementations which may not be reading till EOF and in theory could be invoked multiple times.
Having said that, the proposal to cache was merely a suggestion. I don't have any data to suggest if these methods are called frequent enough to have the additional native call show up prominently in that call path.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21673#discussion_r1815051566

From epeter at openjdk.org  Thu Oct 24 14:07:24 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 24 Oct 2024 14:07:24 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <xho7AbRfmyy-_XlCUIEZI2s4m1uq6uTpmunrRp6zrI4=.7c4208a4-4657-447d-bcf3-b757675592c3@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
 <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>
 <xho7AbRfmyy-_XlCUIEZI2s4m1uq6uTpmunrRp6zrI4=.7c4208a4-4657-447d-bcf3-b757675592c3@github.com>
Message-ID: <vo7yaqOXbMBtIITyjIIYq-DQqL25Y6noa2PBRdW1fMU=.99921f1a-fd0c-44ce-840a-ea342adeb7ab@github.com>

On Thu, 24 Oct 2024 13:59:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 10593:
>> 
>>> 10591:   match(Set dst (SaturatingAddV src1 src2));
>>> 10592:   match(Set dst (SaturatingSubV src1 src2));
>>> 10593:   format %{ "vector_addsub_saturating_subword $dst, $src1, $src2" %}
>> 
>> Could the `Opcode` be put into the `format` string? Not strictly necessary, but would be neat.
>
> Desirable future extension, but its not related to this specific PR.

Well, here it would be especially interesting, because it would tell us if we have a `sub` or an `add`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815058565

From mullan at openjdk.org  Thu Oct 24 14:07:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 14:07:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <TAjuG-LLpFQjYHfC-K2h0rAynZrqV0ckIViIVvwJB94=.cb21f1de-39bc-4fb6-96a1-861834ccb336@github.com>

On Mon, 21 Oct 2024 22:51:54 GMT, Mandy Chung <mchung 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java line 31:
> 
>> 29:  * @summary test that all fields returned by getDeclaredFields() can be
>> 30:  *          set accessible if the right permission is granted; this test
>> 31:  *          also verifies that Class.classLoader final private field is
> 
> "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d8564fa8dd003456b6e313c5e07809999c7d96e1

> test/jdk/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java line 45:
> 
>> 43: 
>> 44:     public static void main(String... args) throws Throwable {
>> 45:         System.err.println("Test without security manager.");
> 
> Security manager is not relevant any more.  Suggest to drop this println.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/002276450e625b66b786fb7eae7256bbcafa7496

> test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java line 83:
> 
>> 81:     }
>> 82: 
>> 83:     private static final String NEW_PROXY_IN_PKG = "newProxyInPackage.";
> 
> This constant is no longer needed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/3dbf684263a75470b85a95b9446a44ceb99c4b3a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815057352
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815058036
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815055982

From mullan at openjdk.org  Thu Oct 24 14:07:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 14:07:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
 <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>
Message-ID: <ZHPRQ0q6AkTrdGKCsX_9xghixEQm8e0qe7UTbqPSCFM=.b57001b8-376f-4e00-9953-64d8bdaeb160@github.com>

On Wed, 23 Oct 2024 11:58:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
>> 
>>> 31:  * @test
>>> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
>>> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest
>> 
>> line 36 can also be removed.
>> 
>> 
>> * $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest
>
> hasSM and the code that only runs when true can be deleted too.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/559934662119b1372fd831de8be7c97f877e0947

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815058738

From jbhateja at openjdk.org  Thu Oct 24 14:10:15 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 14:10:15 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <_Fu-_LTHnSKDrkQR1er4Tl9jIlyh2wIWvTstUaxJVFU=.df8418f6-95c9-4c52-8704-76d1f4046023@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
 <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>
 <_Fu-_LTHnSKDrkQR1er4Tl9jIlyh2wIWvTstUaxJVFU=.df8418f6-95c9-4c52-8704-76d1f4046023@github.com>
Message-ID: <DNAWXAMOALG7D0uTxP5P4qDQJ5EV8baLwMTMYCZEPlY=.de326730-62df-4f90-9730-aac0e77ca118@github.com>

On Thu, 24 Oct 2024 13:38:12 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Hand crafter cases contains delimiting and general cases, in short they sufficiently cover entire value range.
>
> @PaulSandoz do you think this is sufficient coverage?

Please note this test was added just to cover scalar operation validation in VectorMath, automated tests exercise these APIs in fallback implementation anyways.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815064343

From jvernee at openjdk.org  Thu Oct 24 14:20:21 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 24 Oct 2024 14:20:21 GMT
Subject: RFR: 8338544: Dedicated Array class descriptor implementation [v8]
In-Reply-To: <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>
References: <_sDTnqrcvxUdY-XLxAnhXRBXVDjhaZ9trn1cFNC5WHo=.1eab1e2f-8fe0-44b0-8c9c-2349791d0e57@github.com>
 <YBtM_WbOlIe8RUx35kLnD4LEjCnJGqolIyYs5eZ8h2M=.0aa14f6e-a87a-4f08-b8b0-a684f3b4558d@github.com>
Message-ID: <XB1awfEhOWMkwRw599pW3txCWiF9BZ6WIhGPyECUVco=.e0d18473-3583-41c3-b926-23033724a0e6@github.com>

On Wed, 23 Oct 2024 06:14:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @cl4es discovered that Stack Map generation in ClassFile API uses `componentType` and `arrayType` for `aaload` `aastore` instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster `arrayType` and `componentType` operations.
>> 
>> Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the `ClassDesc` implementations much cleaner.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix displayName
>   
>   Turns out ArrayClassDesc::displayName was incorrect. Added a test.

Latest version looks good.

P.S. Oh, looks like the tab I had open for this PR wasn't updated. Didn't see it was already merged. All good!

-------------

PR Review: https://git.openjdk.org/jdk/pull/20665#pullrequestreview-2392757564

From jwaters at openjdk.org  Thu Oct 24 14:22:28 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Oct 2024 14:22:28 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8342682

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21616/files
  - new: https://git.openjdk.org/jdk/pull/21616/files/e149e654..2294b27f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=00-01

  Stats: 68 lines in 22 files changed: 1 ins; 21 del; 46 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  Thu Oct 24 14:22:29 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Oct 2024 14:22:29 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <PAXJ4c957eITw8vYHeZk2eDQ6T60wVqOAJwpa_2I344=.1eef170c-5296-47ce-b0d3-aee9124834af@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <6bgDWzW7hPhgXiKPtf691dw78Fywzz7xpNfI7AixFsM=.ebc2cc90-ebc1-4187-ae38-3f0979a97dc9@github.com>
 <PAXJ4c957eITw8vYHeZk2eDQ6T60wVqOAJwpa_2I344=.1eef170c-5296-47ce-b0d3-aee9124834af@github.com>
Message-ID: <7TiLoi4kpEVA782sZ5phBa38PuZxf7Ny6H_lZ27cFgA=.59b35424-72f8-4cb8-be83-758c2e181836@github.com>

On Thu, 24 Oct 2024 07:11:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > the way I did it I'd have to force push
> 
> That should not be the case. You can just anti-delta changes.

I did it in a really inefficient way, by checking out all files except for the files that I wanted to stay. I could not figure out how to undo it. In any case, I'm sorry for the sin I just committed...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2435429996

From alanb at openjdk.org  Thu Oct 24 14:29:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 14:29:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
 <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
 <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>
Message-ID: <bLyF3XGfyhUtiuOuG0jqnqZtXM0UgzNtZAAZhDyNymM=.cdec18a4-ba4e-4e32-918a-93be3d95fadc@github.com>

On Thu, 24 Oct 2024 11:32:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?
>
> So you're saying there will still be these frames in the stack that we want to skip?  Okay, we'll clean all that out later then.

I have the changes to Class/ClassLoader to propose as soon as this JEP integrates. If that can go in quickly then it would remove any concerns in advance of your cleanup to remove the filtering of these frames (although I don't think there is an issue as this code path is conditional based on whether a SM is set).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815107403

From liach at openjdk.org  Thu Oct 24 14:38:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 14:38:22 GMT
Subject: RFR: 8341566: Add Reader.of(CharSequence) [v15]
In-Reply-To: <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
 <B8oxCjZyEKwYz2wKRbweZrFy_2w_onJTOdDG_iegU20=.6fd9254e-c73c-498f-879a-5d9dc74df619@github.com>
Message-ID: <UDvo3sQLzd-9B68xxy2KYgBul4vjxq8ioN_tsAQttZg=.1aab24b0-c21b-456c-9e3f-8e75f057906b@github.com>

On Wed, 23 Oct 2024 08:58:30 GMT, Markus KARG <duke at openjdk.org> wrote:

>> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
>> 
>> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
>> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
>> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
>> 
>> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed wording as proposed by Alan Bateman: 'The returned reader supports the mark and reset ... could move up to become the second paragraph.'
>  - Fixed wording as proposed by Alan Bateman: 'make The reader is initially .. the second sentence of the first paragraph rather than a new paragraph.'

Thanks Markus! The java.io tests succeed with repeats and the only test failures in tier 1-3 were ones problem-listed by f7a61fce949ea2d15ec09d295c643d0c2eabea1e.

FYI, besides Kevin's question, there was another concern about this API's interaction with BufferedReader (as you know, many Reader users wrap any Reader into a BufferedReader, especially you want to read all lines from a reader). We currently decide that we might explore line reading capability to Reader, but anyways that will not affect this patch.

And I have consulted with Kevin in private; he thinks this minor confusion is fine.

Sponsoring.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21371#issuecomment-2435470372

From duke at openjdk.org  Thu Oct 24 14:38:23 2024
From: duke at openjdk.org (Markus KARG)
Date: Thu, 24 Oct 2024 14:38:23 GMT
Subject: Integrated: 8341566: Add Reader.of(CharSequence)
In-Reply-To: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
References: <MBQum-34oAripHuSImprlZ52n5RZk343Y3dkRGf5Ib4=.9f3798dc-e1a5-435e-ba38-6a430525881a@github.com>
Message-ID: <L5Fkr7w7L0f_D1UCIAtJnkUpTnmgMNZXTKJ1hf1CzCo=.903e45ba-dffa-42eb-a569-8dcb02ab2784@github.com>

On Sat, 5 Oct 2024 16:32:39 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Requests proposes an implementation for [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new method `public static Reader Reader.of(CharSequence)` will return an anonymous, non-synchronized implementation of a `Reader` for each kind of `CharSequence` implementation. It is optimized for `String`, `StringBuilder`, `StringBuffer` and `CharBuffer`.
> 
> In addition, this Pull Request proposes to replace the implementation of `StringReader` to become a simple synchronized wrapper around `Reader.of(CharSequence)` for the case of `String` sources. To ensure correctness, this PR...
> * ...simply moved the **original code** of `StringBuilder` to become the de-facto implementation of `Reader.of()`, then stripped synchronized from it on the left hand, but kept just a synchronized wrapper on the right hand. Then added a `switch` for optimizations within the original code, at the exact location where previously just an optimization for `String` lived in.
> * ...added tests for all methods (`Of.java`), and applied that test upon the modified `StringBuilder`.
> 
> Wherever new JavaDocs were added, existing phrases from other code locations have been copied and adapted, to best match the same wording.

This pull request has now been integrated.

Changeset: 3c14c2ba
Author:    Markus KARG <markus at headcrashing.eu>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c14c2babbdfb46a77636ed80e083ef2f8be2b45
Stats:     385 lines in 3 files changed: 338 ins; 36 del; 11 mod

8341566: Add Reader.of(CharSequence)

Reviewed-by: rriggs, jpai, liach, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21371

From ecaspole at openjdk.org  Thu Oct 24 14:46:08 2024
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 24 Oct 2024 14:46:08 GMT
Subject: RFR: 8342958: Use jvmArgs consistently in microbenchmarks
In-Reply-To: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>
References: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>
Message-ID: <meKy1jtVf5iB7DUxdHwuIzR6xcvYu9y1wjB4Np36vOw=.ac38e5b0-4268-47a4-8978-4a673ad3a2d5@github.com>

On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM reasonable or necessary flags, but when deploying and running micros we often want to add or replace flags to tune to the machine, test different GCs, etc. The inconsistent use of the different `jvmArgs` options make it error prone, and we've had a few recent cases where we've not been testing with the expected set of flags. 
> 
> This PR suggests using `jvmArgs` consistently. I think this aligns with the intuition that when you use `jvmArgsAppend/-Prepend` intent is to add to a set of existing flags, while if you supply `jvmArgs` intent is "run with these and nothing else". Perhaps there are other opinions/preferences, and I don't feel strongly about which to consolidate to as long as we do so consistently. One argument could be made to consolidate on `jvmArgsAppend` since that one is (likely accidentally) the current most popular (143 compared to 59 `jvmArgsPrepend` and 18 `jvmArgs`).

Looks good.

-------------

Marked as reviewed by ecaspole (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21683#pullrequestreview-2392886714

From iris at openjdk.org  Thu Oct 24 14:48:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 24 Oct 2024 14:48:08 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <I0JNrzns6q4kroyAUrklR25TtDu-NaMGivmDom9qvPg=.5a85ad97-a410-4e92-b509-b959420cd0ba@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Confirmed changes only re-order @param declarations.
 
Recommend @JoeWang-Java to review changes to java.xml since portions of that module are maintained in an upstream repository.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2392918255

From sspitsyn at openjdk.org  Thu Oct 24 14:52:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Oct 2024 14:52:27 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v11]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: removed asserts from continuationFreezeThaw.cpp again

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/5d6e5c91..bc056ec1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From psandoz at openjdk.org  Thu Oct 24 15:04:14 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 24 Oct 2024 15:04:14 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
 <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
Message-ID: <Vyw79ZVROQcEbDaCsKyIHAedT6tbEYrpXNcnkpME1QA=.edaa7e1e-678f-4806-abdd-7bf88d28e2a9@github.com>

On Thu, 24 Oct 2024 13:31:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Also: why did we not add these `Long.minUnsigned` etc? I guess that was already discussed?
>> Because we can easily also use this with the auto-vectorizer or more generally. Saturating and unsigned ops are generally useful I think...
>
> PR is specially targeting explicit vectorization flow, we plan to address scalar intrinsification and auto-vectorization later, once type system has exposure to unsigned types.

We are uncertain about their locations in `java.lang` at the moment. For now it's better to place them under incubation and then revisit later when we are more certain.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815180240

From psandoz at openjdk.org  Thu Oct 24 15:10:15 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 24 Oct 2024 15:10:15 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <DNAWXAMOALG7D0uTxP5P4qDQJ5EV8baLwMTMYCZEPlY=.de326730-62df-4f90-9730-aac0e77ca118@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <Hg_lsFU5Js_rUpzSHE6WdGMcGUsBxVg24AnS6NnjLfE=.fa927bc3-681a-4177-903a-dfa14e20c47c@github.com>
 <WTdWcZkVd_DaHkfUdQEXRwdt8FlTDRN9Y_eLA_fu508=.93eb0838-7402-4cec-9362-5e6b8a159ac0@github.com>
 <_Fu-_LTHnSKDrkQR1er4Tl9jIlyh2wIWvTstUaxJVFU=.df8418f6-95c9-4c52-8704-76d1f4046023@github.com>
 <DNAWXAMOALG7D0uTxP5P4qDQJ5EV8baLwMTMYCZEPlY=.de326730-62df-4f90-9730-aac0e77ca118@github.com>
Message-ID: <koMDh1i6p6SEDncMXgPq9vbHZO9pFHgTYjvE10Mx21I=.a7879b0a-de1c-4f89-9228-c025332b2c51@github.com>

On Thu, 24 Oct 2024 14:07:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @PaulSandoz do you think this is sufficient coverage?
>
> Please note this test was added just to cover scalar operation validation in VectorMath, automated tests exercise these APIs in fallback implementation anyways.

I think the coverage is sufficient for now and we can expand later. The test is written so that it should be possible to more easily refactor and add further dynamically generated test cases. (Note it is deliberately not a test designed to specifically exercise C2 - if/when we add auto vectorization IR tests would be required).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815191672

From vklang at openjdk.org  Thu Oct 24 15:13:40 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Oct 2024 15:13:40 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview
Message-ID: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>

Make final adjustments to drop PreviewFeature and updating the @ since markers.

-------------

Commit messages:
 - 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=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342707
  Stats: 35 lines in 24 files changed: 0 ins; 17 del; 18 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 bpb at openjdk.org  Thu Oct 24 15:16:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Oct 2024 15:16:04 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices
In-Reply-To: <uiI6sbxL_fxtqRFyOzbzxsN_Ws6lc6FXcP7V4xMeVNA=.1273b78f-7a09-46aa-8eb3-c0ceb89d897f@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
 <NGyEj0JwRNPj9hi0eFdOYX2KHlPA2b_642BsBcBlYXE=.5040051a-574c-4c98-8b33-c64a728e2714@github.com>
 <97MGOglCWpHjwzAxhlEJBQMT9uR0Zu_wsewRmor6z0M=.afe4de22-4977-4afe-8ce1-f127e2b31ec2@github.com>
 <uiI6sbxL_fxtqRFyOzbzxsN_Ws6lc6FXcP7V4xMeVNA=.1273b78f-7a09-46aa-8eb3-c0ceb89d897f@github.com>
Message-ID: <-O2Ls_9kZP9fMJnRI5Mxh_Xp_rLuErlhGZdEdGCzvnE=.bd377750-eded-4932-bd9a-489562109d70@github.com>

On Thu, 24 Oct 2024 14:00:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> readAllBytes reads to EOF so there isn't any benefit to caching. I think the main thing with this PR is whether canSeek is the right thing to use.
>
> Hello Alan, I didn't just mean the readAllBytes. The rest of the changes in this PR calls canSeek() even in readNBytes() and skip() implementations which may not be reading till EOF and in theory could be invoked multiple times.
> Having said that, the proposal to cache was merely a suggestion. I don't have any data to suggest if these methods are called frequent enough to have the additional native call show up prominently in that call path.

> [...] do you think we should reduce these native calls in this change and call `canSeek()` just once [...]

I think that is a good idea but I would think it best to do i in a similar way to the recent change to `ChannelInputStream` that added `isOther`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21673#discussion_r1815201732

From bpb at openjdk.org  Thu Oct 24 15:16:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Oct 2024 15:16:05 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices
In-Reply-To: <-O2Ls_9kZP9fMJnRI5Mxh_Xp_rLuErlhGZdEdGCzvnE=.bd377750-eded-4932-bd9a-489562109d70@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
 <NGyEj0JwRNPj9hi0eFdOYX2KHlPA2b_642BsBcBlYXE=.5040051a-574c-4c98-8b33-c64a728e2714@github.com>
 <97MGOglCWpHjwzAxhlEJBQMT9uR0Zu_wsewRmor6z0M=.afe4de22-4977-4afe-8ce1-f127e2b31ec2@github.com>
 <uiI6sbxL_fxtqRFyOzbzxsN_Ws6lc6FXcP7V4xMeVNA=.1273b78f-7a09-46aa-8eb3-c0ceb89d897f@github.com>
 <-O2Ls_9kZP9fMJnRI5Mxh_Xp_rLuErlhGZdEdGCzvnE=.bd377750-eded-4932-bd9a-489562109d70@github.com>
Message-ID: <UQ612RgSfwXTzfgWL9ErEqGkgktW8pdTXTzX2jRNUvo=.a6231eea-0ab6-4d38-bc63-87a8c7fa0a32@github.com>

On Thu, 24 Oct 2024 15:11:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hello Alan, I didn't just mean the readAllBytes. The rest of the changes in this PR calls canSeek() even in readNBytes() and skip() implementations which may not be reading till EOF and in theory could be invoked multiple times.
>> Having said that, the proposal to cache was merely a suggestion. I don't have any data to suggest if these methods are called frequent enough to have the additional native call show up prominently in that call path.
>
>> [...] do you think we should reduce these native calls in this change and call `canSeek()` just once [...]
> 
> I think that is a good idea but I would think it best to do i in a similar way to the recent change to `ChannelInputStream` that added `isOther`.

> I think the main thing with this PR is whether canSeek is the right thing to use.

`canSeek` is really the same as `isOther` in the recent `Files.newInputStream` change, but given that on Windows the result of the function is always `true`, the naming `isOther` (which would always return `false`) did not seem apropos.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21673#discussion_r1815205981

From psandoz at openjdk.org  Thu Oct 24 15:19:20 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 24 Oct 2024 15:19:20 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
 <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
 <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>
Message-ID: <HhVt-vF5pur1QVZzkxyCS2dZf8fx95zomNgvASaPaC0=.872254c0-6d39-4fe9-b43d-b1de1fa3f03a@github.com>

On Thu, 24 Oct 2024 13:41:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> To exercise non memory operand pattern we need a vector operation padding layer after load vector, this will always ensure that selector pick all register operands flavor of instruction. Since its a generic limitation, do you think we should float it as a separate PR? 
>> 
>> I have create an RFE https://bugs.openjdk.org/browse/JDK-8342959  for reference. Given that we have moved IR tests out this PR on the grounds of review complexity, lets not add more code here.
>
> Ok, we can file a separate RFE. Though I really have voiced 2 concerns:
> - Making sure we always test `_mem` and `_reg` variants in the backend. See your https://bugs.openjdk.org/browse/JDK-8342959
> - Making sure we have tests that would detect vectors that are too long. This would require some padding between the vectors, so that we have some untouched space - and if it does get touched we know that a vector was too long. Does that make sense? This is I guess also a general concern - and would have to be applied to all vector instructions.

Good point on vector operations overrunning bounds. I worry about the computational increase of doing this generally for all operations (explicit or for auto vectorization i suppose). Perhaps we can focus on areas where we know this may be problematic?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815211324

From vklang at openjdk.org  Thu Oct 24 15:26:24 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Oct 2024 15:26:24 GMT
Subject: [jdk23] RFR: 8342905: Thread.setContextClassloader from thread in
 FJP commonPool task no longer works after JDK-8327501 redux
In-Reply-To: <ajQ_02ARas5U2alcVSBntwVT1bmaFqOlyk5TiDxoP80=.8eb6a4cc-8887-415f-a23c-1555e0f1b846@github.com>
References: <ajQ_02ARas5U2alcVSBntwVT1bmaFqOlyk5TiDxoP80=.8eb6a4cc-8887-415f-a23c-1555e0f1b846@github.com>
Message-ID: <KAReXnXziqwz9OJQituQzLrQQUhTW0tT_Mp_SMBQxB4=.83975963-9b53-4612-b007-c1d642099698@github.com>

On Wed, 23 Oct 2024 18:36:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Having opted in to allow setting an SM is a clearer signal.

Targeting jdk23u instead of here. Closing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21668#issuecomment-2435598811

From vklang at openjdk.org  Thu Oct 24 15:26:24 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Oct 2024 15:26:24 GMT
Subject: [jdk23] Withdrawn: 8342905: Thread.setContextClassloader from thread
 in FJP commonPool task no longer works after JDK-8327501 redux
In-Reply-To: <ajQ_02ARas5U2alcVSBntwVT1bmaFqOlyk5TiDxoP80=.8eb6a4cc-8887-415f-a23c-1555e0f1b846@github.com>
References: <ajQ_02ARas5U2alcVSBntwVT1bmaFqOlyk5TiDxoP80=.8eb6a4cc-8887-415f-a23c-1555e0f1b846@github.com>
Message-ID: <9ZQ_xOa7UxQNKSuMZTGXH-GB3PC8jznCj-LLTnfSYlk=.d0e0ac3d-24b2-4b31-8884-819a4bef58eb@github.com>

On Wed, 23 Oct 2024 18:36:01 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Having opted in to allow setting an SM is a clearer signal.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21668

From jiangli at openjdk.org  Thu Oct 24 15:30:08 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Oct 2024 15:30:08 GMT
Subject: RFR: 8342642: Class loading failure due to archived map issue in
 ModuleLoaderMap.Mapper
In-Reply-To: <uQOrLdzHHGFc7GGCBl1XGucRfBFgrgCsUKl6e429Pi4=.c6939582-9d0c-4369-a0b7-99aca94e2787@github.com>
References: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
 <Uy7sY_UaGyqS8dliTx1fbvEy_4_HuEDVgb2ZiirMIbw=.afbc0f19-1431-47a6-aec7-b71d1c686773@github.com>
 <uQOrLdzHHGFc7GGCBl1XGucRfBFgrgCsUKl6e429Pi4=.c6939582-9d0c-4369-a0b7-99aca94e2787@github.com>
Message-ID: <uLY5dvF9HLHrzM0zI16c3PFRNfr6ha31paTBpFrs0io=.9686dab1-d0e4-47cb-a1ed-720424ba0874@github.com>

On Thu, 24 Oct 2024 05:51:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > @iklam Would it be possible to comment on this? If the system properties to configure the range of integer cache are set at runtime, does it just not use this archived object graph? I'm wondering if it should disable CDS?
> 
> A better fix would be:
> 
> If runtime java.lang.Integer.IntegerCache.high < dumptime java.lang.Integer.IntegerCache.high -- copy the initial elements from the dumptime cache array -- fill the rest of the cache array
> 
> that way, we will still preserve the object identity of the Integers created during dump time.
> 
> I think we need to do the same thing for the other box cases.

I've been thinking about something like that as a longer term fix after this quick fix. However, there are some complications, e.g.:

When an archived boxed Integer instance is 'used' in a pre-initialized class static field's sub-graph, depending on the runtime IntegerCache.high specified by the system property, the specific 'used' Integer may not be within the runtime range (used_Integer > IntegerCache.high). In that case, the runtime modified cache does not contain the archived boxed Integer instance. Then, the usage of the archived instance is invalid, which causes the corresponding pre-initialized static field to still be problematic. For this loader map, in an extreme example (unlikely to happen) when runtime IntegerCache.high=1, it would still not work well. For such cases, we would need to invalidate the pre-initialized static field or class. That's the reason I mentioned filing a separate bug for the archived Integer cache and evaluating together with the general AOT cache work, see https://bugs.openjdk.org/browse/JDK-8342642?focusedId=14714939&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-
 tabpanel#comment-14714939.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21672#issuecomment-2435608321

From bpb at openjdk.org  Thu Oct 24 16:09:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Oct 2024 16:09:22 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices [v2]
In-Reply-To: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
Message-ID: <-FMUY-2m2MmbdiNpz46AoQTbvpC0Ne9i00zsIlwko2c=.5caede95-020f-4622-ae64-c7ddc93ebe70@github.com>

> Modify `FileInputStream` (FIS) to fall back to the superclass implementations of `readAllBytes()`, `readNBytes(int)`, `skip()`, and `transferTo` when the input source would otherwise fail with "Illegal Seek" in the FIS implementation, such as for the standard input or a named pipe.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8341666: Cache value of canSeek()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21673/files
  - new: https://git.openjdk.org/jdk/pull/21673/files/69260350..d6b679d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21673&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21673&range=00-01

  Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21673/head:pull/21673

PR: https://git.openjdk.org/jdk/pull/21673

From jlu at openjdk.org  Thu Oct 24 16:20:15 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 24 Oct 2024 16:20:15 GMT
Subject: Integrated: 8340554: Improve MessageFormat readObject checks
In-Reply-To: <0hSlYistdp3kSZMl2Frm65PSONFmtwpkx0EcJb_x1-E=.8f597ec0-df3c-499b-a555-92ede1bb1cfb@github.com>
References: <0hSlYistdp3kSZMl2Frm65PSONFmtwpkx0EcJb_x1-E=.8f597ec0-df3c-499b-a555-92ede1bb1cfb@github.com>
Message-ID: <f6gpY6_MWuDsrka-Eb4HhTT4c4J3RwZlP6qmoaEz6jw=.60a599c6-4255-4899-8039-eb9de1f38882@github.com>

On Thu, 17 Oct 2024 20:14:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves the readObject logic for _j.text.MessageFormat_.
> 
> No offset should be larger than the pattern length. We already ensure the offsets when consumed backwards are equal/descending. The existing first/initial check was off by 1 since it was checking against the pattern length + 1; (see L2040 and L2043).
> 
> Please see the JBS issue for further info and other test details.

This pull request has now been integrated.

Changeset: 7af46a6b
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7af46a6b424cadfe298958d774da0f21db58ecd3
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8340554: Improve MessageFormat readObject checks

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21570

From joehw at openjdk.org  Thu Oct 24 16:40:06 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 24 Oct 2024 16:40:06 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <uMoFOQDA3ikNwrePol8zee2hd4FO8lGqoeMFhVh70B4=.4407fe29-37bd-4a2c-9d51-0bfdb6cfb55b@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Thanks Iris for the reminder. Changes to java.xml look good.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2393208720

From liach at openjdk.org  Thu Oct 24 16:45:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 24 Oct 2024 16:45:06 GMT
Subject: RFR: 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: <ITbJz-c7M0Ow0nU-Bf6MjNw785FwOsDRKewU1Aa4c-4=.88a52b99-7b8c-41b8-ad35-9c79b799e95e@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.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 79:

> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
> 78:         CLASSFILE_API,
> 79:         STREAM_GATHERERS,

Does bootcycle fail if this enum constant is removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21686#discussion_r1815375043

From heidinga at openjdk.org  Thu Oct 24 17:12:13 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 24 Oct 2024 17:12:13 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v3]
In-Reply-To: <aEW1gzlt54nr-O9B236ddY5FzO8X1JUr0IjIKGqgOuU=.729b1434-35ac-4427-8648-bf7a520fd487@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <aEW1gzlt54nr-O9B236ddY5FzO8X1JUr0IjIKGqgOuU=.729b1434-35ac-4427-8648-bf7a520fd487@github.com>
Message-ID: <3_QqIqOqw7Zhq-gpwFG72w4EWyoDfjNEHhdBt-eOjDU=.59d15b7a-9081-4cce-9303-108901d931c9@github.com>

On Wed, 23 Oct 2024 04:46:51 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 three additional commits since the last revision:
> 
>  - fixed test failure with "jtreg -Dtest.dynamic.cds.archive=true ..."
>  - simplified the archiving of cpCache::resolved_references() -- we rely on AOTConstantPoolResolver::is_indy_resolution_deterministic() to do the filtering before indys are linked; there is no need to try to undo the resolved_references afterwards
>  - Fixed bug where the BSM oops for resolved indies are not archived

Looks good!

src/hotspot/share/cds/aotClassLinker.cpp line 156:

> 154:         ResourceMark rm;
> 155:         log_warning(cds, aot, link)("%s cannot be aot-linked because it nest host is not aot-linked", ik->external_name());
> 156:         return false;

This is a good find!  Just to note - the same kind of check isn't required for PermittedSubclasses as the class granting permission to be a subclass is necessarily already loaded as one of our supers.

-------------

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2390446370
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1815035125

From naoto at openjdk.org  Thu Oct 24 17:15:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 24 Oct 2024 17:15:06 GMT
Subject: RFR: 8342938: Problem list java/io/IO/IO.java test on Linux
 ppc64le
In-Reply-To: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>
References: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>
Message-ID: <-K253mcafml9FuT90uBGlHg6sC8iI2favfiCWi6U0xs=.d53a27e8-b6a5-46e0-b895-45e4181cd40a@github.com>

On Thu, 24 Oct 2024 09:08:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Test java/io/IO/IO.java fails on Linux ppc64le because of issues with 'expect' .

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21678#pullrequestreview-2393288156

From jvernee at openjdk.org  Thu Oct 24 17:15:06 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 24 Oct 2024 17:15:06 GMT
Subject: RFR: 8342958: Use jvmArgs consistently in microbenchmarks
In-Reply-To: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>
References: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>
Message-ID: <lLazgF7gVvIMLtygF59cn1RWbmuR-P_810PEQGx56V8=.64855b53-5c86-47a6-b779-db8221a4ca7b@github.com>

On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM reasonable or necessary flags, but when deploying and running micros we often want to add or replace flags to tune to the machine, test different GCs, etc. The inconsistent use of the different `jvmArgs` options make it error prone, and we've had a few recent cases where we've not been testing with the expected set of flags. 
> 
> This PR suggests using `jvmArgs` consistently. I think this aligns with the intuition that when you use `jvmArgsAppend/-Prepend` intent is to add to a set of existing flags, while if you supply `jvmArgs` intent is "run with these and nothing else". Perhaps there are other opinions/preferences, and I don't feel strongly about which to consolidate to as long as we do so consistently. One argument could be made to consolidate on `jvmArgsAppend` since that one is (likely accidentally) the current most popular (143 compared to 59 `jvmArgsPrepend` and 18 `jvmArgs`).

I've always used `-jvmArgsAppend <String>` to add more flags on the command line when running the benchmarks jar directly. Does that still work if we change the annotations to use `jvmArgs`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21683#issuecomment-2435881457

From redestad at openjdk.org  Thu Oct 24 17:23:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 24 Oct 2024 17:23:06 GMT
Subject: RFR: 8342958: Use jvmArgs consistently in microbenchmarks
In-Reply-To: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>
References: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>
Message-ID: <jav65Re41Wd-eMq1zjhmayrVwY5BdJ_V9Kx8v-sqvzI=.cfa213ae-d771-4e64-b3b9-36edb265c422@github.com>

On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM reasonable or necessary flags, but when deploying and running micros we often want to add or replace flags to tune to the machine, test different GCs, etc. The inconsistent use of the different `jvmArgs` options make it error prone, and we've had a few recent cases where we've not been testing with the expected set of flags. 
> 
> This PR suggests using `jvmArgs` consistently. I think this aligns with the intuition that when you use `jvmArgsAppend/-Prepend` intent is to add to a set of existing flags, while if you supply `jvmArgs` intent is "run with these and nothing else". Perhaps there are other opinions/preferences, and I don't feel strongly about which to consolidate to as long as we do so consistently. One argument could be made to consolidate on `jvmArgsAppend` since that one is (likely accidentally) the current most popular (143 compared to 59 `jvmArgsPrepend` and 18 `jvmArgs`).

Yes, that's typically what we do in testing, the subtle problem solved by this is that when you do so you'll silently overwrite pre-existing jvmArgsAppend annotation values. I think the suggested scheme is more intuitive in that regard.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21683#issuecomment-2435895954

From aivanov at openjdk.org  Thu Oct 24 17:26:47 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 17:26:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>

On Thu, 24 Oct 2024 13:19: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 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

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/Desktop.java line 713:

> 711:      * {@code Info.plist}.
> 712:      *
> 713:      * @param printFileHandler handler

Suggestion:

     * @param printFileHandler handler
     *

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.

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.

src/java.desktop/share/classes/java/awt/Font.java line 1613:

> 1611:      * interpreted as a {@code Font} object according to the
> 1612:      * specification of {@code Font.decode(String)}
> 1613:      * If the specified property is not found then null is returned instead.

Suggestion:

     * If the specified property is not found, null is returned instead.

The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.

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.

src/java.desktop/share/classes/java/awt/Font.java line 1781:

> 1779:      * The property value should be one of the forms accepted by
> 1780:      * {@code Font.decode(String)}
> 1781:      * If the specified property is not found then the {@code font}

Suggestion:

     * If the specified property is not found, the {@code font}

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?

src/java.desktop/share/classes/java/beans/Expression.java line 1:

> 1: /*

Needs copyright year update.

src/java.desktop/share/classes/java/beans/PropertyEditorManager.java line 71:

> 69:      *
> 70:      * @param targetType   the class object of the type to be edited
> 71:      * @param editorClass  the class object of the editor classs

Suggestion:

     * @param editorClass  the class object of the editor class

Typo with an extra ?s?. The line should remain unchanged.

src/java.desktop/share/classes/javax/swing/JTable.java line 6343:

> 6341:      *                           <code>GraphicsEnvironment.isHeadless</code>
> 6342:      *                           returns <code>true</code>
> 6343:      *          method disallows this thread from creating a print job request

Suggestion:


One more line to remove here.

src/java.desktop/share/classes/javax/swing/WindowConstants.java line 1:

> 1: /*

Needs updating the copyright year.

test/jdk/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java line 28:

> 26:   @key headful
> 27:   @bug       6785058
> 28:   @summary   Tests that an owner is activated on closing its owned dialog with the warning icon.

Does this test remain relevant without the security manager? Without the security manager, there will be no dialogs with the warning icon.

test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java line 1:

> 1: /*

Copyright year needs updating.

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?

test/jdk/java/beans/XMLEncoder/6777487/TestCheckedCollection.java line 1:

> 1: /*

Copyright years need updating.

test/jdk/java/beans/XMLEncoder/ReferenceToNonStaticField.java line 29:

> 27:  * @test
> 28:  * @bug 8060027
> 29:  * @run main/othervm ReferenceToNonStaticField

Other tests in the set removed `/othervm`. Is it left intentionally?

test/jdk/java/beans/XMLEncoder/Test4631471.java line 28:

> 26:  * @bug 4631471 6972468
> 27:  * @summary Tests DefaultTreeModel encoding
> 28:  * @run main/othervm Test4631471

Other tests in the set removed `/othervm`. Is it left intentionally?

Looks like this question applies to all tests in `XMLEncoder/` directory.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2392963469
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815168399
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815180719
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815184053
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815185648
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815187240
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815203856
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815290263
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815294333
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815320927
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815330072
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815362826
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815404801
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815414445
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815434082
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815439684
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815440669

From aivanov at openjdk.org  Thu Oct 24 17:30:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 17:30:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
 <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
Message-ID: <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>

On Wed, 23 Oct 2024 02:56:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Agreed. This is not a "clean up / update tests" task.
>> If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
>> Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.
>
> I know this is not relevant to SM and would not have pointed it out had it not been modified in the PR..
> In some tests as I am going to point out below, the order is changed intentionally even though it does not have anything to do with SM, all I am asking it to restore it back in those tests (and since it will look odd to have different order in different tests, I generalize it all for all javax_swing tests in this PR which is what I reviewed)

> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

Did we agree on that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815457993

From jvernee at openjdk.org  Thu Oct 24 17:41:06 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 24 Oct 2024 17:41:06 GMT
Subject: RFR: 8342958: Use jvmArgs consistently in microbenchmarks
In-Reply-To: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>
References: <nbE_ka0bhdvsZWlmsICbpTHk0WsHapd68nr8A3X5H-E=.f3fec666-2825-47bc-b534-0d894d54258c@github.com>
Message-ID: <5X1PC1riWwOSgqBXF8tJRwqiXgZKZTOltDj_DEUISyU=.ffb929d0-9820-43a6-8e2e-20c3a5fb399c@github.com>

On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM reasonable or necessary flags, but when deploying and running micros we often want to add or replace flags to tune to the machine, test different GCs, etc. The inconsistent use of the different `jvmArgs` options make it error prone, and we've had a few recent cases where we've not been testing with the expected set of flags. 
> 
> This PR suggests using `jvmArgs` consistently. I think this aligns with the intuition that when you use `jvmArgsAppend/-Prepend` intent is to add to a set of existing flags, while if you supply `jvmArgs` intent is "run with these and nothing else". Perhaps there are other opinions/preferences, and I don't feel strongly about which to consolidate to as long as we do so consistently. One argument could be made to consolidate on `jvmArgsAppend` since that one is (likely accidentally) the current most popular (143 compared to 59 `jvmArgsPrepend` and 18 `jvmArgs`).

Overall I like the idea. I took a look at the `foreign` benchmarks in particular, and don't see any issues with them.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21683#pullrequestreview-2393339018

From jbhateja at openjdk.org  Thu Oct 24 17:41:16 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 24 Oct 2024 17:41:16 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <vo7yaqOXbMBtIITyjIIYq-DQqL25Y6noa2PBRdW1fMU=.99921f1a-fd0c-44ce-840a-ea342adeb7ab@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
 <nnaFH_ZysJZAU9C7Oo8BeTxyTFyDP5k-E4UH71NV31o=.261fd26e-7513-4e6b-99a0-96e92a80300f@github.com>
 <xho7AbRfmyy-_XlCUIEZI2s4m1uq6uTpmunrRp6zrI4=.7c4208a4-4657-447d-bcf3-b757675592c3@github.com>
 <vo7yaqOXbMBtIITyjIIYq-DQqL25Y6noa2PBRdW1fMU=.99921f1a-fd0c-44ce-840a-ea342adeb7ab@github.com>
Message-ID: <9FAHfjE1Kq9dlE7RRWdqnXZYGQ0SXVevZi4EWuYinv0=.28778d36-1a8e-408c-a447-adc963cdd1b8@github.com>

On Thu, 24 Oct 2024 14:04:32 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Desirable future extension, but its not related to this specific PR.
>
> Well, here it would be especially interesting, because it would tell us if we have a `sub` or an `add`.

Lets address it in a follow up PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815473182

From honkar at openjdk.org  Thu Oct 24 18:01:47 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 18:01:47 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: <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>

On Thu, 24 Oct 2024 17:16:54 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/XMLEncoder/ReferenceToNonStaticField.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 8060027
>> 29:  * @run main/othervm ReferenceToNonStaticField
> 
> Other tests in the set removed `/othervm`. Is it left intentionally?

@aivanov-jdk 
It was missed when -Djava.security.manager=allow was removed. 
Out of curiosity: does it affect the performance of CI testing if tests are run in `/othervm` mode when it is not needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815499279

From honkar at openjdk.org  Thu Oct 24 18:12:41 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 18:12:41 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: <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>

On Thu, 24 Oct 2024 14:55:57 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
>
> src/java.desktop/share/classes/java/awt/Desktop.java line 713:
> 
>> 711:      * {@code Info.plist}.
>> 712:      *
>> 713:      * @param printFileHandler handler
> 
> Suggestion:
> 
>      * @param printFileHandler handler
>      *
> 
> 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.

@seanjmullan Can you please advice on some of these src file javadoc related clean-up review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815510916

From rriggs at openjdk.org  Thu Oct 24 18:30:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 18:30:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>

On Fri, 18 Oct 2024 19:03:30 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 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/java.base/share/classes/java/io/FilePermission.java line 71:

> 69:  *
> 70:  * @apiNote
> 71:  * This permission cannot be used for controlling access to resources anymore

The word "anymore" is unnecessary.

src/java.base/share/classes/java/io/SerializablePermission.java line 40:

> 38:  *
> 39:  * @apiNote
> 40:  * This permission cannot be used for controlling access to resources anymore

Unnecessary "anymore"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811333130
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811338244

From jvernee at openjdk.org  Thu Oct 24 18:34:34 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 24 Oct 2024 18:34:34 GMT
Subject: RFR: 8342963: TestLargeStub::testUpcall doesn't test upcalls stubs
Message-ID: <4v3pSjmkMF8A7UxoVvkwQsNt_4PG4NvjkHv9tCVGEhs=.f37c49c9-9c44-429b-9627-197476d1e52a@github.com>

We were made aware of the fact the `TestLargeStub::testUpcall` was not actually calling `Linker::upcallStub`. This PR addresses that issue.

-------------

Commit messages:
 - Call upcallStub method in TestLargeStub::upcallStub

Changes: https://git.openjdk.org/jdk/pull/21691/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21691&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342963
  Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21691/head:pull/21691

PR: https://git.openjdk.org/jdk/pull/21691

From rriggs at openjdk.org  Thu Oct 24 18:37:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 18:37:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
 <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>
Message-ID: <WP5Y8HfjmKGYOHZjnGID9Uj3_RcqBwlETVZqhbyLuoY=.b97320ba-8fa4-4ee6-bbeb-4fd9178bc3e8@github.com>

On Wed, 23 Oct 2024 21:54:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:
>> 
>>> 239:         Properties props = System.getProperties();
>>> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
>>> 241:         System.setSecurityManager(new SecurityMan());
>> 
>> I assume SecurityMan should be removed too.
>
> Yes, and the comments that say "no SM" should be updated. @RogerRiggs can you take a look at this? Thanks.

Fix to ExecCommand pushed to the sandbox.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815540092

From coleenp at openjdk.org  Thu Oct 24 19:03:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 19:03:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>

On Thu, 24 Oct 2024 03:38:21 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:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

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/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/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 1552:

> 1550:   assert(!cont.is_empty(), "");
> 1551:   // This is done for the sake of the enterSpecial frame
> 1552:   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/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 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.

-------------

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_r1814084085
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_r1815445109
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815479877

From coleenp at openjdk.org  Thu Oct 24 19:03:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 19:03:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
In-Reply-To: <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@github.com>
Message-ID: <uOEk1wWFaFw278TYc_e7vn63TD7Ym3upyk2Yh7RJIhA=.5f1d73df-e4d9-4220-aa30-5f825bd73bde@github.com>

On Wed, 23 Oct 2024 17:26: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 three additional commits since the last revision:
> 
>  - Rename timedWaitNonce to timedWaitSeqNo
>  - Fix comment in Thread.java
>  - Clear oops when thawing lockstack + add thaw_lockstack()

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.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2390813935

From duke at openjdk.org  Thu Oct 24 19:16:41 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Thu, 24 Oct 2024 19:16:41 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
Message-ID: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>

This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.

Current behaviour of `javap` differs with and without `-verbose` in the following way:
**Command**: `javap -c -XDdetails:stackMaps A.class`

Without `-verbose`


...
  public void a();
    Code:
       0: iconst_0
       1: istore_1
    StackMap locals:  this int
    StackMap stack:
...


With `-verbose`


...
  public void a();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=1
         0: iconst_0
         1: istore_1
      StackMap locals:  this int
      StackMap stack:
...


With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.

In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.

---

Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.


void writeSimple(CodeAttribute attr) {
        println("Code:");
        indent(+1);
        writeInstrs(attr);
        writeExceptionTable(attr);
        indent(-1);
    }


---

Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

-------------

Commit messages:
 - 8034066: fix indentation in javap Code section details

Changes: https://git.openjdk.org/jdk/pull/21685/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21685&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8034066
  Stats: 245 lines in 3 files changed: 245 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21685/head:pull/21685

PR: https://git.openjdk.org/jdk/pull/21685

From jvernee at openjdk.org  Thu Oct 24 19:16:41 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 24 Oct 2024 19:16:41 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
Message-ID: <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>

On Thu, 24 Oct 2024 14:57:19 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
> 
> Current behaviour of `javap` differs with and without `-verbose` in the following way:
> **Command**: `javap -c -XDdetails:stackMaps A.class`
> 
> Without `-verbose`
> 
> 
> ...
>   public void a();
>     Code:
>        0: iconst_0
>        1: istore_1
>     StackMap locals:  this int
>     StackMap stack:
> ...
> 
> 
> With `-verbose`
> 
> 
> ...
>   public void a();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          1: istore_1
>       StackMap locals:  this int
>       StackMap stack:
> ...
> 
> 
> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
> 
> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
> 
> ---
> 
> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
> 
> 
> void writeSimple(CodeAttribute attr) {
>         println("Code:");
>         indent(+1);
>         writeInstrs(attr);
>         writeExceptionTable(attr);
>         indent(-1);
>     }
> 
> 
> ---
> 
> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

I think I prefer your idea of keeping the code inside `CodeWriter`.

Maybe have a `write` and a `writeVerbose`, and have a private method with a `boolean` param that controls printing of extra info?

test/langtools/tools/javap/8034066/T8034066.java line 37:

> 35: import java.util.regex.Pattern;
> 36: 
> 37: public class T8034066 {

Please don't continue the old practice of naming tests after their bug ID. It obfuscates which test class does what (both in the source code and in the test logs). Suggestion for name: `TestStackMapDetailsIndent`

test/langtools/tools/javap/8034066/T8034066.java line 44:

> 42:     public void run() throws IOException {
> 43:         String output = javap();
> 44: 

Could you put a comment here that roughly shows what the expected output looks like? I think it would help readers understand what the following three lines are looking for.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21685#pullrequestreview-2393197370
PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815355517
PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815380775

From rriggs at openjdk.org  Thu Oct 24 19:23:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 19:23:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <u1-uOqM_jiV8EcaC7dsfCwCQiUjiQVcgHL2XfvTbXBg=.33981b17-c4df-435d-87fe-b552e2fabbb8@github.com>

On Thu, 24 Oct 2024 13:19: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 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

Reviewed java.io... changes in classes and tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2436170029

From jlahoda at openjdk.org  Thu Oct 24 19:32:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 24 Oct 2024 19:32:29 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln()
Message-ID: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>

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

-------------

Commit messages:
 - Adding support for IO.readln()
 - 8342936: Enhance java.io.IO with parameter-less println()

Changes: https://git.openjdk.org/jdk/pull/21693/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21693&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342936
  Stats: 214 lines in 13 files changed: 197 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21693/head:pull/21693

PR: https://git.openjdk.org/jdk/pull/21693

From darcy at openjdk.org  Thu Oct 24 19:36:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 24 Oct 2024 19:36:05 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <C7bEaXoK5m7U1dx10KUM-56dwGBKOh0-x_vtV3T2dpg=.d6c51bc6-0a33-4568-8188-78de35125012@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Changes in java.compiler look fine.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2393555695

From rriggs at openjdk.org  Thu Oct 24 19:43:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 19:43:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>

On Thu, 24 Oct 2024 13:19: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 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

Reviewed rmi classes and tests
Reviewed ProcessBuilder, ProcessHandler, and Runtime.exec classes and tests

src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java line 342:

> 340:         /*
> 341:          * There is no security manager, so disable access to RMI class
> 342:          * loaders and use the would-de parent instead.

Fix typo "would-de" -> "would-be".

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2393555484
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815601635

From vklang at openjdk.org  Thu Oct 24 19:47:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 24 Oct 2024 19:47:05 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview
In-Reply-To: <ITbJz-c7M0Ow0nU-Bf6MjNw785FwOsDRKewU1Aa4c-4=.88a52b99-7b8c-41b8-ad35-9c79b799e95e@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <ITbJz-c7M0Ow0nU-Bf6MjNw785FwOsDRKewU1Aa4c-4=.88a52b99-7b8c-41b8-ad35-9c79b799e95e@github.com>
Message-ID: <kbhGBwR9Ne-Hab7YLaQH1lhpK5JQGo-dWU71qBBwPM8=.b2f9ed82-3a61-445f-a37e-1315f50b9eb3@github.com>

On Thu, 24 Oct 2024 16:42:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 79:
> 
>> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
>> 78:         CLASSFILE_API,
>> 79:         STREAM_GATHERERS,
> 
> Does bootcycle fail if this enum constant is removed?

Yep :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21686#discussion_r1815612773

From asemenyuk at openjdk.org  Thu Oct 24 20:07:06 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 24 Oct 2024 20:07:06 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v4]
In-Reply-To: <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
 <XS2eBT6hEVsUkFb__dBZfqy5SWjvEMxrGHGQGKaaQ20=.2ac8b001-055a-49b9-866c-3ab7b08ed1db@github.com>
Message-ID: <mQHQ7H2D1pYvEpQnZL_9gxqv_ldofGAJKcgLXcVDf6U=.cf238586-1853-4e12-8040-4a48e29e708f@github.com>

On Fri, 18 Oct 2024 14:42:39 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make jpackage correctly handle the output directory (`--dest`) that is:
>>  - a subdirectory of the input directory;
>>  - the same as the input directory.
>> 
>> Make jpackage correctly handle temp directory (`--temp`) that is:
>>  - a subdirectory of the input directory.
>> 
>> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
>> 
>> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
>> 
>> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
>> 
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
>> 
>> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Files.isSameFile() throws exception if a file doesn't exist

For `--mac-dmg-content` I think we can just test that jpackage doesn't dive into an infinite spiral:

`jpackage --input in --dest . --mac-dmg-content in`
`jpackage --input in --dest . --mac-dmg-content .`
`jpackage --input in --dest . --mac-dmg-content in/foo`
`jpackage --input in --dest . --name Foo --mac-dmg-content Foo.app`

For `--app-content` we can do the same as for the `--mac-dmg-content`:

`jpackage --input in --dest . --app-content in`
`jpackage --input in --dest . --app-content .`
`jpackage --input in --dest . --app-content in/foo`
for linux & windows: `jpackage --input in --dest . --name Foo --app-content Foo`
for mac: `jpackage --input in --dest . --name Foo --app-content Foo.app`

I don't see a point in making jpackage handle these weird command lines predictably except not falling into an infinite copying spiral. That said the tests will not verify the contents of app images produced by these commands.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21550#issuecomment-2436241905

From jiangli at openjdk.org  Thu Oct 24 20:20:08 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Oct 2024 20:20:08 GMT
Subject: RFR: 8342642: Class loading failure due to archived map issue in
 ModuleLoaderMap.Mapper
In-Reply-To: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
References: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
Message-ID: <nwhzx5Bh9fK6gNjlqigk7vU3BsBvzI-BBDNwOkerzr8=.6a1dc8a4-98e4-4a61-a10b-44dfa9494777@github.com>

On Wed, 23 Oct 2024 22:14:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix that uses String type for the mapped value in ModuleLoaderMap.Mapper map (Map<String, String>). Please see details in https://bugs.openjdk.org/browse/JDK-8342642, thanks.

I brought up this issue in today's Leyden/premain meeting. There was a good discussion on the specific issue, and the general Integer cache archiving and identity hash problem. The conclusion was it's better to avoid using boxed Integer and go with String in ModuleLoaderMap.Mapper.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21672#issuecomment-2436262114

From aivanov at openjdk.org  Thu Oct 24 20:26:44 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 20:26:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@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>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
Message-ID: <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>

On Thu, 24 Oct 2024 17:58:55 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> It was missed when `-Djava.security.manager=allow` was removed.

It wasn't intentional then, was it?

> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?

I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.

Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.

https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49

It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815652996

From aivanov at openjdk.org  Thu Oct 24 20:30:39 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 20:30:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@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>
Message-ID: <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>

On Thu, 24 Oct 2024 18:09:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Desktop.java line 713:
>> 
>>> 711:      * {@code Info.plist}.
>>> 712:      *
>>> 713:      * @param printFileHandler handler
>> 
>> Suggestion:
>> 
>>      * @param printFileHandler handler
>>      *
>> 
>> ~~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_.
>
> @seanjmullan Can you please advice on some of the following src file javadoc related review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.

@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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815657461

From dl at openjdk.org  Thu Oct 24 20:41:46 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 24 Oct 2024 20:41:46 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v5]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <7z5sxU8bf7S6mIlyzd0li2i6GKAxzLWE5J9Tlq4Ym4Q=.2ed1cd3d-dc79-48f7-9127-633a7ae106d0@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:

  For starvation check #2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/dcbfc1f7..b35cc63c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=03-04

  Stats: 18 lines in 1 file changed: 7 ins; 0 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 mullan at openjdk.org  Thu Oct 24 21:00:39 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 21:00:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@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>
Message-ID: <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@github.com>

On Thu, 24 Oct 2024 20:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @seanjmullan Can you please advice on some of the following src file javadoc related review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.
>
> @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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815686941

From pchilanomate at openjdk.org  Thu Oct 24 21:08:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:08:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
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: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@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 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()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/03ba6dfb..c7a82c45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=07-08

  Stats: 66 lines in 10 files changed: 2 ins; 37 del; 27 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 Oct 24 21:08:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:08:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@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>
Message-ID: <DEan9Tspd0UIgQiYMSha9fLGDa0BLD6wEa2w1en9bmg=.dd579010-ff63-4927-ab2c-5972e178b785@github.com>

On Thu, 24 Oct 2024 02:41:43 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:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815693906

From honkar at openjdk.org  Thu Oct 24 21:10:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 21:10:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@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>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
 <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
Message-ID: <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>

On Thu, 24 Oct 2024 20:23:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk 
>> It was missed when -Djava.security.manager=allow was removed. 
>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in `/othervm` mode when it is not needed?
>
>> It was missed when `-Djava.security.manager=allow` was removed.
> 
> It wasn't intentional then, was it?
> 
>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?
> 
> I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.
> 
> Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.
> 
> https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49
> 
> It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.

@aivanov-jdk 
Right, it wasn't intentionally but missed when removing `-Djava.security.manager=allow`.

> Anyway, removing /othervm isn't strictly required because java/beans are run in othervm mode.

Thank you for clarifying. Since `/othervm` doesn't impact the beans tests I'll keep it as-is. Let me know if you still think it is good to remove, I can probably do a replace-all on beans/XMLEncoder/ folder.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815694898

From pchilanomate at openjdk.org  Thu Oct 24 21:17:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
 <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
 <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>
Message-ID: <pTM3f2szGU_CSb0ASohOPwIKQQjLpKyquSrfFjCmpew=.3e7e9e9f-ae59-4a6c-b944-19324445d944@github.com>

On Thu, 24 Oct 2024 06:18:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697784

From pchilanomate at openjdk.org  Thu Oct 24 21:17:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>
Message-ID: <gLdoEBbkdZ34VkSGPRJ9GVsSE3guDPf_s8Rk0eiv6N8=.6b76a553-a3e5-4330-8f24-8ee5647dc9da@github.com>

On Thu, 24 Oct 2024 08:08:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> 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  Thu Oct 24 21:17:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
Message-ID: <K_hfNhC2_eMjYjNAZQbT9dL7pGz7cdcfKas7rSbigbA=.f6ef4f24-3473-47c9-833f-c9158457fdcd@github.com>

On Thu, 24 Oct 2024 05:10:56 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:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> 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/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`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700441
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701043

From pchilanomate at openjdk.org  Thu Oct 24 21:17:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
Message-ID: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@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 pchilanomate at openjdk.org  Thu Oct 24 21:17:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@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>
Message-ID: <i2BRCkPmAaFopJCUHlnUjKlaahQbwnifHjvu6GiMh7U=.88f208d9-eb95-464c-860e-0f7eab6d3e7d@github.com>

On Thu, 24 Oct 2024 02:57:18 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:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> 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 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_r1815699934
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700312

From jiangli at openjdk.org  Thu Oct 24 21:23:04 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Oct 2024 21:23:04 GMT
Subject: RFR: 8342642: Class loading failure due to archived map issue in
 ModuleLoaderMap.Mapper
In-Reply-To: <uQOrLdzHHGFc7GGCBl1XGucRfBFgrgCsUKl6e429Pi4=.c6939582-9d0c-4369-a0b7-99aca94e2787@github.com>
References: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
 <Uy7sY_UaGyqS8dliTx1fbvEy_4_HuEDVgb2ZiirMIbw=.afbc0f19-1431-47a6-aec7-b71d1c686773@github.com>
 <uQOrLdzHHGFc7GGCBl1XGucRfBFgrgCsUKl6e429Pi4=.c6939582-9d0c-4369-a0b7-99aca94e2787@github.com>
Message-ID: <CN35o-nur_x4gzjcNPHA1x7nh2CSdKDQylstjuE4wqo=.0f1d2a64-869f-4ec7-8dae-d349b763b436@github.com>

On Thu, 24 Oct 2024 05:51:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> @iklam Would it be possible to comment on this?  If the system properties to configure the range of integer cache are set at runtime, does it just not use this archived object graph? I'm wondering if it should disable CDS?
>
>> @iklam Would it be possible to comment on this? If the system properties to configure the range of integer cache are set at runtime, does it just not use this archived object graph? I'm wondering if it should disable CDS?
> 
> A better fix would be:
> 
> If runtime java.lang.Integer.IntegerCache.high < dumptime java.lang.Integer.IntegerCache.high
>   -- copy the initial elements from the dumptime cache array
>   -- fill the rest of the cache array
> 
> that way, we will still preserve the object identity of the Integers created during dump time.
> 
> I think we need to do the same thing for the other box cases.

> > > @iklam Would it be possible to comment on this? If the system properties to configure the range of integer cache are set at runtime, does it just not use this archived object graph? I'm wondering if it should disable CDS?
> > 
> > 
> > A better fix would be:
> > If runtime java.lang.Integer.IntegerCache.high < dumptime java.lang.Integer.IntegerCache.high -- copy the initial elements from the dumptime cache array -- fill the rest of the cache array
> > that way, we will still preserve the object identity of the Integers created during dump time.
> > I think we need to do the same thing for the other box cases.
> 
> I've been thinking about something like that as a longer term fix after this quick fix. However, there are some complications, e.g.:
> 
> When an archived boxed Integer instance is 'used' in a pre-initialized class static field's sub-graph, depending on the runtime IntegerCache.high specified by the system property, the specific 'used' Integer may not be within the runtime range (used_Integer > IntegerCache.high). In that case, the runtime modified cache does not contain the archived boxed Integer instance. Then, the usage of the archived instance is invalid, which causes the corresponding pre-initialized static field to still be problematic. For this loader map, in an extreme example (unlikely to happen) when runtime IntegerCache.high=1, it would still not work well. For such cases, we would need to invalidate the pre-initialized static field or class. That's the reason I mentioned filing a separate bug for the archived Integer cache and evaluating together with the general AOT cache work, see https://bugs.openjdk.org/browse/JDK-8342642?focusedId=14714939&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acommen
 t-tabpanel#comment-14714939.

I just re-looked at the [IntegerCache](https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/src/java.base/share/classes/java/lang/Integer.java#L961) code, I need to take the above back. Unlike I remembered, IntegerCache doesn't recreate the cache if runtime cache length () is **less** than the archived cache:


   if (archivedCache == null || size > archivedCache.length) {
      // re-create
  }


In that sense, I think we don't have a risk of potentially with `used_Integer > IntegerCache.high`. The idea described in Ioi's comment above (also brought up by Aleksey Shipilev separately during premain meeting) could be sufficient.

Anyway moving away from archived boxed Integer and identity hash comparison in this case is safer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21672#issuecomment-2436358591

From ihse at openjdk.org  Thu Oct 24 22:10:05 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 24 Oct 2024 22:10:05 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: <cVv-wFm8QKGffdCPHJwPV4F4NtWO1w76oK2BJvDFUt8=.b7f4a083-9743-4d0b-874f-06a4e2d72f8a@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

make/autoconf/flags-cflags.m4 line 589:

> 587:   # CXXFLAGS C++ language level for all of JDK, including Hotspot.
> 588:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
> 589:     LANGSTD_CXXFLAGS="-std=c++14"

Is this really an intention on your part, to bump the C++ level inside a PR to remove unused code? ? Or is it a merge error from a different PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21655#discussion_r1815752670

From ihse at openjdk.org  Thu Oct 24 22:15:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 24 Oct 2024 22:15:08 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
Message-ID: <blGOVgYqxowsDcbJcsqn-2e0zsKV2UzmAHvmWYw-ZGc=.d8eb7778-994a-4ed1-949e-3b995b2406a1@github.com>

On Thu, 24 Oct 2024 14:22:28 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8342682

All the original labels are still there. A better approach had probably been to close the PR and open a new. You either need to do that now, or delete all the irrelevant labels. (I can't be bothered to figure out; at least build is wrong.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2436431780

From dholmes at openjdk.org  Thu Oct 24 22:16:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 22:16:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
 <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
 <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@github.com>
Message-ID: <uhNEFqOmOPAUXR5vCaSiMeOvh23OjcpBiUgxjZ5PByU=.6bcb0a5f-e0e1-4ed3-b5d8-b470e2859375@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 dholmes at openjdk.org  Thu Oct 24 22:16:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 22:16:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzu
 Zr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
Message-ID: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@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 honkar at openjdk.org  Thu Oct 24 22:27:40 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 22:27:40 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: <gIwlmNzUQN7CM7jX7Tq5CQkS1Ay_fWsPrZABjIRdHeo=.ba7f210c-8a6a-4e47-9c00-830476aa158b@github.com>

On Thu, 24 Oct 2024 16:35:44 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/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java line 28:
> 
>> 26:   @key headful
>> 27:   @bug       6785058
>> 28:   @summary   Tests that an owner is activated on closing its owned dialog with the warning icon.
> 
> Does this test remain relevant without the security manager? Without the security manager, there will be no dialogs with the warning icon.

Looks like the test was created for SM specific issue - [JDK-6785058](https://bugs.openjdk.org/browse/JDK-6785058). I have deleted the test here https://github.com/openjdk/jdk-sandbox/commit/de0a0f67ef207e1d217c42c312a4378f9f7fa833

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815770344

From honkar at openjdk.org  Thu Oct 24 22:31:41 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 22:31:41 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: <C6AQiFYXzD9ov3ZvyWThfp_FUec5f-cLLOyPkqLBeeE=.f3c888ca-d459-44ad-9c18-2329869ffa18@github.com>

On Thu, 24 Oct 2024 16:11:18 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
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 6343:
> 
>> 6341:      *                           <code>GraphicsEnvironment.isHeadless</code>
>> 6342:      *                           returns <code>true</code>
>> 6343:      *          method disallows this thread from creating a print job request
> 
> Suggestion:
> 
> 
> One more line to remove here.

Relevant (w.r.t jep486) javadocs changes have been updated here: https://github.com/openjdk/jdk-sandbox/commit/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815773023

From amenkov at openjdk.org  Thu Oct 24 23:05:07 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 24 Oct 2024 23:05:07 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v11]
In-Reply-To: <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>
Message-ID: <aZhg_op6XpuDqW9ToM_CcQgZLrZKb_aoY5OpttkkOlQ=.ce0df356-b718-40c3-ab1d-7b5115296746@github.com>

On Thu, 24 Oct 2024 14:52:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: removed asserts from continuationFreezeThaw.cpp again

src/hotspot/share/prims/jvmtiEnvBase.cpp line 667:

> 665: 
> 666: javaVFrame*
> 667: JvmtiEnvBase::check_and_skip_hidden_frames(bool is_in_VTMS_transition, javaVFrame* jvf) {

reworked function looks much better! Now it's clear what the function does and I have a question what it should do.
The function checks `@JvmtiMountTransition` annotation first even if the thread is in transition.
If `@JvmtiMountTransition` is present, the code doesn't care about `@ChangesCurrentThread` (and doesn't case about `@JvmtiMountTransition` if in_transition + `@ChangesCurrentThread`).
But we have 2 methods in VirtualThread class (`switchToCarrierThread()` and `switchToVirtualThread()`) with both annotations.
So if the function is called when `switchToCarrierThread` is on top, the function skips this frame, but if the thread calls some other function without `@JvmtiMountTransition` annotation from `switchToCarrierThread`, the function returns `switchToCarrierThread`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1815790409

From jiangli at openjdk.org  Thu Oct 24 23:14:09 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Oct 2024 23:14:09 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <N2aJZCe4omsgw1E7s46gAKTEJ_h5xUKeOVxYrkf4EFA=.2b9e15c2-4154-48ca-a75d-4fa04323a710@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <HqG0Q7lavlhlPNp6BJKIori-X7CHK7hfbZ5TPyMCsa0=.b19903ef-b490-4909-8142-37da8d5b9ffc@github.com>
 <N2aJZCe4omsgw1E7s46gAKTEJ_h5xUKeOVxYrkf4EFA=.2b9e15c2-4154-48ca-a75d-4fa04323a710@github.com>
Message-ID: <9Zl_5SycthY0QWHqfuyHiOaH4nzVM7ngWRGuqNBuM6g=.31fbe17e-1c86-4ace-9322-7a1b942d2e9e@github.com>

On Wed, 23 Oct 2024 01:40:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.
> > I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.
> > @jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.
> 
> @magicus I just noticed your above notes now (I'm been chasing an unrelated long G1 Evacuation Pause issue). I'll test your changes tomorrow. Will update you in the thread.

Sorry for the delay. I finally found some time to look into this today. Running the latest `static-jdk` `bin/java` built from your branch fails for me as well:


$ bin/java
Error: failed , because bin/java: undefined symbol: JNI_CreateJavaVM


I only took a quick look, but I think this looks like https://bugs.openjdk.org/browse/JDK-8339522 that I filed in September.


$ nm bin/java | grep JNI_CreateJavaVM
000000000162733c t JNI_CreateJavaVM
0000000001626e75 t _ZL22JNI_CreateJavaVM_innerPP7JavaVM_PPvS2_
jianglizhou at leia:~/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk$ nm -D bin/java | grep JNI_CreateJavaVM


The VM dynamic symbols are not exported properly. This is related to the https://github.com/openjdk/jdk/pull/20837#discussion_r1744611776 discussion comment thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2436496612

From dl at openjdk.org  Thu Oct 24 23:27:33 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 24 Oct 2024 23:27:33 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v6]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <bNWMein_ut4FagkzftrYz-8ft_W1maADC2dTuOypAzc=.861e89b6-0ec2-4212-a639-93a176192e6e@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:

  For starvation check #3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/b35cc63c..409cf500

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=04-05

  Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 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  Thu Oct 24 23:39:07 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 24 Oct 2024 23:39:07 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
Message-ID: <xMfGwygwvEEqpdyRINSpxEFWIgv_Rnu0ccet-vOITcA=.efa2cc8a-bb0e-43b4-bf3a-27fcd3367a38@github.com>

On Tue, 15 Oct 2024 20:22:52 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:
> 
>   Don't hardcode server variant

> > > When trying to sort out the LDFLAGS issues, it turned out that I could not run the linux launcher at all, not even when checking out older commits of this PR. I am almost at a loss here; I assume that this worked when I created this PR (even though I only did ad hoc testing at the time), and I'm not sure if my testing then was inadequate or if something else has changed during that time with my environment.
> > > I'm trying to retrace my steps in how I got to this branch, but I have unfortunately deleted much of the intermediate steps.
> > > @jianglizhou Can you check if you can build and run a simple HelloWorld.java with the static launcher in this PR on linux? `images/static-jdk/bin/java --version` works for me, but not `images/static-jdk/bin/java HelloWorld.java`, which fails with an error that indicates it cannot locate the jimage library.
> > 
> > 
> > @magicus I just noticed your above notes now (I'm been chasing an unrelated long G1 Evacuation Pause issue). I'll test your changes tomorrow. Will update you in the thread.
> 
> Sorry for the delay. I finally found some time to look into this today. Running the latest `static-jdk` `bin/java` built from your branch fails for me as well:
> 
> ```
> $ bin/java
> Error: failed , because bin/java: undefined symbol: JNI_CreateJavaVM
> ```
> 
> I only took a quick look, but I think this looks like https://bugs.openjdk.org/browse/JDK-8339522 that I filed in September.
> 
> ```
> $ nm bin/java | grep JNI_CreateJavaVM
> 000000000162733c t JNI_CreateJavaVM
> 0000000001626e75 t _ZL22JNI_CreateJavaVM_innerPP7JavaVM_PPvS2_
> jianglizhou at leia:~/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk$ nm -D bin/java | grep JNI_CreateJavaVM
> ```
> 
> The VM dynamic symbols are not exported properly. This is related to the [#20837 (comment)](https://github.com/openjdk/jdk/pull/20837#discussion_r1744611776) discussion comment thread.

Checking the `ld` command line, I think it is indeed https://bugs.openjdk.org/browse/JDK-8339522 issue. `-Wl,--exclude-libs,ALL` is included in the command:

$ cat ./support/static-native/launcher/BUILD_LAUNCHER_java_run_ld.cmdline
/usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,--no-as-needed -Wl,-z,noexecstack -m64 -pie -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,--no-as-needed -Wl,--exclude-libs,ALL -Wl,-z,noexecstack -m64 -Wl,-rpath,$ORIGIN -Wl,--disable-new-dtags -Wl,-rpath,$ORIGIN/../lib -Wl,--disable-new-dtags -o /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/static-native/launcher/java /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/static-native/launcher/main.o -Wl,--export-dynamic -Wl,--whole-archive /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libverify/static/libverify.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libjava/static/libjava.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libzip/static/libzip.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-sl
 owdebug/support/native/java.base/libjimage/static/libjimage.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libjli/static/libjli.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libnet/static/libnet.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libnio/static/libnio.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libjsig/static/libjsig.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libsyslookup/static/libsyslookup.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.base/libsimdsort/static/libsimdsort.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libawt/static/libawt.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_
 64-server-slowdebug/support/native/java.desktop/libawt_xawt/static/libawt_xawt.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libjawt/static/libjawt.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libmlib_image/static/libmlib_image.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/liblcms/static/liblcms.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libjavajpeg/static/libjavajpeg.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libfontmanager/static/libfontmanager.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.desktop/libjsound/static/libjsound.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.instrument/libinstrume
 nt/static/libinstrument.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.management/libmanagement/static/libmanagement.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.prefs/libprefs/static/libprefs.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.rmi/librmi/static/librmi.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.security.jgss/libj2gss/static/libj2gss.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/java.smartcardio/libj2pcsc/static/libj2pcsc.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.attach/libattach/static/libattach.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.crypto.cryptoki/libj2pkcs11/static/libj2pkcs11.a /...jianglizhou/github/jdk_pull_20837/bu
 ild/linux-x86_64-server-slowdebug/support/native/jdk.hotspot.agent/libsaproc/static/libsaproc.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.incubator.vector/libjsvml/static/libjsvml.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.jdwp.agent/libdt_socket/static/libdt_socket.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.jdwp.agent/libjdwp/static/libjdwp.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.management/libmanagement_ext/static/libmanagement_ext.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.management.agent/libmanagement_agent/static/libmanagement_agent.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.net/libextnet/static/libextnet.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-serve
 r-slowdebug/support/native/jdk.sctp/libsctp/static/libsctp.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/support/native/jdk.security.auth/libjaas/static/libjaas.a /...jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/hotspot/variant-server/libjvm/objs/static/libjvm.a -Wl,--no-whole-archive -lX11 -lXext -lXi -lXrender -lXtst -lasound -ldl -lfreetype -lm -lpthread -lrt -lz -static-libgcc -static-libstdc++ -l:libstdc++.a -lz -ldl -lpthread

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2436518730

From dholmes at openjdk.org  Fri Oct 25 00:14:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Oct 2024 00:14:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
Message-ID: <nl9Di_JEDI2KSzXhFfRJxrsz7XXyYOnTW_j_te2ToeU=.8290bee1-1f3f-44a4-b149-ec1cac7eaf28@github.com>

On Thu, 24 Oct 2024 21:08:26 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 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()

Thanks for updates. (I need to add a Review comment so I get a checkpoint to track further updates.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393910702

From swen at openjdk.org  Fri Oct 25 01:33:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 25 Oct 2024 01:33:17 GMT
Subject: Withdrawn: 8342644: Optimize InvokerBytecodeGenerator for using
 ClassFile API
In-Reply-To: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
References: <5xKK6d8_-bDSWeaRyOHoR-CbOwIRu6lItJDmXVFoftM=.d5ed0957-43da-4427-b285-2d03b05cb6d6@github.com>
Message-ID: <efceqJwFeBYQsRwF-eOQ88leT2EkZLemCwYxyB3AkBg=.dc73e5bb-cfd4-49e2-a1b7-b95a7dbb6179@github.com>

On Fri, 18 Oct 2024 10:01:59 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Cache commonly used classDesc to avoid creating ReferenceClassDescImpl every time

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21580

From henryjen at openjdk.org  Fri Oct 25 01:43:52 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 25 Oct 2024 01:43:52 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
Message-ID: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>

Check output for including values rather than exact match.
Also include the manpage change  and revert the problem list.

-------------

Commit messages:
 - 8342930: New tests from JDK-8335912 are failing

Changes: https://git.openjdk.org/jdk/pull/21697/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21697&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342930
  Stats: 30 lines in 4 files changed: 19 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21697/head:pull/21697

PR: https://git.openjdk.org/jdk/pull/21697

From almatvee at openjdk.org  Fri Oct 25 01:54:39 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 25 Oct 2024 01:54:39 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for
 same reason on older macOS versions
Message-ID: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>

- It is not clear on which macOS versions codesign fails if application bundle contains additional content.
- As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
- This change is for macOS only.
- Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

-------------

Commit messages:
 - 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions

Changes: https://git.openjdk.org/jdk/pull/21698/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21698&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342576
  Stats: 82 lines in 2 files changed: 56 ins; 16 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21698/head:pull/21698

PR: https://git.openjdk.org/jdk/pull/21698

From jbhateja at openjdk.org  Fri Oct 25 02:06:17 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Oct 2024 02:06:17 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v31]
In-Reply-To: <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <CT0jhDxwTzcmgQQECtpVZzFA8ChMeWE84-_NF6i41Ks=.c74c1988-d6c3-478d-baaa-61e8ec9475bd@github.com>
 <SA3xOxzuFvAA8aj5Tg23xs3gSv_LfV5boJCzMHvyizI=.b9a9449a-73cf-4ac6-8f02-ab6875e8d6ff@github.com>
 <uBgKdIf34SCfB7G1iZJOH6Z6GTCUqiNeuZOg1hK7rE0=.ae46ff55-ea10-413c-91e8-234d8911f0bc@github.com>
 <yeKFptYb_oQRSEzSAeo4qdf05f19zU3AKs4_PzgsX8Q=.6f55c1d5-cc8e-4757-aa4a-9e12f842effa@github.com>
 <vPAe6Kr-X9xQ4WebHvw8UCK1AA8JCvR8MopYHl70KQ4=.ef743dc3-e095-402a-a05b-b0d546e5fb2b@github.com>
Message-ID: <8QrQacNaEZcyAYAcGLLzIm4xN-0G1-5BRxmSi__vMBU=.2ffa14a0-9fde-4587-9bc3-6b5bfaef33a0@github.com>

On Thu, 24 Oct 2024 13:41:13 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> To exercise non memory operand pattern we need a vector operation padding layer after load vector, this will always ensure that selector pick all register operands flavor of instruction. Since its a generic limitation, do you think we should float it as a separate PR? 
>> 
>> I have created a new RFE https://bugs.openjdk.org/browse/JDK-8342959  for reference. Given that we have moved IR tests out this PR on the grounds of review complexity, lets not add more code here.
>
> Ok, we can file a separate RFE. Though I really have voiced 2 concerns:
> - Making sure we always test `_mem` and `_reg` variants in the backend. See your https://bugs.openjdk.org/browse/JDK-8342959
> - Making sure we have tests that would detect vectors that are too long. This would require some padding between the vectors, so that we have some untouched space - and if it does get touched we know that a vector was too long. Does that make sense? This is I guess also a general concern - and would have to be applied to all vector instructions.

Hi @eme64 , @PaulSandoz , in general bounds overrun problem is only pertinent to a very small portion of vector ISA which supports memory destination flavor e.g. [VCVTPS2PH](https://www.felixcloutier.com/x86/vcvtps2ph) , in all other cases we only load exact memory size into vector i.e. 4 , 8 and 16 bytes of memory will be loaded into 128 bit vector. Similarly, store vector writes exact memory size and intermediate vector operations with all register operands can operate at equally sized or lowest upper vector size for a given vector species.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1815901472

From jbhateja at openjdk.org  Fri Oct 25 02:11:13 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Oct 2024 02:11:13 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
Message-ID: <KcU5Z1yqIieSNA_yXI2GgVoFR9Mx8_hxTPLnokvfQLg=.b5c261fc-56a9-4bee-a2d9-5b3c434dc09d@github.com>

On Mon, 21 Oct 2024 09:12:25 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replacing flag based checks with CPU feature checks in IR validation test.
>
> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.
> 
> I think these optimizations should be done in a separate PR. I see no reason why they need to be mixed in.
> 
> https://github.com/openjdk/jdk/commit/c56508899b000b8b1eb6755c901798a2a3685ef5 The `UMinVNode::Ideal` etc changes with IR rules.
> 
> I also cannot easily review just such a diff, it does not let me make comments - so I still have to go find the relevant code in the whole PR.
> 
> Some comments on this section:
> 
> 
> Node* UMinVNode::Ideal(PhaseGVN* phase, bool can_reshape) {
>   bool match1 = in(1)->Opcode() == Op_UMinV || in(1)->Opcode() == Op_UMaxV;
>   bool match2 = in(2)->Opcode() == Op_UMinV || in(2)->Opcode() == Op_UMaxV;
>   // UMin (UMin(a, b), UMax(a, b))  => UMin(a, b)
>   // UMin (UMin(a, b), UMax(b, a))  => UMin(a, b)
>   if (match1 && match2) {
>     if ((in(1)->in(1) == in(2)->in(1) && in(1)->in(2) == in(2)->in(2)) ||
>          (in(1)->in(2) == in(2)->in(1) && in(1)->in(1) == in(2)->in(2))) {
>       return new UMinVNode(in(1)->in(1), in(1)->in(2), vect_type());
>     }
>   }
>   return nullptr;
> }
> 
> 
> Are we sure we do not need to verify any types in all of these cases? Maybe not - but I'd rather be super sure - not that things get misinterpreted and then folded the wrong way.
> 
> I mean if I now approve only that diff, then I still need to approve the whole PR, which means I need to spend a lot of time on everything again. Otherwise, in theory people could smuggle anything in.

Hi @eme64 , Let me know if there are other comments, else looking forward to you approval :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2436663568

From asemenyuk at openjdk.org  Fri Oct 25 02:15:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 25 Oct 2024 02:15:03 GMT
Subject: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443
 for same reason on older macOS versions
In-Reply-To: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
References: <r6p-OZMkh6DfZhrsuVXZe8cCC2CT9gIwu2VPv1RRRQ8=.a4ea22b4-f436-43fb-bb77-8438ea7e9c62@github.com>
Message-ID: <RCyA5upd6rCHFLcziWbIoNvCAIcG793_MUdTL2EfN2U=.69ceffea-f2cd-483d-b772-0957d898b9bd@github.com>

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not clear on which macOS versions codesign fails if application bundle contains additional content.
> - As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
> - This change is for macOS only.
> - Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

The test does nothing on OSX, right? We just run jpackage and don't verify the output. What is the point then?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21698#issuecomment-2436667340

From liach at openjdk.org  Fri Oct 25 02:58:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Oct 2024 02:58:04 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
Message-ID: <hx4_aWAXVQRoL6rzjVRVPCT_IN6EgKQ10a8TSsLNojw=.f92a2dfd-8bab-4bb9-8d99-bdb7d27ae25c@github.com>

On Thu, 24 Oct 2024 16:31:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> test/langtools/tools/javap/8034066/T8034066.java line 37:
> 
>> 35: import java.util.regex.Pattern;
>> 36: 
>> 37: public class T8034066 {
> 
> Please don't continue the old practice of naming tests after their bug ID. It obfuscates which test class does what (both in the source code and in the test logs). Suggestion for name: `TestStackMapDetailsIndent`

How about `CodeWriterIndentTest`? We prefer to use prefix modifiers, and this tests the indent for general code writer output.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815928810

From liach at openjdk.org  Fri Oct 25 03:04:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Oct 2024 03:04:06 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
Message-ID: <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>

On Thu, 24 Oct 2024 14:57:19 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
> 
> Current behaviour of `javap` differs with and without `-verbose` in the following way:
> **Command**: `javap -c -XDdetails:stackMaps A.class`
> 
> Without `-verbose`
> 
> 
> ...
>   public void a();
>     Code:
>        0: iconst_0
>        1: istore_1
>     StackMap locals:  this int
>     StackMap stack:
> ...
> 
> 
> With `-verbose`
> 
> 
> ...
>   public void a();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          1: istore_1
>       StackMap locals:  this int
>       StackMap stack:
> ...
> 
> 
> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
> 
> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
> 
> ---
> 
> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
> 
> 
> void writeSimple(CodeAttribute attr) {
>         println("Code:");
>         indent(+1);
>         writeInstrs(attr);
>         writeExceptionTable(attr);
>         indent(-1);
>     }
> 
> 
> ---
> 
> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

test/langtools/tools/javap/8034066/EmptyLoop.jcod line 26:

> 24:  /*
> 25:  * Original source:
> 26:  * public class EmptyLoop {

To reduce test file noise, I recommend adding this as a package-private class to the end of your test file (so not a nested class) after it is renamed, like:


class EmptyLoop {
    public void emptyLoop() {
        for (int i = 0; i < 10; i++) {
        }
    }
}


After that, once your test class is compiled, the `EmptyLoop.class` is available in `test.classes` property directory, so you can remove this jcod and all code that converts the jcod to class.

You can see UndefinedAccessFlagTest for how we use such tricks.

Note: since you will only have one test class, you no longer need a dedicated directory; you can just place our `CodeIndentTest.java` in the root javap directory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815931722

From liach at openjdk.org  Fri Oct 25 03:09:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Oct 2024 03:09:12 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>
Message-ID: <-WqUhwnLhGndoAAvBO-ZxwlvobpDSWH9MFK5M1SYLaQ=.1dd22519-1330-4ee7-b12d-db93c60387b9@github.com>

On Fri, 25 Oct 2024 03:01:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> test/langtools/tools/javap/8034066/EmptyLoop.jcod line 26:
> 
>> 24:  /*
>> 25:  * Original source:
>> 26:  * public class EmptyLoop {
> 
> To reduce test file noise, I recommend adding this as a package-private class to the end of your test file (so not a nested class) after it is renamed, like:
> 
> 
> class EmptyLoop {
>     public void emptyLoop() {
>         for (int i = 0; i < 10; i++) {
>         }
>     }
> }
> 
> 
> After that, once your test class is compiled, the `EmptyLoop.class` is available in `test.classes` property directory, so you can remove this jcod and all code that converts the jcod to class.
> 
> You can see UndefinedAccessFlagTest for how we use such tricks.
> 
> Note: since you will only have one test class, you no longer need a dedicated directory; you can just place our `CodeIndentTest.java` in the root javap directory.

Another example of such a trick is available at [test/jdk/jdk/classfile/ClassBuildingTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/classfile/ClassBuildingTest.java)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1815933828

From jpai at openjdk.org  Fri Oct 25 04:38:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 04:38:06 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
Message-ID: <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>

On Fri, 25 Oct 2024 01:38:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Check output for including values rather than exact match.
> Also include the manpage change  and revert the problem list.

Marked as reviewed by jpai (Reviewer).

test/jdk/tools/jar/MultipleManifestTest.java line 203:

> 201: 
> 202:     private void assertOutputContains(String expected) {
> 203:         Assertions.assertTrue(baos.toString().contains(expected));

The linked JBS issue notes that the test was failing because of the additional (new) log messages from the jar tool itself. So I think the logs will be deterministic (since they aren't being generated by something else other than the jart tool). Using `contains()` thus looks fine to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21697#pullrequestreview-2394147934
PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1815980769

From jpai at openjdk.org  Fri Oct 25 04:38:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 04:38:07 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
 <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>
Message-ID: <D0xaEJ-cNRKBSCU12WtFLryfYjy0vl0wYiOGQG7mjys=.dcad49d2-e244-4b00-908d-c526c1124ed0@github.com>

On Fri, 25 Oct 2024 04:34:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Check output for including values rather than exact match.
>> Also include the manpage change  and revert the problem list.
>
> test/jdk/tools/jar/MultipleManifestTest.java line 203:
> 
>> 201: 
>> 202:     private void assertOutputContains(String expected) {
>> 203:         Assertions.assertTrue(baos.toString().contains(expected));
> 
> The linked JBS issue notes that the test was failing because of the additional (new) log messages from the jar tool itself. So I think the logs will be deterministic (since they aren't being generated by something else other than the jart tool). Using `contains()` thus looks fine to me.

Do you think we should print out the actual and expected, when they don't match? It might make it easier to debug any unexpected failures in future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1815981958

From duke at openjdk.org  Fri Oct 25 04:40:11 2024
From: duke at openjdk.org (duke)
Date: Fri, 25 Oct 2024 04:40:11 GMT
Subject: Withdrawn: 8339241: Optimize LambdaForm#basicType(Class)
In-Reply-To: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>
References: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>
Message-ID: <ngoMcS71u3fK7PgojPiqiwjA-OxYqNl_Evf64UoGZPg=.e255f657-44ea-4340-83b7-e3f94030ccb0@github.com>

On Thu, 29 Aug 2024 01:30:55 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to simplify the implementation logic of LambdaForm$BasicType#basicType method can reduce the call stack and reduce the overall bytecode size.
> 
> Below is the compiler log
> 
> * baseline
> 
>  @ 1   java.lang.invoke.LambdaForm$BasicType::basicType (8 bytes)   inline
>    @ 1   sun.invoke.util.Wrapper::basicTypeChar (18 bytes)   inline
>      @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>      @ 11   sun.invoke.util.Wrapper::forPrimitiveType (122 bytes)   failed to inline: callee is too large
>      @ 14   sun.invoke.util.Wrapper::basicTypeChar (5 bytes)   inline
> 
> 
> * current
> 
> java.lang.invoke.LambdaForm$BasicType::basicType (87 bytes)   failed to inline: callee is too large

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20759

From jwaters at openjdk.org  Fri Oct 25 04:50:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 25 Oct 2024 04:50:07 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <cVv-wFm8QKGffdCPHJwPV4F4NtWO1w76oK2BJvDFUt8=.b7f4a083-9743-4d0b-874f-06a4e2d72f8a@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
 <cVv-wFm8QKGffdCPHJwPV4F4NtWO1w76oK2BJvDFUt8=.b7f4a083-9743-4d0b-874f-06a4e2d72f8a@github.com>
Message-ID: <GMGgl1SPx74o0LZNaOAX2IjzQIY15sAhFErLpqbrra0=.cd66efd1-312b-4866-b1ce-3fa435d75bee@github.com>

On Thu, 24 Oct 2024 22:07:52 GMT, Magnus Ihse Bursie <ihse 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
>
> make/autoconf/flags-cflags.m4 line 589:
> 
>> 587:   # CXXFLAGS C++ language level for all of JDK, including Hotspot.
>> 588:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>> 589:     LANGSTD_CXXFLAGS="-std=c++14"
> 
> Is this really an intention on your part, to bump the C++ level inside a PR to remove unused code? ? Or is it a merge error from a different PR?

It's a checkout error from the original gigantic Pull Request, sorry. I don't plan to raise the JDK to C++17 in this one. But I'm not sure what to do with this now, since maybe_unused is C++17. I don't think anyone is going to appreciate [[gnu::unused]] inside Windows code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21655#discussion_r1815989407

From psadhukhan at openjdk.org  Fri Oct 25 04:57:39 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 04:57:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
 <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
 <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>
Message-ID: <3cbgckSg8DmaAkUalu54f2S9UMmrVrgo7SNQ1Eb1PvM=.a2830527-7ffc-48d2-8191-85c861f30b6f@github.com>

On Thu, 24 Oct 2024 17:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...
> 
> Did we agree on that?

Atleast client-dev team did..
See this initial note https://github.com/openjdk/jdk/pull/18414/files#r1534605049
And also in our internal meeting, Phil mentioned if IDE is having issue with this tag order (like collapsing) it's IDE's problem and they should be rectified and we should not change our product code for that..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815994453

From asemenyuk at openjdk.org  Fri Oct 25 05:09:48 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 25 Oct 2024 05:09:48 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v5]
In-Reply-To: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
Message-ID: <Xxyx1K0U6yvMtxVrbLl1O79gFdeVlGAcCtqp7FYpiI0=.183f75ed-7d8d-412a-9bd0-a1a5c70a30b8@github.com>

> Make jpackage correctly handle the output directory (`--dest`) that is:
>  - a subdirectory of the input directory;
>  - the same as the input directory.
> 
> Make jpackage correctly handle temp directory (`--temp`) that is:
>  - a subdirectory of the input directory.
> 
> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
> 
> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
> 
> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
> 
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
> 
> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.

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 20 additional commits since the last revision:

 - Merge branch 'master' into JDK-8325089
 - Add tests for `--app-content` and `--dmg-app-content` CLI parameters
 - Files.isSameFile() throws exception if a file doesn't exist
 - Replace Path.equals() call with Files.isSameFile()
 - Use jdk.jpackage.test.Annotations.Parameter annotation to parameterize packaging type in the test
 - Bugfix
 - Fix typo and trailing whitespaces
 - Fix JPackageCommand.execute(): remove existing output bundle (package file or app image folder) based on its type (file/directory) and not on the type of jpackage command (app image/package).
 - Make jpackage work properly when input and output directories are the same
 - Fix trailing whitespaces
 - ... and 10 more: https://git.openjdk.org/jdk/compare/15642669...c21b18bb

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21550/files
  - new: https://git.openjdk.org/jdk/pull/21550/files/5065a3bd..c21b18bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=03-04

  Stats: 51051 lines in 877 files changed: 26021 ins; 21692 del; 3338 mod
  Patch: https://git.openjdk.org/jdk/pull/21550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21550/head:pull/21550

PR: https://git.openjdk.org/jdk/pull/21550

From asemenyuk at openjdk.org  Fri Oct 25 05:47:49 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 25 Oct 2024 05:47:49 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v6]
In-Reply-To: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
Message-ID: <jb6t8ubajxxGphrx8eqRio0RH9HDgJSzrU46PF-6nDI=.88269208-fc09-41f4-9625-079f6e383f64@github.com>

> Make jpackage correctly handle the output directory (`--dest`) that is:
>  - a subdirectory of the input directory;
>  - the same as the input directory.
> 
> Make jpackage correctly handle temp directory (`--temp`) that is:
>  - a subdirectory of the input directory.
> 
> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
> 
> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
> 
> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
> 
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
> 
> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Make app image asserts configurable in JPackageCommand

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21550/files
  - new: https://git.openjdk.org/jdk/pull/21550/files/c21b18bb..f54e88bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=04-05

  Stats: 43 lines in 2 files changed: 28 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21550/head:pull/21550

PR: https://git.openjdk.org/jdk/pull/21550

From dholmes at openjdk.org  Fri Oct 25 06:09:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Oct 2024 06:09:25 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
Message-ID: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>

On Thu, 24 Oct 2024 21:08:26 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 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()

Next batch of comments ...

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/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/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 1698:

> 1696:     // on _WaitSetLock so it's not profitable to reduce the length of the
> 1697:     // critical section.
> 1698: 

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 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 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 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

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393922768
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_r1815840245
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_r1815956322
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816040287
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815959203
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

From psadhukhan at openjdk.org  Fri Oct 25 06:43:42 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 06:43:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <8Oq38NBheXvpvw7sKy_5vSHd7o5r2rJmM8lQToaXmDc=.d8488397-1c79-446b-95c9-9b7a43d4b308@github.com>

On Thu, 24 Oct 2024 13:19: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 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

Reviewed jdk javax/print and javax/swing..Looks good..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2437002459

From jpai at openjdk.org  Fri Oct 25 06:55:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 06:55:16 GMT
Subject: RFR: 8343040: Clean up references to JRE in the launcher code
Message-ID: <Hxe8lDtNtkeGd2eKZT0_b8zUHPXVZqqpMV_JbanOKQQ=.16c06c04-edaa-45db-9a71-5125e01f9df1@github.com>

Can I please get a review of this change which cleans up references to "JRE" from the launcher's code?

No functional changes have been introduced in this change.

No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass in our CI against Linux, macosx and Windows.

-------------

Commit messages:
 - 8343040: Clean up references to JRE in the launcher code

Changes: https://git.openjdk.org/jdk/pull/21704/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21704&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343040
  Stats: 161 lines in 8 files changed: 1 ins; 27 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/21704.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21704/head:pull/21704

PR: https://git.openjdk.org/jdk/pull/21704

From jpai at openjdk.org  Fri Oct 25 06:55:17 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 06:55:17 GMT
Subject: RFR: 8343040: Clean up references to JRE in the launcher code
In-Reply-To: <Hxe8lDtNtkeGd2eKZT0_b8zUHPXVZqqpMV_JbanOKQQ=.16c06c04-edaa-45db-9a71-5125e01f9df1@github.com>
References: <Hxe8lDtNtkeGd2eKZT0_b8zUHPXVZqqpMV_JbanOKQQ=.16c06c04-edaa-45db-9a71-5125e01f9df1@github.com>
Message-ID: <eyYBhqV0Fpk0gnl--mc5qLUF46bnBW1QKHfshAUmPRU=.cd410eab-2f00-4d11-ad3b-6ab37fa72d89@github.com>

On Fri, 25 Oct 2024 06:49:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up references to "JRE" from the launcher's code?
> 
> No functional changes have been introduced in this change.
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass in our CI against Linux, macosx and Windows.

src/java.base/share/native/libjli/emessages.h line 74:

> 72: #define CLS_ERROR4      "Error: Main method not public\n" GEN_ERROR
> 73: #define CLS_ERROR5      "Error: main-class: attribute exceeds system limits of %d bytes\n" GEN_ERROR
> 74: 

The macros which have been removed in this PR are unusued ones. I decided to clean them up since they weren't too many and I was anyway updating this current file in context of the current change.

src/java.base/share/native/libjli/emessages.h line 87:

> 85: #define LAUNCHER_ERROR3 "Error: Path length exceeds maximum length (PATH_MAX)"
> 86: #define LAUNCHER_ERROR4 "Error: trying to exec %s.\nCheck if file exists and permissions are set correctly."
> 87: #define LAUNCHER_ERROR5 "Error: String processing operation failed"

While renaming these `JRE_ERROR` macros, I've renumbered them, since some of these `JRE_ERROR<N>` were unused. Relevant usages within the code of these macros have been updated accordingly to make sure they continue to emit the correct message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21704#discussion_r1816099321
PR Review Comment: https://git.openjdk.org/jdk/pull/21704#discussion_r1816101967

From jlahoda at openjdk.org  Fri Oct 25 06:56:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Oct 2024 06:56:30 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v2]
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: <8Hfsbc8W7ItgCmH4P7kSapfiPIym6rAsGslOo_3vg94=.92d5f913-7cb1-4111-be1b-7a8c213e9854@github.com>

> 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:

  Removing incorrect sentence about writing a prompt for the prompt-less readln method.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21693/files
  - new: https://git.openjdk.org/jdk/pull/21693/files/3554045b..78bf15bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21693&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21693&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21693/head:pull/21693

PR: https://git.openjdk.org/jdk/pull/21693

From jpai at openjdk.org  Fri Oct 25 07:03:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 07:03:07 GMT
Subject: RFR: 8343040: Clean up references to JRE in the launcher code
In-Reply-To: <Hxe8lDtNtkeGd2eKZT0_b8zUHPXVZqqpMV_JbanOKQQ=.16c06c04-edaa-45db-9a71-5125e01f9df1@github.com>
References: <Hxe8lDtNtkeGd2eKZT0_b8zUHPXVZqqpMV_JbanOKQQ=.16c06c04-edaa-45db-9a71-5125e01f9df1@github.com>
Message-ID: <B4u5ElGeE_Wb_g4Zd2vG6qqtUouqkQjPyo1q9DrVEpQ=.be072423-f31d-484b-9e9a-225c894b1b28@github.com>

On Fri, 25 Oct 2024 06:49:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up references to "JRE" from the launcher's code?
> 
> No functional changes have been introduced in this change.
> 
> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass in our CI against Linux, macosx and Windows.

GitHub UI doesn't let me add this comment inline, so adding this here. There's this `if` block (only) in the `src/java.base/macosx/native/libjli/java_md_macosx.m`:


/* Does the app ship a private JRE in <apphome>/jre directory? */
JLI_Snprintf(libjava, sizeof(libjava), "%s/jre/lib/" JAVA_DLL, path);
if (access(libjava, F_OK) == 0) {
    JLI_StrCat(path, "/jre");
    JLI_TraceLauncher("JRE path is %s\n", path);
    return JNI_TRUE;
}


I have let this stay and haven't changed it, since any changes here would be functional. I think we will have to look into this separately and decide if we should continue supporting this. What this is doing here is that it's trying to find `jre/lib/libjava.dylib` under the current running process' launched "home" path and if it finds one, then it considers the process' launched "home" path as the JDK installation root. It's not clear why we do this only in the macosx implementation (I will check the history).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21704#issuecomment-2437042807

From mbaesken at openjdk.org  Fri Oct 25 07:06:09 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 25 Oct 2024 07:06:09 GMT
Subject: RFR: 8342938: Problem list java/io/IO/IO.java test on Linux
 ppc64le
In-Reply-To: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>
References: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>
Message-ID: <q622nq_kKy8_sVHzfYeRRs1lYd_Z5RmKJQvLEvKm3Es=.057ca215-62bf-4a0c-919c-71a86145fb03@github.com>

On Thu, 24 Oct 2024 09:08:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Test java/io/IO/IO.java fails on Linux ppc64le because of issues with 'expect' .

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21678#issuecomment-2437045742

From mbaesken at openjdk.org  Fri Oct 25 07:06:09 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 25 Oct 2024 07:06:09 GMT
Subject: Integrated: 8342938: Problem list java/io/IO/IO.java test on Linux
 ppc64le
In-Reply-To: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>
References: <oLDWsgD1fn5iDct6dwA5_2a1Xr2rfhlQNPML8FWOr_8=.34a4da3d-f49d-410c-9297-9b18b293ff5c@github.com>
Message-ID: <PM4zyD2EpurET-WaC96br_39VP3n32Ml6gjiNjGB9M4=.7e873161-a2c0-406b-a9c1-d9be9fa48f6d@github.com>

On Thu, 24 Oct 2024 09:08:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Test java/io/IO/IO.java fails on Linux ppc64le because of issues with 'expect' .

This pull request has now been integrated.

Changeset: 415d8151
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/415d8151a6c7ce04d8ab27ff641acb5d69840125
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8342938: Problem list java/io/IO/IO.java test on Linux ppc64le

Reviewed-by: lucy, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21678

From hannesw at openjdk.org  Fri Oct 25 07:11:18 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 25 Oct 2024 07:11:18 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <PgAAUiIwM4y3ghPK2qfvZ8PECbU_Py3VGRyOLX4YUsM=.ede5c00f-1c52-44fe-9de4-cc1650ebb506@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Thanks all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2437054155

From epeter at openjdk.org  Fri Oct 25 07:11:20 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 25 Oct 2024 07:11:20 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v32]
In-Reply-To: <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <iR7LC-_qU0E8IVfd-rjB4sSLrYwQvsAb3lBIQfWwMqk=.fec50d13-d0b5-4b6e-970d-6f41d9ed9044@github.com>
Message-ID: <aG2JGZxd4WxT-NyNBlIjsPb_J8sq1WfSUoPBmjT2YzU=.6838a077-d786-4834-ba0d-11e12d08ca2c@github.com>

On Thu, 24 Oct 2024 13:36:50 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Review resolutions.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Factor out IR tests and Transforms to follow-up PRs.
>  - Replacing flag based checks with CPU feature checks in IR validation test.
>  - Remove Saturating IRNode patterns.
>  - Restrict IR validation to newly added UMin/UMax transforms.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - Prod build fix
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8338201
>  - New IR tests + additional IR transformations
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/158b93d1...0e10139c

Ok, I'll approve it now, since @PaulSandoz is ok with the test coverage.
I did not review all the x86 backend instructions, I don't have the time or understanding for that - I rely on testing for correctness here.

Thanks for the work @jatin-bhateja ? 
The VectorAPI is a lot of work, and we are grateful for your contributions!

I am still worried about general test coverage. One can always do it later - but will that actually be done? I suppose this is a trade-off between spending time on quality vs quantity of features. Bugs in the VectorAPI will probably mostly show in miscompilations. Those are hard to catch without solid testing and rigorous result verification. The VectorAPI is also not widely used yet, so miscompilations will only slowly be discovered. Miscompilations in Auto-Vectorization are quicker discovered because there is more code out there that is sensitive to it.

Maybe I'm coming across as annoying with all my RFE-splitting suggestions. But I do think that it is the job of the PR-author to make the code as reviewable and high-quality before it is sent for review. The author knows the code best, and should not burden the reviewers unnecessarily with combined features. A PR that is 2x as long is not just 2x as much work to review. It takes the reviewer more time - maybe 4x because it is harder to understand what belongs together, if everything is sufficiently tested. Also, the number of review-rounds increases. Every time the reviewer is then required to read all code again. This is really a waste of time and very frustrating. But I think you understand that now, and I am looking forward to nicely portioned PRs in the future ;)

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2394395794

From hannesw at openjdk.org  Fri Oct 25 07:11:19 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 25 Oct 2024 07:11:19 GMT
Subject: Integrated: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <r2DQm4YM057gNfMLILLJZJswLeOxQagxBqyFAGNMU7g=.de394ac2-5105-4aea-b153-59f519148dd3@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

This pull request has now been integrated.

Changeset: fd5ff054
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd5ff0547ced6733ae05f1428664062615408dc9
Stats:     144 lines in 28 files changed: 58 ins; 58 del; 28 mod

8342827: Fix order of @param tags in other modules

Reviewed-by: jpai, iris, joehw, darcy, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/21637

From duke at openjdk.org  Fri Oct 25 08:02:06 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 08:02:06 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <-WqUhwnLhGndoAAvBO-ZxwlvobpDSWH9MFK5M1SYLaQ=.1dd22519-1330-4ee7-b12d-db93c60387b9@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>
 <-WqUhwnLhGndoAAvBO-ZxwlvobpDSWH9MFK5M1SYLaQ=.1dd22519-1330-4ee7-b12d-db93c60387b9@github.com>
Message-ID: <BoqI7hVgo3HwsqOdMv5UBwuqFUzh1tecjSWLAELg_Sk=.78ec1b80-55c1-4ce3-884e-45f5ed90e445@github.com>

On Fri, 25 Oct 2024 03:06:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javap/8034066/EmptyLoop.jcod line 26:
>> 
>>> 24:  /*
>>> 25:  * Original source:
>>> 26:  * public class EmptyLoop {
>> 
>> To reduce test file noise, I recommend adding this as a package-private class to the end of your test file (so not a nested class) after it is renamed, like:
>> 
>> 
>> class EmptyLoop {
>>     public void emptyLoop() {
>>         for (int i = 0; i < 10; i++) {
>>         }
>>     }
>> }
>> 
>> 
>> After that, once your test class is compiled, the `EmptyLoop.class` is available in `test.classes` property directory, so you can remove this jcod and all code that converts the jcod to class.
>> 
>> You can see UndefinedAccessFlagTest for how we use such tricks.
>> 
>> Note: since you will only have one test class, you no longer need a dedicated directory; you can just place our `CodeIndentTest.java` in the root javap directory.
>
> Another example of such a trick is available at [test/jdk/jdk/classfile/ClassBuildingTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/classfile/ClassBuildingTest.java)

I initially had something like this, but was not sure if the generated classfile could differ between jdk versions/implementations. I assume this is not a valid concern for such a simple example?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1816186616

From duke at openjdk.org  Fri Oct 25 08:06:11 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 08:06:11 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options
In-Reply-To: <hx4_aWAXVQRoL6rzjVRVPCT_IN6EgKQ10a8TSsLNojw=.f92a2dfd-8bab-4bb9-8d99-bdb7d27ae25c@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
 <hx4_aWAXVQRoL6rzjVRVPCT_IN6EgKQ10a8TSsLNojw=.f92a2dfd-8bab-4bb9-8d99-bdb7d27ae25c@github.com>
Message-ID: <N2ASB-26v4AcQBHcXV8s3-SZ1x3tTqcxbyokA5C5usA=.e0f27ba1-58a4-4949-9e97-df1f0f185b88@github.com>

On Fri, 25 Oct 2024 02:55:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javap/8034066/T8034066.java line 37:
>> 
>>> 35: import java.util.regex.Pattern;
>>> 36: 
>>> 37: public class T8034066 {
>> 
>> Please don't continue the old practice of naming tests after their bug ID. It obfuscates which test class does what (both in the source code and in the test logs). Suggestion for name: `TestStackMapDetailsIndent`
>
> How about `CodeIndentTest`? We prefer to use prefix modifiers, and this tests the indent for general code writer output.

I would propose `ClassWriterCodeIndentTest`. Although a little longer, it makes clear we are testing the Path `ClassWriter->CoderWriter` and not the similar `AttributeWriter->CodeWriter` control flow. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1816192328

From aboldtch at openjdk.org  Fri Oct 25 08:25:21 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 25 Oct 2024 08:25:21 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v5]
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Remove GCName::Z
 - Merge tag 'jdk-24+21' into JDK-8341692
   
   Added tag jdk-24+21 for changeset 8bcd4920
 - Merge tag 'jdk-24+20' into JDK-8341692
   
   Added tag jdk-24+20 for changeset 7a64fbbb
 - Merge tag 'jdk-24+19' into JDK-8341692
   
   Added tag jdk-24+19 for changeset e7c5bf45
 - LargeWindowPaintTest.java fix id typo
 - Fix problem-listed @requires typo
 - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
 - Reorder z_globals options: product > diagnostic product > develop
 - Consistent albite special code style
 - Consistent order between ZArguments and GCArguments
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8bcd4920...eef214b4

-------------

Changes: https://git.openjdk.org/jdk/pull/21401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=04
  Stats: 39435 lines in 407 files changed: 155 ins; 39010 del; 270 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

PR: https://git.openjdk.org/jdk/pull/21401

From mcimadamore at openjdk.org  Fri Oct 25 08:42:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 08:42:24 GMT
Subject: RFR: 8342902: Deduplication of acquire calls in BindingSpecializer
 causes escape-analyisis failure
Message-ID: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>

This PR fixes an issue where passing many by-reference parameters to downcall results in escape analysis failures.
The problem is that, as the parameters grow, the generated code in the trampoline stub we generate also grows.
When it reaches a certain threshold, it becomes too big, and it is no longer inlined in the caller.
When this happens, allocations for by-reference parameters (e.g. a segment constructed from `MemorySegment::ofAddress`) can no longer be eliminated.

The solution is two-fold. First, we annotate the generated trampoline with `@ForceInline`. After all, it is rather critical, to guarantee optimal performance, that this code can be always inlined.
Second, to keep the size of the generated code under control, we also put a limit on the max number of comparisons that are generated in order to "deduplicate" scope acquire/release calls.
The deduplication logic is a bit finicky -- it was put in place because, when confined and shared are passed by-ref, we need to prevent them from being closed in the middle of a native call.
So, we save all the seen scopes in a bunch of locals, and then we compare each new scope with _all_ the previous cached locals, and skip acquire if we can.

While this strategy work it does not scale when there are many by-ref parameters - as a by-ref parameter N will need N - 1 comparisons - which means a quadratic number of comparisons is generated.
This is fixed in this PR by putting a lid on the maximum number of comparisons that are generated. We also make the comparisons a bit smarter, by always skipping the very first by-ref argument -- the downcall address.
It is in fact very common for the downcall address to be in a different scope than that of the other by-ref arguments anyway.

A nice property of the new logic is that by configuring the max number of comparisons we can effectively select between different strategies:
* max = 0, means no dedup
* max = 1, means one-element cache
* max = N, means full dedup (like before)

Thanks to Ioannis (@spasi) for the report and the benchmark. I've beefed the benchmark up by adding a case for 10 arguments, and also adding support for critical downcalls, so we could also test passing by-ref heap segments. Benchmark result will be provided in a separate comment.

-------------

Commit messages:
 - Simplify logic.
 - Cache a single scope
 - Initial push
 - Add JDK property to select shape of generated bytecode for scope dedup
 - Add more benchmarks
 - Fix classfile API usages
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/21706/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342902
  Stats: 303 lines in 3 files changed: 296 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21706/head:pull/21706

PR: https://git.openjdk.org/jdk/pull/21706

From mcimadamore at openjdk.org  Fri Oct 25 08:42:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 08:42:24 GMT
Subject: RFR: 8342902: Deduplication of acquire calls in BindingSpecializer
 causes escape-analyisis failure
In-Reply-To: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
References: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
Message-ID: <VO6p-485tK2cKp3tXhioyjxKHjFmaU8r8t3k6PRELXI=.4b4a8073-6584-4aa4-b40e-544e8174fadb@github.com>

On Fri, 25 Oct 2024 08:37:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue where passing many by-reference parameters to downcall results in escape analysis failures.
> The problem is that, as the parameters grow, the generated code in the trampoline stub we generate also grows.
> When it reaches a certain threshold, it becomes too big, and it is no longer inlined in the caller.
> When this happens, allocations for by-reference parameters (e.g. a segment constructed from `MemorySegment::ofAddress`) can no longer be eliminated.
> 
> The solution is two-fold. First, we annotate the generated trampoline with `@ForceInline`. After all, it is rather critical, to guarantee optimal performance, that this code can be always inlined.
> Second, to keep the size of the generated code under control, we also put a limit on the max number of comparisons that are generated in order to "deduplicate" scope acquire/release calls.
> The deduplication logic is a bit finicky -- it was put in place because, when confined and shared are passed by-ref, we need to prevent them from being closed in the middle of a native call.
> So, we save all the seen scopes in a bunch of locals, and then we compare each new scope with _all_ the previous cached locals, and skip acquire if we can.
> 
> While this strategy work it does not scale when there are many by-ref parameters - as a by-ref parameter N will need N - 1 comparisons - which means a quadratic number of comparisons is generated.
> This is fixed in this PR by putting a lid on the maximum number of comparisons that are generated. We also make the comparisons a bit smarter, by always skipping the very first by-ref argument -- the downcall address.
> It is in fact very common for the downcall address to be in a different scope than that of the other by-ref arguments anyway.
> 
> A nice property of the new logic is that by configuring the max number of comparisons we can effectively select between different strategies:
> * max = 0, means no dedup
> * max = 1, means one-element cache
> * max = N, means full dedup (like before)
> 
> Thanks to Ioannis (@spasi) for the report and the benchmark. I've beefed the benchmark up by adding a case for 10 arguments, and also adding support for critical downcalls, so we could also test passing by-ref heap segments. Benchmark result will be provided in a separate comment.

This are the results of running the new benchmark on my workstation. As it can be seen, GC activity remains low (zero) across the board. Throughput is also very good, even when "real" acquire/release calls are involved (a sign that the cache still works).


Benchmark                                               (kind)  Mode  Cnt   Score    Error   Units
CallByRefHighArity.noop_params0                       CONFINED  avgt    3   2.714 ?  0.444   ns/op
CallByRefHighArity.noop_params0:?gc.alloc.rate        CONFINED  avgt    3   0.001 ?  0.015  MB/sec
CallByRefHighArity.noop_params0:?gc.alloc.rate.norm   CONFINED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params0:?gc.count             CONFINED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params0                         SHARED  avgt    3   2.795 ?  0.045   ns/op
CallByRefHighArity.noop_params0:?gc.alloc.rate          SHARED  avgt    3   0.001 ?  0.026  MB/sec
CallByRefHighArity.noop_params0:?gc.alloc.rate.norm     SHARED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params0:?gc.count               SHARED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params0                         GLOBAL  avgt    3   2.762 ?  0.321   ns/op
CallByRefHighArity.noop_params0:?gc.alloc.rate          GLOBAL  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params0:?gc.alloc.rate.norm     GLOBAL  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params0:?gc.count               GLOBAL  avgt    3     ? 0           counts
CallByRefHighArity.noop_params0                           HEAP  avgt    3   2.775 ?  0.330   ns/op
CallByRefHighArity.noop_params0:?gc.alloc.rate            HEAP  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params0:?gc.alloc.rate.norm       HEAP  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params0:?gc.count                 HEAP  avgt    3     ? 0           counts
CallByRefHighArity.noop_params1                       CONFINED  avgt    3   4.667 ?  0.207   ns/op
CallByRefHighArity.noop_params1:?gc.alloc.rate        CONFINED  avgt    3   0.001 ?  0.015  MB/sec
CallByRefHighArity.noop_params1:?gc.alloc.rate.norm   CONFINED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params1:?gc.count             CONFINED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params1                         SHARED  avgt    3   7.942 ?  4.004   ns/op
CallByRefHighArity.noop_params1:?gc.alloc.rate          SHARED  avgt    3   0.001 ?  0.026  MB/sec
CallByRefHighArity.noop_params1:?gc.alloc.rate.norm     SHARED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params1:?gc.count               SHARED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params1                         GLOBAL  avgt    3   2.922 ?  0.397   ns/op
CallByRefHighArity.noop_params1:?gc.alloc.rate          GLOBAL  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params1:?gc.alloc.rate.norm     GLOBAL  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params1:?gc.count               GLOBAL  avgt    3     ? 0           counts
CallByRefHighArity.noop_params1                           HEAP  avgt    3   3.668 ?  0.255   ns/op
CallByRefHighArity.noop_params1:?gc.alloc.rate            HEAP  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params1:?gc.alloc.rate.norm       HEAP  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params1:?gc.count                 HEAP  avgt    3     ? 0           counts
CallByRefHighArity.noop_params2                       CONFINED  avgt    3   4.443 ?  0.383   ns/op
CallByRefHighArity.noop_params2:?gc.alloc.rate        CONFINED  avgt    3   0.001 ?  0.015  MB/sec
CallByRefHighArity.noop_params2:?gc.alloc.rate.norm   CONFINED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params2:?gc.count             CONFINED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params2                         SHARED  avgt    3   7.938 ?  0.644   ns/op
CallByRefHighArity.noop_params2:?gc.alloc.rate          SHARED  avgt    3   0.001 ?  0.026  MB/sec
CallByRefHighArity.noop_params2:?gc.alloc.rate.norm     SHARED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params2:?gc.count               SHARED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params2                         GLOBAL  avgt    3   2.923 ?  0.446   ns/op
CallByRefHighArity.noop_params2:?gc.alloc.rate          GLOBAL  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params2:?gc.alloc.rate.norm     GLOBAL  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params2:?gc.count               GLOBAL  avgt    3     ? 0           counts
CallByRefHighArity.noop_params2                           HEAP  avgt    3   3.791 ?  0.103   ns/op
CallByRefHighArity.noop_params2:?gc.alloc.rate            HEAP  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params2:?gc.alloc.rate.norm       HEAP  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params2:?gc.count                 HEAP  avgt    3     ? 0           counts
CallByRefHighArity.noop_params3                       CONFINED  avgt    3   4.793 ?  2.755   ns/op
CallByRefHighArity.noop_params3:?gc.alloc.rate        CONFINED  avgt    3   0.001 ?  0.015  MB/sec
CallByRefHighArity.noop_params3:?gc.alloc.rate.norm   CONFINED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params3:?gc.count             CONFINED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params3                         SHARED  avgt    3   8.842 ?  0.786   ns/op
CallByRefHighArity.noop_params3:?gc.alloc.rate          SHARED  avgt    3   0.001 ?  0.026  MB/sec
CallByRefHighArity.noop_params3:?gc.alloc.rate.norm     SHARED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params3:?gc.count               SHARED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params3                         GLOBAL  avgt    3   2.726 ?  0.114   ns/op
CallByRefHighArity.noop_params3:?gc.alloc.rate          GLOBAL  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params3:?gc.alloc.rate.norm     GLOBAL  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params3:?gc.count               GLOBAL  avgt    3     ? 0           counts
CallByRefHighArity.noop_params3                           HEAP  avgt    3   4.155 ?  0.581   ns/op
CallByRefHighArity.noop_params3:?gc.alloc.rate            HEAP  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params3:?gc.alloc.rate.norm       HEAP  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params3:?gc.count                 HEAP  avgt    3     ? 0           counts
CallByRefHighArity.noop_params4                       CONFINED  avgt    3   5.008 ?  0.361   ns/op
CallByRefHighArity.noop_params4:?gc.alloc.rate        CONFINED  avgt    3   0.001 ?  0.015  MB/sec
CallByRefHighArity.noop_params4:?gc.alloc.rate.norm   CONFINED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params4:?gc.count             CONFINED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params4                         SHARED  avgt    3   9.612 ?  0.722   ns/op
CallByRefHighArity.noop_params4:?gc.alloc.rate          SHARED  avgt    3   0.001 ?  0.026  MB/sec
CallByRefHighArity.noop_params4:?gc.alloc.rate.norm     SHARED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params4:?gc.count               SHARED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params4                         GLOBAL  avgt    3   3.076 ?  0.250   ns/op
CallByRefHighArity.noop_params4:?gc.alloc.rate          GLOBAL  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params4:?gc.alloc.rate.norm     GLOBAL  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params4:?gc.count               GLOBAL  avgt    3     ? 0           counts
CallByRefHighArity.noop_params4                           HEAP  avgt    3   4.520 ?  0.275   ns/op
CallByRefHighArity.noop_params4:?gc.alloc.rate            HEAP  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params4:?gc.alloc.rate.norm       HEAP  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params4:?gc.count                 HEAP  avgt    3     ? 0           counts
CallByRefHighArity.noop_params5                       CONFINED  avgt    3   5.429 ?  2.031   ns/op
CallByRefHighArity.noop_params5:?gc.alloc.rate        CONFINED  avgt    3   0.001 ?  0.015  MB/sec
CallByRefHighArity.noop_params5:?gc.alloc.rate.norm   CONFINED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params5:?gc.count             CONFINED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params5                         SHARED  avgt    3   9.716 ?  2.919   ns/op
CallByRefHighArity.noop_params5:?gc.alloc.rate          SHARED  avgt    3   0.001 ?  0.026  MB/sec
CallByRefHighArity.noop_params5:?gc.alloc.rate.norm     SHARED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params5:?gc.count               SHARED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params5                         GLOBAL  avgt    3   2.954 ?  0.035   ns/op
CallByRefHighArity.noop_params5:?gc.alloc.rate          GLOBAL  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params5:?gc.alloc.rate.norm     GLOBAL  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params5:?gc.count               GLOBAL  avgt    3     ? 0           counts
CallByRefHighArity.noop_params5                           HEAP  avgt    3   5.001 ?  1.058   ns/op
CallByRefHighArity.noop_params5:?gc.alloc.rate            HEAP  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params5:?gc.alloc.rate.norm       HEAP  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params5:?gc.count                 HEAP  avgt    3     ? 0           counts
CallByRefHighArity.noop_params10                      CONFINED  avgt    3   8.532 ?  1.880   ns/op
CallByRefHighArity.noop_params10:?gc.alloc.rate       CONFINED  avgt    3   0.001 ?  0.015  MB/sec
CallByRefHighArity.noop_params10:?gc.alloc.rate.norm  CONFINED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params10:?gc.count            CONFINED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params10                        SHARED  avgt    3  12.237 ?  2.431   ns/op
CallByRefHighArity.noop_params10:?gc.alloc.rate         SHARED  avgt    3   0.001 ?  0.026  MB/sec
CallByRefHighArity.noop_params10:?gc.alloc.rate.norm    SHARED  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params10:?gc.count              SHARED  avgt    3     ? 0           counts
CallByRefHighArity.noop_params10                        GLOBAL  avgt    3   7.216 ?  0.846   ns/op
CallByRefHighArity.noop_params10:?gc.alloc.rate         GLOBAL  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params10:?gc.alloc.rate.norm    GLOBAL  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params10:?gc.count              GLOBAL  avgt    3     ? 0           counts
CallByRefHighArity.noop_params10                          HEAP  avgt    3   8.961 ?  0.667   ns/op
CallByRefHighArity.noop_params10:?gc.alloc.rate           HEAP  avgt    3  ? 10??           MB/sec
CallByRefHighArity.noop_params10:?gc.alloc.rate.norm      HEAP  avgt    3  ? 10??             B/op
CallByRefHighArity.noop_params10:?gc.count                HEAP  avgt    3     ? 0           counts

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21706#issuecomment-2437219620

From mcimadamore at openjdk.org  Fri Oct 25 08:45:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 08:45:10 GMT
Subject: RFR: 8342902: Deduplication of acquire calls in BindingSpecializer
 causes escape-analyisis failure
In-Reply-To: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
References: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
Message-ID: <BuMdoeXK1IHova3NhDOhImJXpqkaw6KN5HXoQWxOsow=.675fadcb-4388-4513-bb21-b24e4bdd5e24@github.com>

On Fri, 25 Oct 2024 08:37:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue where passing many by-reference parameters to downcall results in escape analysis failures.
> The problem is that, as the parameters grow, the generated code in the trampoline stub we generate also grows.
> When it reaches a certain threshold, it becomes too big, and it is no longer inlined in the caller.
> When this happens, allocations for by-reference parameters (e.g. a segment constructed from `MemorySegment::ofAddress`) can no longer be eliminated.
> 
> The solution is two-fold. First, we annotate the generated trampoline with `@ForceInline`. After all, it is rather critical, to guarantee optimal performance, that this code can be always inlined.
> Second, to keep the size of the generated code under control, we also put a limit on the max number of comparisons that are generated in order to "deduplicate" scope acquire/release calls.
> The deduplication logic is a bit finicky -- it was put in place because, when confined and shared are passed by-ref, we need to prevent them from being closed in the middle of a native call.
> So, we save all the seen scopes in a bunch of locals, and then we compare each new scope with _all_ the previous cached locals, and skip acquire if we can.
> 
> While this strategy work it does not scale when there are many by-ref parameters - as a by-ref parameter N will need N - 1 comparisons - which means a quadratic number of comparisons is generated.
> This is fixed in this PR by putting a lid on the maximum number of comparisons that are generated. We also make the comparisons a bit smarter, by always skipping the very first by-ref argument -- the downcall address.
> It is in fact very common for the downcall address to be in a different scope than that of the other by-ref arguments anyway.
> 
> A nice property of the new logic is that by configuring the max number of comparisons we can effectively select between different strategies:
> * max = 0, means no dedup
> * max = 1, means one-element cache
> * max = N, means full dedup (like before)
> 
> Thanks to Ioannis (@spasi) for the report and the benchmark. I've beefed the benchmark up by adding a case for 10 arguments, and also adding support for critical downcalls, so we could also test passing by-ref heap segments. Benchmark result will be provided in a separate comment.

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 85:

> 83:         = GetBooleanAction.privilegedGetProperty("jdk.internal.foreign.abi.Specializer.PERFORM_VERIFICATION");
> 84:     private static final int SCOPE_DEDUP_DEPTH
> 85:             = GetIntegerAction.privilegedGetProperty("jdk.internal.foreign.abi.Specializer.SCOPE_DEDUP_DEPTH", 2);

A two-comparison logic seems like a good compromise. Note this doesn't really mean a two-element cache - it is still possible to have e.g. the first two arguments with the same scope and then a third argumemt with another scope - in which case the third argument won't be deduped. This is a trade-off - to keep the generated code simple we need to have a 1-1 mapping between by-ref parameters and locals.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21706#discussion_r1816268042

From jbhateja at openjdk.org  Fri Oct 25 08:59:13 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 25 Oct 2024 08:59:13 GMT
Subject: RFR: 8338021: Support new unsigned and saturating vector operators
 in VectorAPI [v30]
In-Reply-To: <FzDMi0bp6vzxLkpXz4li9u-odivGOdvSN8xPva9GI9c=.e5356fe6-33cb-4753-b86d-f6edc04f7ad2@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <usY3a3QFA7q1WYt3ucGoZcFkTXR5GqKCPXGmi7Abkus=.ad93886c-6bee-410b-abd2-450f3f9d145b@github.com>
 <rUeSOdb7fMhVJnMNpo05ExmEanp7QomnPiyp1eIJ8uA=.3d092f54-4fa0-4382-82fc-67e201dbad69@github.com>
 <yIxt0hF-lxx23dN3166uVpg4oqRZwrt5_3gd8Te37bc=.8cd5846a-1c4e-4046-aaff-e4b87b88cffe@github.com>
 <FzDMi0bp6vzxLkpXz4li9u-odivGOdvSN8xPva9GI9c=.e5356fe6-33cb-4753-b86d-f6edc04f7ad2@github.com>
Message-ID: <5b8t9BfyScOG01ZBVh6pwUr6nssDucvq2idxtNd_7sc=.0f08654f-1e75-4c39-bcd0-0ad7e8adca44@github.com>

On Tue, 22 Oct 2024 15:56:18 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hey @eme64 ,
>> 
>>> Wow this is really a very moving target - quite frustrating to review - it takes up way too much of the reviewers bandwidth. You really need to split up your PRs as much as possible so that review is easier and faster.
>> 
>> I understand reviewer's pain, which is why I mentioned about last two changes specifically. Vector API related PRs generally looks bulky due to script generated sources and tests. Barring that it may not demand much of your time.
>> 
>> But, to keep you motivated :-) and following @PaulSandoz and yours suggestions, I have moved out IR validations and Min / Max transforms to following follow up PRs.
>>    
>>    - https://bugs.openjdk.org/browse/JDK-8342676 (https://github.com/openjdk/jdk/pull/21604)
>>    - https://bugs.openjdk.org/browse/JDK-8342677 (https://github.com/openjdk/jdk/pull/21603)
>> 
>> Can you kindly run this though your test infrastructure and approve if it goes fine ?
>> 
>> Best Regards,
>> Jatin
>
>> Can you kindly run this though your test infrastructure and approve if it goes fine ?
>>
> 
> Internal tier 1 to 3 testing passed (i needed to merge with master at 7133d1b983d, due to some updates to unrelated test configuration files the test infrastructure expects).

> Ok, I'll approve it now, since @PaulSandoz is ok with the test coverage. I did not review all the x86 backend instructions, I don't have the time or understanding for that - I rely on testing for correctness here.
> 
> Thanks for the work @jatin-bhateja ? The VectorAPI is a lot of work, and we are grateful for your contributions!
> 
> I am still worried about general test coverage. One can always do it later - but will that actually be done? I suppose this is a trade-off between spending time on quality vs quantity of features. Bugs in the VectorAPI will probably mostly show in miscompilations. Those are hard to catch without solid testing and rigorous result verification. The VectorAPI is also not widely used yet, so miscompilations will only slowly be discovered. Miscompilations in Auto-Vectorization are quicker discovered because there is more code out there that is sensitive to it.
> 
> Maybe I'm coming across as annoying with all my RFE-splitting suggestions. But I do think that it is the job of the PR-author to make the code as reviewable and high-quality before it is sent for review. The author knows the code best, and should not burden the reviewers unnecessarily with combined features. A PR that is 2x as long is not just 2x as much work to review. It takes the reviewer more time - maybe 4x because it is harder to understand what belongs together, if everything is sufficiently tested. Also, the number of review-rounds increases. Every time the reviewer is then required to read all code again. This is really a waste of time and very frustrating. But I think you understand that now, and I am looking forward to nicely portioned PRs in the future ;)

We are in same boat @eme64 , I understand reviewers pain, and no debate on coverage and validations ? 

@sviswa7 , I guess we need a cursory re-approval from you for integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2437252005

From duke at openjdk.org  Fri Oct 25 09:28:53 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 09:28:53 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
Message-ID: <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>

> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
> 
> Current behaviour of `javap` differs with and without `-verbose` in the following way:
> **Command**: `javap -c -XDdetails:stackMaps A.class`
> 
> Without `-verbose`
> 
> 
> ...
>   public void a();
>     Code:
>        0: iconst_0
>        1: istore_1
>     StackMap locals:  this int
>     StackMap stack:
> ...
> 
> 
> With `-verbose`
> 
> 
> ...
>   public void a();
>     descriptor: ()V
>     flags: (0x0001) ACC_PUBLIC
>     Code:
>       stack=2, locals=2, args_size=1
>          0: iconst_0
>          1: istore_1
>       StackMap locals:  this int
>       StackMap stack:
> ...
> 
> 
> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
> 
> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
> 
> ---
> 
> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
> 
> 
> void writeSimple(CodeAttribute attr) {
>         println("Code:");
>         indent(+1);
>         writeInstrs(attr);
>         writeExceptionTable(attr);
>         indent(-1);
>     }
> 
> 
> ---
> 
> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)

Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:

 - adress feedback in implementation
 - address feedback in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21685/files
  - new: https://git.openjdk.org/jdk/pull/21685/files/ac915325..bd6372ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21685&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21685&range=00-01

  Stats: 382 lines in 5 files changed: 127 ins; 249 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21685/head:pull/21685

PR: https://git.openjdk.org/jdk/pull/21685

From duke at openjdk.org  Fri Oct 25 09:28:53 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 09:28:53 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <BoqI7hVgo3HwsqOdMv5UBwuqFUzh1tecjSWLAELg_Sk=.78ec1b80-55c1-4ce3-884e-45f5ed90e445@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <s28bhD81gYIGi8AKmCMu1EQ1o5B8Kz7DEJWXNVQd_FE=.51013feb-62c1-4db5-8e77-29f2d16d3069@github.com>
 <-WqUhwnLhGndoAAvBO-ZxwlvobpDSWH9MFK5M1SYLaQ=.1dd22519-1330-4ee7-b12d-db93c60387b9@github.com>
 <BoqI7hVgo3HwsqOdMv5UBwuqFUzh1tecjSWLAELg_Sk=.78ec1b80-55c1-4ce3-884e-45f5ed90e445@github.com>
Message-ID: <zCVR1T7JQzL7IPgqMhUTk-5EnIovJBA9_0uxN9G6CW4=.041dbfc9-b9d2-48b7-a2d1-7df867d6504b@github.com>

On Fri, 25 Oct 2024 07:59:29 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> Another example of such a trick is available at [test/jdk/jdk/classfile/ClassBuildingTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/classfile/ClassBuildingTest.java)
>
> I initially had something like this, but was not sure if the generated classfile could differ between jdk versions/implementations. I assume this is not a valid concern for such a simple example?

Have adjusted the implementation and moved to single source file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1816334918

From duke at openjdk.org  Fri Oct 25 09:28:53 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 09:28:53 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
Message-ID: <pHXMQYbAvZ0mHXpa_gWqQ7fYUqEXlEi_TgUfMt0DXGo=.e8d9273a-66cc-4d45-9d9d-a3c7bfa8452d@github.com>

On Thu, 24 Oct 2024 16:46:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - adress feedback in implementation
>>  - address feedback in tests
>
> test/langtools/tools/javap/8034066/T8034066.java line 44:
> 
>> 42:     public void run() throws IOException {
>> 43:         String output = javap();
>> 44: 
> 
> Could you put a comment here that roughly shows what the expected output looks like? I think it would help readers understand what the following three lines are looking for.

Have added a partial snippet of the relevant part of the output.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21685#discussion_r1816333032

From stefank at openjdk.org  Fri Oct 25 09:31:09 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Oct 2024 09:31:09 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v5]
In-Reply-To: <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
Message-ID: <oq59eejHdICbFJMnj-3mrGlgFeH9P_vahgWD8BPEHgs=.3084edd8-9526-4d5b-86ec-883ef7274746@github.com>

On Fri, 25 Oct 2024 08:25:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Remove GCName::Z
>  - Merge tag 'jdk-24+21' into JDK-8341692
>    
>    Added tag jdk-24+21 for changeset 8bcd4920
>  - Merge tag 'jdk-24+20' into JDK-8341692
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8bcd4920...eef214b4

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2394745512

From eosterlund at openjdk.org  Fri Oct 25 09:37:10 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 25 Oct 2024 09:37:10 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v5]
In-Reply-To: <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
Message-ID: <30WXGwanfqdFmkKex3iqECu6rMjALS_GisqtOgSV2ek=.5c42b29d-1d38-41fe-8825-da3ad639b017@github.com>

On Fri, 25 Oct 2024 08:25:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Remove GCName::Z
>  - Merge tag 'jdk-24+21' into JDK-8341692
>    
>    Added tag jdk-24+21 for changeset 8bcd4920
>  - Merge tag 'jdk-24+20' into JDK-8341692
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8bcd4920...eef214b4

Marked as reviewed by eosterlund (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2394758948

From henryjen at openjdk.org  Fri Oct 25 09:39:07 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 25 Oct 2024 09:39:07 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <D0xaEJ-cNRKBSCU12WtFLryfYjy0vl0wYiOGQG7mjys=.dcad49d2-e244-4b00-908d-c526c1124ed0@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
 <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>
 <D0xaEJ-cNRKBSCU12WtFLryfYjy0vl0wYiOGQG7mjys=.dcad49d2-e244-4b00-908d-c526c1124ed0@github.com>
Message-ID: <qbKlykRjPeruxOdzUot6jvVPcgG2WjML9zxc8B_ntG0=.dd23020c-1101-46d0-abbe-392e232a8204@github.com>

On Fri, 25 Oct 2024 04:35:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/tools/jar/MultipleManifestTest.java line 203:
>> 
>>> 201: 
>>> 202:     private void assertOutputContains(String expected) {
>>> 203:         Assertions.assertTrue(baos.toString().contains(expected));
>> 
>> The linked JBS issue notes that the test was failing because of the additional (new) log messages from the jar tool itself. So I think the logs will be deterministic (since they aren't being generated by something else other than the jar tool). Using `contains()` thus looks fine to me.
>
> Do you think we should print out the actual and expected, when they don't match? It might make it easier to debug any unexpected failures in future.

The output is always printed in the log, so we know the actual value. If a test failed, the source code tell us the expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1816360973

From asotona at openjdk.org  Fri Oct 25 09:41:06 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 25 Oct 2024 09:41:06 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v2]
In-Reply-To: <8Hfsbc8W7ItgCmH4P7kSapfiPIym6rAsGslOo_3vg94=.92d5f913-7cb1-4111-be1b-7a8c213e9854@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
 <8Hfsbc8W7ItgCmH4P7kSapfiPIym6rAsGslOo_3vg94=.92d5f913-7cb1-4111-be1b-7a8c213e9854@github.com>
Message-ID: <5IIzPq2EK4pFsO50nQIGLSRYR3WJ47zbiVTTd5rssPE=.decdca3c-219d-4224-a702-62c9f50e1933@github.com>

On Fri, 25 Oct 2024 06:56:30 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:
> 
>   Removing incorrect sentence about writing a prompt for the prompt-less readln method.

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21693#pullrequestreview-2394768522

From ihse at openjdk.org  Fri Oct 25 10:14:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 25 Oct 2024 10:14:06 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <GMGgl1SPx74o0LZNaOAX2IjzQIY15sAhFErLpqbrra0=.cd66efd1-312b-4866-b1ce-3fa435d75bee@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
 <cVv-wFm8QKGffdCPHJwPV4F4NtWO1w76oK2BJvDFUt8=.b7f4a083-9743-4d0b-874f-06a4e2d72f8a@github.com>
 <GMGgl1SPx74o0LZNaOAX2IjzQIY15sAhFErLpqbrra0=.cd66efd1-312b-4866-b1ce-3fa435d75bee@github.com>
Message-ID: <bJ_-qsdcP1WTa00NnynZ3M9CVWJQWUu_FV7ceBGIj-c=.6c5a4982-daeb-455e-80c1-1436cf71a0bb@github.com>

On Fri, 25 Oct 2024 04:47:19 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 589:
>> 
>>> 587:   # CXXFLAGS C++ language level for all of JDK, including Hotspot.
>>> 588:   if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then
>>> 589:     LANGSTD_CXXFLAGS="-std=c++14"
>> 
>> Is this really an intention on your part, to bump the C++ level inside a PR to remove unused code? ? Or is it a merge error from a different PR?
>
> It's a checkout error from the original gigantic Pull Request, sorry. I don't plan to raise the JDK to C++17 in this one. But I'm not sure what to do with this now, since maybe_unused is C++17. I don't think anyone is going to appreciate [[gnu::unused]] inside Windows code

Then you'll have to create a macro for disabling the unused warnings (however, I'm not sure how well that would be received). Or fix the bug if it is actually unused. Or wait until we go to 17.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21655#discussion_r1816412298

From jpai at openjdk.org  Fri Oct 25 10:21:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Oct 2024 10:21:03 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <qbKlykRjPeruxOdzUot6jvVPcgG2WjML9zxc8B_ntG0=.dd23020c-1101-46d0-abbe-392e232a8204@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
 <TPvBj2hNKeEVl5FLzBDhtsevRGbf9q_UPBVqIrsuhVs=.e4e38df0-32ca-4e2b-9cb7-fc81f4609768@github.com>
 <D0xaEJ-cNRKBSCU12WtFLryfYjy0vl0wYiOGQG7mjys=.dcad49d2-e244-4b00-908d-c526c1124ed0@github.com>
 <qbKlykRjPeruxOdzUot6jvVPcgG2WjML9zxc8B_ntG0=.dd23020c-1101-46d0-abbe-392e232a8204@github.com>
Message-ID: <5drpdSBWJMArKNainC5RnaM-DWaV0aXNz5uaYwfqdL0=.ed96ca33-7d27-49ba-9958-0a35ff7efeac@github.com>

On Fri, 25 Oct 2024 09:36:41 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Do you think we should print out the actual and expected, when they don't match? It might make it easier to debug any unexpected failures in future.
>
> The output is always printed in the log, so we know the actual value. If a test failed, the source code tell us the expected.

Thank you Henry, I believe that's good enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1816419731

From alanb at openjdk.org  Fri Oct 25 10:24:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 10:24:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzu
 Zr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
 <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@github.com>
Message-ID: <bIj9x7QeQeCoCgHy7PkpwOy0SLdF2lRnZ8oKN7yjILk=.4f23be55-161c-46f9-b3b7-86ae1426fbb6@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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816425590

From duke at openjdk.org  Fri Oct 25 10:26:05 2024
From: duke at openjdk.org (Jonathan =?UTF-8?B?TGFtcMOpcnRo?=)
Date: Fri, 25 Oct 2024 10:26:05 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <nP2RQ65U-dLYCZ4zqG-mQWcQubvIPEd_OOrAk96WZqY=.8c6ec907-60c5-4339-b69d-774659f13fee@github.com>
Message-ID: <3WzotMeV2mA4HkUTDORqYoSLAWwfyzPy6uYsm2gwzdo=.92a6362a-437b-4c2d-8280-2be2211a92cd@github.com>

On Thu, 24 Oct 2024 16:48:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - adress feedback in implementation
>>  - address feedback in tests
>
> I think I prefer your idea of keeping the code inside `CodeWriter`.
> 
> Maybe have a `write` and a `writeVerbose`, and have a private method with a `boolean` param that controls printing of extra info?

@JornVernee 

> I think I prefer your idea of keeping the code inside `CodeWriter`.
> 
> Maybe have a `write` and a `writeVerbose`, and have a private method with a `boolean` param that controls printing of extra info?

Not sure about the wording of using `writeVerbose`. It just happens that in the case when the `-verbose` flag is set, that `task.options.showAllAttrs = true;` is set, which leads to writing out the "complete" output of the `CodeWriter`. I think the non-verbose case is the exception, where we override the default `write` functionality. Thus I have opted for keeping the functionality and naming of `write` and adding a new function `writeMinimal` as the "non-standard" case. What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21685#issuecomment-2437425971

From shade at openjdk.org  Fri Oct 25 10:48:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Oct 2024 10:48:04 GMT
Subject: RFR: 8342642: Class loading failure due to archived map issue in
 ModuleLoaderMap.Mapper
In-Reply-To: <CN35o-nur_x4gzjcNPHA1x7nh2CSdKDQylstjuE4wqo=.0f1d2a64-869f-4ec7-8dae-d349b763b436@github.com>
References: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
 <Uy7sY_UaGyqS8dliTx1fbvEy_4_HuEDVgb2ZiirMIbw=.afbc0f19-1431-47a6-aec7-b71d1c686773@github.com>
 <uQOrLdzHHGFc7GGCBl1XGucRfBFgrgCsUKl6e429Pi4=.c6939582-9d0c-4369-a0b7-99aca94e2787@github.com>
 <CN35o-nur_x4gzjcNPHA1x7nh2CSdKDQylstjuE4wqo=.0f1d2a64-869f-4ec7-8dae-d349b763b436@github.com>
Message-ID: <lBvja_qrgmeac0nZY84eqFuTAjbk_qUGzacRgoAebxc=.b9d25e13-5114-4292-b6c5-556b614b711f@github.com>

On Thu, 24 Oct 2024 21:20:57 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> In that sense, I think we don't have a risk of potentially with `used_Integer > IntegerCache.high`. The idea described in Ioi's comment above (also brought up by Aleksey Shipilev separately during premain meeting) could be sufficient.

Phew, thanks! I thought I was misunderstanding some fundamental thing here :) I think `IntegerCache` interaction with CDS archive deserves a fix regardless. Have you filed the bug for it, @jianglizhou? AFAICS, if we fix `IntegerCache` <-> CDS interaction, we solve this particular problem as well.

I am still non-committal about this special fix. We can still do it, but then this patch effectively changes relying on boxing identity behavior over `Integer`s to relying on interning behavior over `Strings`, right? If we want to be 100% safe, shouldn't `==` checks be rewritten to `equals`? And when we do so, would that affect startup in any meaningful way?

The names of the fields should probably be changed from `_INDEX` to something else, like `_NAME`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21672#issuecomment-2437465648

From jlahoda at openjdk.org  Fri Oct 25 10:57:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Oct 2024 10:57:07 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v5]
In-Reply-To: <bCa_dSlhLoNTigAiaVIbLyRQ1XKMNLzZizjZ3ULVfSw=.17a40eb7-4c30-4e78-a0d2-f1e63e8ed591@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <1lAqvR59LNaK3sSbf-ZeXgHav93nP9EVQnmu3wG0P1Q=.85613333-5df5-4d54-bf07-463c85d1a624@github.com>
 <bCa_dSlhLoNTigAiaVIbLyRQ1XKMNLzZizjZ3ULVfSw=.17a40eb7-4c30-4e78-a0d2-f1e63e8ed591@github.com>
Message-ID: <RjmFmh-RwOtmYLxN0bd6WqpocTUrosyt-tbAsGsNsD4=.48e588b2-ef49-424e-92df-b0cebf0b108a@github.com>

On Thu, 24 Oct 2024 10:10:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   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".
>
> src/java.base/share/native/libjli/java.c line 546:
> 
>> 544: 
>> 545:     /* If the user specified neither a class name nor a JAR file */
>> 546:     if (printUsageKind != HELP_NONE) {
> 
> Is the state check for `what` and `mode` no longer needed here?

The idea was that `printUsageKind` should replace that - specifically, `HELP_CONCISE` should be equivalent to the original `what == 0 || mode == LM_UNKNOWN`. The code is a bit cryptic, so I hope I managed to achieve that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1816473575

From alanb at openjdk.org  Fri Oct 25 11:07:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 11:07:07 GMT
Subject: RFR: 8342642: Class loading failure due to archived map issue in
 ModuleLoaderMap.Mapper
In-Reply-To: <nwhzx5Bh9fK6gNjlqigk7vU3BsBvzI-BBDNwOkerzr8=.6a1dc8a4-98e4-4a61-a10b-44dfa9494777@github.com>
References: <aArlUU9ANOOkgTVNqy9kOog7go-DytgoqBny8szs5Dc=.7ac18b6b-dbea-4728-98a8-da55a3c2184f@github.com>
 <nwhzx5Bh9fK6gNjlqigk7vU3BsBvzI-BBDNwOkerzr8=.6a1dc8a4-98e4-4a61-a10b-44dfa9494777@github.com>
Message-ID: <B_oBEH2t4_w2-Ip8gC54cI59JcQBWZfGr4_LkDRtGeM=.95ebe5d3-4ef9-4939-9b25-12db58ddf4c5@github.com>

On Thu, 24 Oct 2024 20:16:59 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> The conclusion was it's better to avoid using boxed Integer and go with String in ModuleLoaderMap.Mapper.

Okay, you'll need to rename the fields and Mapper's description will need to be updated as explains why a boxed value was used.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21672#issuecomment-2437501231

From mcimadamore at openjdk.org  Fri Oct 25 11:15:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 11:15:12 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v3]
In-Reply-To: <UdmVa_Bz2ey3j8gGHM_nOgGRXI3cUJeIUVc3mOi4YgU=.ea8d70c7-589e-4e51-a8b3-e4bf0bd90465@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZK6M1ol-NjNZGpnzIIqh7941xEHhjSZpuXdZr1iIDug=.b68fdb01-2d1a-41bb-90d5-7ed86f87bf87@github.com>
 <UdmVa_Bz2ey3j8gGHM_nOgGRXI3cUJeIUVc3mOi4YgU=.ea8d70c7-589e-4e51-a8b3-e4bf0bd90465@github.com>
Message-ID: <7vquAKTYiefBLBfY4j-AYmZiJcwg9AHSnxNFk5TFVaE=.1e826818-0aba-470a-8d01-fab6bba40a2f@github.com>

On Wed, 16 Oct 2024 17:38:17 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> The file separator is a secondary concern and could be moved to the end of the sentence:
> 
> ```
> Where key java options include:
>   --class-path <class path>
>       a list of directories and JAR archives to search for class files, separated by ":"
>   --module-path <module path>
>       a list of directories and JAR archives to search for modules, separated by ":"
> ```

I agree with this comment. I also have another observation - it is not super obvious that "a list of directiories ..."  is a description for what a <class path> or <module path> is. You kind of guess that being the case (what else can it be?) but something like:


 --class-path <class path>
        where <class path> is a list of directories and JAR archives to search for class files, separated by ":"

Seems more crystal clear?

(Btw, the reason I like moving `:` at the end is that you want users to quickly graps what <class path> is - and this trick does that: "a class path is a list of directories and jars" - whether they're `:` or `#!?` separated, that's a second-order concern at this point (as we're still defining the term).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2437510741

From mcimadamore at openjdk.org  Fri Oct 25 11:17:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 11:17:11 GMT
Subject: RFR: 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: <XGcLK6Iss-kqORr6CfjFkTZOOK2e0QBu58RSS_zH0FU=.c439270f-9c5e-4470-84bd-d609895c35dd@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.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21691#pullrequestreview-2394980975

From psadhukhan at openjdk.org  Fri Oct 25 11:19:41 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 11:19:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <N9SCzjHG3Q-GHIk6nNj7s8_vQBkx_dirVhnTjhWpWw0=.d298d7d7-4fab-46e7-9f07-f4f39f308478@github.com>

On Thu, 24 Oct 2024 13:19: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 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

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2394343323

From dfuchs at openjdk.org  Fri Oct 25 11:19:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Oct 2024 11:19:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <XK2j-0yrasFNv7xEkGgkrwWX09OJD29pcQPMmVd88kU=.13059532-b236-45bf-b788-626491003998@github.com>

On Thu, 24 Oct 2024 13:19: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 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

For the record I had a look at the changes in JMX and JNDI tests and these look good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2437522137

From alanb at openjdk.org  Fri Oct 25 11:20:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 11:20:10 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices [v2]
In-Reply-To: <UQ612RgSfwXTzfgWL9ErEqGkgktW8pdTXTzX2jRNUvo=.a6231eea-0ab6-4d38-bc63-87a8c7fa0a32@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
 <NGyEj0JwRNPj9hi0eFdOYX2KHlPA2b_642BsBcBlYXE=.5040051a-574c-4c98-8b33-c64a728e2714@github.com>
 <97MGOglCWpHjwzAxhlEJBQMT9uR0Zu_wsewRmor6z0M=.afe4de22-4977-4afe-8ce1-f127e2b31ec2@github.com>
 <uiI6sbxL_fxtqRFyOzbzxsN_Ws6lc6FXcP7V4xMeVNA=.1273b78f-7a09-46aa-8eb3-c0ceb89d897f@github.com>
 <-O2Ls_9kZP9fMJnRI5Mxh_Xp_rLuErlhGZdEdGCzvnE=.bd377750-eded-4932-bd9a-489562109d70@github.com>
 <UQ612RgSfwXTzfgWL9ErEqGkgktW8pdTXTzX2jRNUvo=.a6231eea-0ab6-4d38-bc63-87a8c7fa0a32@github.com>
Message-ID: <NiAjdjPL0MXfzzx12HM2Cbnv3S6Pm69gxSSNnZMMHvM=.495838c2-1f13-48c0-8c3f-6d4e437cad39@github.com>

On Thu, 24 Oct 2024 15:13:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> [...] do you think we should reduce these native calls in this change and call `canSeek()` just once [...]
>> 
>> I think that is a good idea but I would think it best to do i in a similar way to the recent change to `ChannelInputStream` that added `isOther`.
>
>> I think the main thing with this PR is whether canSeek is the right thing to use.
> 
> `canSeek` is really the same as `isOther` in the recent `Files.newInputStream` change, but given that on Windows the result of the function is always `true`, the naming `isOther` (which would always return `false`) did not seem apropos.

I think it would be limit to limit is to regular files, in which case canSeek could be isRegularFile and just check S_ISREG. The Windows implementation that just assume it's a regular file until there is a better implementation. Up to you but I think it would make it much clearer. Longer time we need to re-target this to use FileChannelImpl but several issues to work through before then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21673#discussion_r1816500743

From aivanov at openjdk.org  Fri Oct 25 11:38:37 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 11:38:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@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>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
 <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
 <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>
Message-ID: <xmvA-xWfN2PbFLJsskbi8HNSDlJ6ANEKeWuzLgqlzrk=.b2eb7e3f-4f25-4c3e-b5c0-e29705ab9ce4@github.com>

On Thu, 24 Oct 2024 21:06:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> It was missed when `-Djava.security.manager=allow` was removed.
>> 
>> It wasn't intentional then, was it?
>> 
>>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?
>> 
>> I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.
>> 
>> Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.
>> 
>> https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49
>> 
>> It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.
>
> @aivanov-jdk 
> Right, it wasn't intentional but missed when removing `-Djava.security.manager=allow`.
> 
>> Anyway, removing /othervm isn't strictly required because java/beans are run in othervm mode.
> 
> Thank you for clarifying. Since `/othervm` doesn't impact the beans tests I'll keep it as-is. Let me know if you still think it is good idea to remove it, I could do a find and replace-all on beans/XMLEncoder/ test folder.

@honkar-jdk I've submitted [JDK-8343062](https://bugs.openjdk.org/browse/JDK-8343062) for additional cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816521679

From coleenp at openjdk.org  Fri Oct 25 12:03:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 12:03:21 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: <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>

On Fri, 25 Oct 2024 03:51:08 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.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 Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816550112
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816551794

From jwaters at openjdk.org  Fri Oct 25 12:05:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 25 Oct 2024 12:05:07 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <bJ_-qsdcP1WTa00NnynZ3M9CVWJQWUu_FV7ceBGIj-c=.6c5a4982-daeb-455e-80c1-1436cf71a0bb@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
 <cVv-wFm8QKGffdCPHJwPV4F4NtWO1w76oK2BJvDFUt8=.b7f4a083-9743-4d0b-874f-06a4e2d72f8a@github.com>
 <GMGgl1SPx74o0LZNaOAX2IjzQIY15sAhFErLpqbrra0=.cd66efd1-312b-4866-b1ce-3fa435d75bee@github.com>
 <bJ_-qsdcP1WTa00NnynZ3M9CVWJQWUu_FV7ceBGIj-c=.6c5a4982-daeb-455e-80c1-1436cf71a0bb@github.com>
Message-ID: <qVN0u18w-xMG8hAZeb3lY4ZTYUM76EkGHQqRVEq3TEQ=.e33523ce-8e99-4402-b298-b52bc9d3bb81@github.com>

On Fri, 25 Oct 2024 10:11:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> It's a checkout error from the original gigantic Pull Request, sorry. I don't plan to raise the JDK to C++17 in this one. But I'm not sure what to do with this now, since maybe_unused is C++17. I don't think anyone is going to appreciate [[gnu::unused]] inside Windows code
>
> Then you'll have to create a macro for disabling the unused warnings (however, I'm not sure how well that would be received). Or fix the bug if it is actually unused. Or wait until we go to 17.

I don't think it's a bug since the error is an unused pointer typedef, and it seems customary to provide the pointer typedef alongside the actual struct in awt code, even if not needed. I could just disable the warning for the file in the port, but that way no more potential bugfixes in that file would be possible

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21655#discussion_r1816554048

From vklang at openjdk.org  Fri Oct 25 12:24:07 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 25 Oct 2024 12:24:07 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v5]
In-Reply-To: <7z5sxU8bf7S6mIlyzd0li2i6GKAxzLWE5J9Tlq4Ym4Q=.2ed1cd3d-dc79-48f7-9127-633a7ae106d0@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <7z5sxU8bf7S6mIlyzd0li2i6GKAxzLWE5J9Tlq4Ym4Q=.2ed1cd3d-dc79-48f7-9127-633a7ae106d0@github.com>
Message-ID: <9rQxDRTFItJM-BGGTWeI9rlACyAgtvmaai6chSN9m4c=.527ca66f-50e4-4935-8a0f-b3b6c055fcfe@github.com>

On Thu, 24 Oct 2024 20:41:46 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:
> 
>   For starvation check #2

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1272:

> 1270:             int s = top, b = base, m, cap, room; ForkJoinTask<?>[] a;
> 1271:             if ((a = array) != null && (cap = a.length) > 0 &&
> 1272:                 task != null) {                             // else disabled

Can `task` ever be null here? or is this check just to avoid subsequent implicit nullchecks?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1816581681

From jlahoda at openjdk.org  Fri Oct 25 12:45:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Oct 2024 12:45:25 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v6]
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: <ZR2sc2jqswIemj9OOUCCYDwdvT14emhKMO3gKl44s7Y=.c196ef43-284a-454f-9809-318ab8bf9759@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 two additional commits since the last revision:

 - Using correct pplaceholders.
 - Adjusting text as suggested.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21411/files
  - new: https://git.openjdk.org/jdk/pull/21411/files/dc85a167..d1d6e4ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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  Fri Oct 25 12:48:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 25 Oct 2024 12:48:10 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v5]
In-Reply-To: <1lAqvR59LNaK3sSbf-ZeXgHav93nP9EVQnmu3wG0P1Q=.85613333-5df5-4d54-bf07-463c85d1a624@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <1lAqvR59LNaK3sSbf-ZeXgHav93nP9EVQnmu3wG0P1Q=.85613333-5df5-4d54-bf07-463c85d1a624@github.com>
Message-ID: <hkgv_v5OGrc2GS5Ngy41VPQ1S2EItVN-WGyUJbOKAKA=.8294c653-8125-47b9-8088-1ffbb407ea8e@github.com>

On Tue, 22 Oct 2024 11:06:44 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:
> 
>   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".

> > The file separator is a secondary concern and could be moved to the end of the sentence:
> > ```
> > Where key java options include:
> >   --class-path <class path>
> >       a list of directories and JAR archives to search for class files, separated by ":"
> >   --module-path <module path>
> >       a list of directories and JAR archives to search for modules, separated by ":"
> > ```
> 
> I agree with this comment. I also have another observation - it is not super obvious that "a list of directiories ..." is a description for what a or is. You kind of guess that being the case (what else can it be?) but something like:
> 
> ```
>  --class-path <class path>
>         where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
> ```
> 
> Seems more crystal clear?
> 
> (Btw, the reason I like moving `:` at the end is that you want users to quickly graps what is - and this trick does that: "a class path is a list of directories and jars" - whether they're `:` or `#!?` separated, that's a second-order concern at this point (as we're still defining the term).

Ok:
https://github.com/openjdk/jdk/pull/21411/commits/f1f7cc8006dcd2bdefe5bbc90936c6ccbdf044ab

(text in the description updated)

I checked, and the default line length for `cmd` on Windows 10 appears to be 120 characters. the longest line is now 108 characters long. So, we are nearing the hard-limit for the text.

I also start to wonder if adding the text for these options lights its weight, and whether it wouldn't be better to just skip the options, leading to a leaner, shorter help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2437683715

From pchilanomate at openjdk.org  Fri Oct 25 13:17:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 13:17:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
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: <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@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:

 - Add comments for Coleen
 - Fix JvmtiUnmountBeginMark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/c7a82c45..0308ee4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=08-09

  Stats: 22 lines in 6 files changed: 10 ins; 8 del; 4 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 Oct 25 13:17:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 13:17:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
Message-ID: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>

On Wed, 23 Oct 2024 22:59:19 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:
>> 
>>  - Add comments for Coleen
>>  - Fix JvmtiUnmountBeginMark
>
> 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/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/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 1552:
> 
>> 1550:   assert(!cont.is_empty(), "");
>> 1551:   // This is done for the sake of the enterSpecial frame
>> 1552:   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/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.

-------------

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_r1816660542
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_r1816662554
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816663065

From jvernee at openjdk.org  Fri Oct 25 13:46:05 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 25 Oct 2024 13:46:05 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
Message-ID: <S_TgHacDPxuvj3ncEN9_9SWzQMXbp6GEPBR-WakZmB4=.ff817e4b-191b-4f24-befd-b0250a79f6e1@github.com>

On Fri, 25 Oct 2024 09:28:53 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - adress feedback in implementation
>  - address feedback in tests

Looks great, thanks!

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21685#pullrequestreview-2395341712

From mullan at openjdk.org  Fri Oct 25 13:47:42 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 25 Oct 2024 13:47:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
Message-ID: <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>

On Tue, 22 Oct 2024 20:23:52 GMT, Roger Riggs <rriggs 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 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
> 
>> 38:  *
>> 39:  * @apiNote
>> 40:  * This permission cannot be used for controlling access to resources anymore
> 
> Unnecessary "anymore"

Removed this word from all `Permission` subclasses; fix will be in next update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816717534

From rriggs at openjdk.org  Fri Oct 25 14:33:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Oct 2024 14:33:09 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v6]
In-Reply-To: <ZR2sc2jqswIemj9OOUCCYDwdvT14emhKMO3gKl44s7Y=.c196ef43-284a-454f-9809-318ab8bf9759@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <ZR2sc2jqswIemj9OOUCCYDwdvT14emhKMO3gKl44s7Y=.c196ef43-284a-454f-9809-318ab8bf9759@github.com>
Message-ID: <3vWph71R6RIrXwN3ZtxxMC10G1je4z8NBC6KWXb3Wwc=.517f8628-56cd-4b65-9eac-12475f099942@github.com>

On Fri, 25 Oct 2024 12:45:25 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 two additional commits since the last revision:
> 
>  - Using correct pplaceholders.
>  - Adjusting text as suggested.

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21411#pullrequestreview-2395480750

From henryjen at openjdk.org  Fri Oct 25 14:38:10 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 25 Oct 2024 14:38:10 GMT
Subject: Integrated: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
Message-ID: <4apyeiE6kZKn_JrE5BLDmiPDCSmJYv2R9dnvlYeEEJE=.c4772876-fa67-4971-a8b2-f373855c3a3c@github.com>

On Fri, 25 Oct 2024 01:38:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Check output for including values rather than exact match.
> Also include the manpage change  and revert the problem list.

This pull request has now been integrated.

Changeset: 5cbd578f
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cbd578fbe9df4f68ab21bf764208ad4f67443f6
Stats:     30 lines in 4 files changed: 19 ins; 3 del; 8 mod

8342930: New tests from JDK-8335912 are failing

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/21697

From asmehra at openjdk.org  Fri Oct 25 15:05:12 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 25 Oct 2024 15:05:12 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <dQQmsawG5xpu_rrJmjGOfEs0LjV0gkYSqEBoTUXvU8M=.31d49b2e-1565-4fb0-b0b5-9ef82669ffe4@github.com>

On Thu, 24 Oct 2024 03:01:54 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 two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

src/hotspot/share/cds/aotClassLinker.cpp line 117:

> 115: 
> 116: void AOTClassLinker::add_candidate(InstanceKlass* ik) {
> 117:   _candidates->put_when_absent(ik, true);

I just noticed the use of `put_when_absent` here. This means the caller should ensure that `ik` has not already been added to the `_candidates`. We do that currently (`try_add_candidate` calls `is_candidate` before calling `add_candidate`) but probably worth mentioning this contract explicitly in a comment somewhere for future readers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1816850893

From asemenyuk at openjdk.org  Fri Oct 25 15:06:45 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 25 Oct 2024 15:06:45 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v7]
In-Reply-To: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
Message-ID: <WkGJdVFU7U9hlqn_XUuwwDjnFUlmm7yJExWK2DjWnIw=.69e1bb23-1176-4250-b087-f99574539b5b@github.com>

> Make jpackage correctly handle the output directory (`--dest`) that is:
>  - a subdirectory of the input directory;
>  - the same as the input directory.
> 
> Make jpackage correctly handle temp directory (`--temp`) that is:
>  - a subdirectory of the input directory.
> 
> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
> 
> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
> 
> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
> 
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
> 
> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  All new InOutPathTest test cases pass

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21550/files
  - new: https://git.openjdk.org/jdk/pull/21550/files/f54e88bb..1d38f2ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21550&range=05-06

  Stats: 25 lines in 2 files changed: 19 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21550.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21550/head:pull/21550

PR: https://git.openjdk.org/jdk/pull/21550

From liach at openjdk.org  Fri Oct 25 15:07:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 25 Oct 2024 15:07:11 GMT
Subject: RFR: 8034066: Incorrect alignment in the "Code" section for
 "-c -XDdetails" options [v2]
In-Reply-To: <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
References: <Dq6FTZWX3EbKTh-a-mHqQ1RW8Azh1u7T0VKcqHfKT-0=.49074949-36a6-4a96-8ad2-37a6587e0177@github.com>
 <Mbqa8xMUJiMDgQ1AKs-iFi3ESaaB1tHQzxE4UHseITo=.7ada4108-75f7-4a6f-bed1-2cc861ce2c13@github.com>
Message-ID: <Pzvr8gvg3Zx2fDxc01bvtZvKqyJFbuPbXQW3lbKhPUk=.dd1d9dba-04d0-44e0-9aee-dedbed6d075a@github.com>

On Fri, 25 Oct 2024 09:28:53 GMT, Jonathan Lamp?rth <duke at openjdk.org> wrote:

>> This PR includes changes to ensure `Code:` block indentation in `javap`for the `-verbose` case and non `-verbose` case is the same, which currently does not hold.
>> 
>> Current behaviour of `javap` differs with and without `-verbose` in the following way:
>> **Command**: `javap -c -XDdetails:stackMaps A.class`
>> 
>> Without `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     Code:
>>        0: iconst_0
>>        1: istore_1
>>     StackMap locals:  this int
>>     StackMap stack:
>> ...
>> 
>> 
>> With `-verbose`
>> 
>> 
>> ...
>>   public void a();
>>     descriptor: ()V
>>     flags: (0x0001) ACC_PUBLIC
>>     Code:
>>       stack=2, locals=2, args_size=1
>>          0: iconst_0
>>          1: istore_1
>>       StackMap locals:  this int
>>       StackMap stack:
>> ...
>> 
>> 
>> With `-verbose` all contents of the `Code:` section include an extra (2 space) indent, which is missing in the non `-verbose` case. This is because the `CodeWriter` is called via `CoderWriter.write(...)` in the `-verbose` case, which wraps the `Code:` block in `indent(+1);...indent(-1)`.
>> 
>> In the non-verbose case this call is circumvented and a simplified version of `CoderWriter.write(...)` is included directly in `ClassWriter.writeMethod`.
>> 
>> ---
>> 
>> Alternatively to keep the logic within `CodeWriter` with the goal of keeping the logic for `-verbose` and non `-verbose` in the same place one could add `CodeWriter.writeSimple(...)`.
>> 
>> 
>> void writeSimple(CodeAttribute attr) {
>>         println("Code:");
>>         indent(+1);
>>         writeInstrs(attr);
>>         writeExceptionTable(attr);
>>         indent(-1);
>>     }
>> 
>> 
>> ---
>> 
>> Note: Test setup is inspired by existing tests: [T6622232.java](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/T6622232.java) and [8244573](https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javap/8244573)
>
> Jonathan Lamp?rth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - adress feedback in implementation
>  - address feedback in tests

Looks good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21685#pullrequestreview-2395574746

From jvernee at openjdk.org  Fri Oct 25 15:09:11 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 25 Oct 2024 15:09:11 GMT
Subject: RFR: 8342902: Deduplication of acquire calls in BindingSpecializer
 causes escape-analyisis failure
In-Reply-To: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
References: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
Message-ID: <EPbe4jYWRTNEeMR0eWn0O5TYDs8nYFCTo4a-k-1ONUM=.83fd2bad-c0cb-47c7-88b0-447103c0575a@github.com>

On Fri, 25 Oct 2024 08:37:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes an issue where passing many by-reference parameters to downcall results in escape analysis failures.
> The problem is that, as the parameters grow, the generated code in the trampoline stub we generate also grows.
> When it reaches a certain threshold, it becomes too big, and it is no longer inlined in the caller.
> When this happens, allocations for by-reference parameters (e.g. a segment constructed from `MemorySegment::ofAddress`) can no longer be eliminated.
> 
> The solution is two-fold. First, we annotate the generated trampoline with `@ForceInline`. After all, it is rather critical, to guarantee optimal performance, that this code can be always inlined.
> Second, to keep the size of the generated code under control, we also put a limit on the max number of comparisons that are generated in order to "deduplicate" scope acquire/release calls.
> The deduplication logic is a bit finicky -- it was put in place because, when confined and shared are passed by-ref, we need to prevent them from being closed in the middle of a native call.
> So, we save all the seen scopes in a bunch of locals, and then we compare each new scope with _all_ the previous cached locals, and skip acquire if we can.
> 
> While this strategy work it does not scale when there are many by-ref parameters - as a by-ref parameter N will need N - 1 comparisons - which means a quadratic number of comparisons is generated.
> This is fixed in this PR by putting a lid on the maximum number of comparisons that are generated. We also make the comparisons a bit smarter, by always skipping the very first by-ref argument -- the downcall address.
> It is in fact very common for the downcall address to be in a different scope than that of the other by-ref arguments anyway.
> 
> A nice property of the new logic is that by configuring the max number of comparisons we can effectively select between different strategies:
> * max = 0, means no dedup
> * max = 1, means one-element cache
> * max = N, means full dedup (like before)
> 
> Thanks to Ioannis (@spasi) for the report and the benchmark. I've beefed the benchmark up by adding a case for 10 arguments, and also adding support for critical downcalls, so we could also test passing by-ref heap segments. Benchmark result will be provided in a separate comment.

Looks great, aside from the native lib issue (inline)

test/micro/org/openjdk/bench/java/lang/foreign/libCallByRefHighArity.c line 33:

> 31: EXPORT void noop_params5(int param0, int param1, void *param2, void *param3, void *param4) {}
> 32: EXPORT void noop_params10(int param0, int param1, void *param2, void *param3, void *param4,
> 33:                           int param5, int param6, void *param7, void *param8, void *param9) {}

Some of these are `int` which mismatches the `ADDRESS` layout used to create the function descriptor.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21706#pullrequestreview-2395567620
PR Review Comment: https://git.openjdk.org/jdk/pull/21706#discussion_r1816850025

From asmehra at openjdk.org  Fri Oct 25 15:11:11 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 25 Oct 2024 15:11:11 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <tP5EfzpobXgMoEGxbYC-LD7J7Pk320Jm3-pOngBVv7M=.31f1a153-6e12-41b5-adca-79ee78117279@github.com>

On Thu, 24 Oct 2024 03:01:54 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 two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

@iklam I remember there was [ConstantPool::iterate_archivable_resolved_references](https://github.com/iklam/jdk/blob/f0bc1ae60fea80d5914d520457986a753e75fae4/src/hotspot/share/oops/constantPool.cpp#L288) in https://github.com/openjdk/jdk/pull/21143 but I don't see it any more in this PR. Can you please comment on why was that removed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2438079354

From lancea at openjdk.org  Fri Oct 25 15:28:10 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 25 Oct 2024 15:28:10 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
Message-ID: <VGc3Lcv6M9MAGhxY3bCExjWqygQ_DcATADhRd7ydRSc=.9541211b-1a98-44bf-9257-b2a4a59fa7dc@github.com>

On Fri, 25 Oct 2024 01:38:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Check output for including values rather than exact match.
> Also include the manpage change  and revert the problem list.

I am not sure how others feel, but I think that the jar tool man page changes should be separate from the changes to the test

Otherwise it is OK

test/jdk/tools/jar/ExtractFilesTest.java line 185:

> 183:         Assertions.assertTrue(baos.toString().contains(expected));
> 184:     }
> 185: 

Is this really needed  vs just including the Assertions.assertTrue where you are replacing the existing Assertions.assertArrayEquals?

I only ask as there is no additional validation in the method being added so outside of  the change in methods.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21697#pullrequestreview-2395650507
PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1816916373

From michaelm at openjdk.org  Fri Oct 25 16:11:46 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Oct 2024 16:11:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <TJNWAEiPXYUxNLNQSveRSSTbV6KUK2aDTjUBN-V-Q9M=.97954e4d-05d7-480a-94a6-ca283458596d@github.com>

On Thu, 24 Oct 2024 13:19: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 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

I've reviewed the networking tests and they look fine. There are tests that possibly don't need the `othervm` keyword any more, and some tests that still do permission implies tests (without a security manager) but these can be updated independently in future PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438222428

From naoto at openjdk.org  Fri Oct 25 16:24:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 25 Oct 2024 16:24:07 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v2]
In-Reply-To: <8Hfsbc8W7ItgCmH4P7kSapfiPIym6rAsGslOo_3vg94=.92d5f913-7cb1-4111-be1b-7a8c213e9854@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
 <8Hfsbc8W7ItgCmH4P7kSapfiPIym6rAsGslOo_3vg94=.92d5f913-7cb1-4111-be1b-7a8c213e9854@github.com>
Message-ID: <ohu7e1UFGq3R3_llXud7x3yERci-lcWZivWIznyvUsU=.faf6261c-3a1a-4ad1-ac31-13603d05e98e@github.com>

On Fri, 25 Oct 2024 06:56:30 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:
> 
>   Removing incorrect sentence about writing a prompt for the prompt-less readln method.

+1

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21693#pullrequestreview-2395793885

From sgehwolf at openjdk.org  Fri Oct 25 16:29:52 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 25 Oct 2024 16:29:52 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v40]
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: <dzvJywrIZpOXOPMf8qqB4yBEdjZCQrVMStCpvvY7d3A=.94956783-7874-4dfd-a449-c6d379620af2@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 five additional commits since the last revision:

 - Better handle patched modules
   
   Also add a test which ensures that module patching (if present), will
   get an appropriate error message.
 - Add /othervm to some langtools tier1 tests
   
   Those tests are using module patches from JTREG. Since the run-time
   image based link uses ModuleFinder.ofSystem(), which will see the extra
   classes comming from the module patch. Then the size look-up using the
   JRT FS provider fails, since that only looks in the module image
   (lib/modules) and NOT also in the patch. Thus, we get a
   NoSuchFileException and the link fails.
   
   Run the tests with othervm so that the JTREG patch'ed module isn't
   visible to the test.
 - Fix tests for builds with --enable-linable-runtime
   
   Those builds don't include the packaged modules, `jmods` directory.
   However, some tests assume that they're there. Add appropriate requires
   tag.
 - Fix provider verification when some JMODs are present
   
   In some configurations, e.g. when java.base is missing from the packaged
   modules, but another JDK module is present as JMOD that is linked into
   an image, then provider verification can fail. Thus, the run-time image
   link fails. Verify that this doesn't happen.
   
   The fix is to return Platform.runtime() for run-time image based links
   as well. Otherwise this code would return the wrong result.
 - Show run-time image based capability in help
   
   Also add a test for it when it's turned on and off.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/22eb4b89..83a86d06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=38-39

  Stats: 501 lines in 13 files changed: 434 ins; 28 del; 39 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 henryjen at openjdk.org  Fri Oct 25 16:34:10 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 25 Oct 2024 16:34:10 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <VGc3Lcv6M9MAGhxY3bCExjWqygQ_DcATADhRd7ydRSc=.9541211b-1a98-44bf-9257-b2a4a59fa7dc@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
 <VGc3Lcv6M9MAGhxY3bCExjWqygQ_DcATADhRd7ydRSc=.9541211b-1a98-44bf-9257-b2a4a59fa7dc@github.com>
Message-ID: <74CsCJmFU8ppWKRaL8DCVtLchZWZKDGacCkLGe5Qe34=.aff2406a-0c00-4f53-91a2-84811f4acc7d@github.com>

On Fri, 25 Oct 2024 15:24:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Check output for including values rather than exact match.
>> Also include the manpage change  and revert the problem list.
>
> test/jdk/tools/jar/ExtractFilesTest.java line 185:
> 
>> 183:         Assertions.assertTrue(baos.toString().contains(expected));
>> 184:     }
>> 185: 
> 
> Is this really needed  vs just including the Assertions.assertTrue where you are replacing the existing Assertions.assertArrayEquals?
> 
> I only ask as there is no additional validation in the method being added so outside of  the change in methods.

Valid points.

A separate ticket is certainly better, or perhaps I should change the ticket title. In a sense, I consider the man page change a missing part, and follow up work of the origin ticket, just like test failure.

The extra method is so that we if we need to change the verification again. The method could be better named as `verifyOutput` or else to reveal the intention better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1817011375

From bpb at openjdk.org  Fri Oct 25 16:35:49 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 16:35:49 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices [v3]
In-Reply-To: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
Message-ID: <Bg6S8T3Uzm01UreJlTzb6tRmoS-nmSO_jv07KVkjeDc=.7086a1cc-c733-4411-88ba-375cdc18cba3@github.com>

> Modify `FileInputStream` (FIS) to fall back to the superclass implementations of `readAllBytes()`, `readNBytes(int)`, `skip()`, and `transferTo` when the input source would otherwise fail with "Illegal Seek" in the FIS implementation, such as for the standard input or a named pipe.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8341666: Change [cC]anSeek to [iI]sRegularFile

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21673/files
  - new: https://git.openjdk.org/jdk/pull/21673/files/d6b679d3..0bb34b4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21673&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21673&range=01-02

  Stats: 22 lines in 6 files changed: 0 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/21673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21673/head:pull/21673

PR: https://git.openjdk.org/jdk/pull/21673

From lancea at openjdk.org  Fri Oct 25 16:43:09 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 25 Oct 2024 16:43:09 GMT
Subject: RFR: 8342930: New tests from JDK-8335912 are failing
In-Reply-To: <74CsCJmFU8ppWKRaL8DCVtLchZWZKDGacCkLGe5Qe34=.aff2406a-0c00-4f53-91a2-84811f4acc7d@github.com>
References: <QSOcnGcQFQvOJP3exVWVFjHeWSJtiF3wwpPLegCw25U=.f2280b51-3d13-4f5f-a2db-8fd40c46522b@github.com>
 <VGc3Lcv6M9MAGhxY3bCExjWqygQ_DcATADhRd7ydRSc=.9541211b-1a98-44bf-9257-b2a4a59fa7dc@github.com>
 <74CsCJmFU8ppWKRaL8DCVtLchZWZKDGacCkLGe5Qe34=.aff2406a-0c00-4f53-91a2-84811f4acc7d@github.com>
Message-ID: <WvmPIYW47GqcoMBWBWg_jZnkgQA-ilb4cAmOjO0VfYw=.96e9c43b-d42c-4a2b-8df5-99e01db3bb96@github.com>

On Fri, 25 Oct 2024 16:30:24 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Valid points.
> 
> A separate ticket is certainly better, or perhaps I should change the ticket title. In a sense, I consider the man page change a missing part,

Yes it could have been part of the original PR, but it is separate from fixing a test bug which is why IMHO it should be a separate PR
 and follow up work of the origin ticket, just like test failure.
> 
> The extra method is so that we if we need to change the verification again. The method could be better named as `verifyOutput` or else to reveal the intention better.

If you want to keep it as is, so be it, but on the flip side, it really is not adding value currently and could just be as easily added at the point in time if/when more validation is required.

Again, just a passing observation for consideration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21697#discussion_r1817025896

From mcimadamore at openjdk.org  Fri Oct 25 16:44:05 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 16:44:05 GMT
Subject: RFR: 8342902: Deduplication of acquire calls in BindingSpecializer
 causes escape-analyisis failure
In-Reply-To: <EPbe4jYWRTNEeMR0eWn0O5TYDs8nYFCTo4a-k-1ONUM=.83fd2bad-c0cb-47c7-88b0-447103c0575a@github.com>
References: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
 <EPbe4jYWRTNEeMR0eWn0O5TYDs8nYFCTo4a-k-1ONUM=.83fd2bad-c0cb-47c7-88b0-447103c0575a@github.com>
Message-ID: <r-URhjk-HXJvDE4ceGaOavKP2XNfU4a08n6fZW8k_BY=.0460a388-f438-4fc7-a556-7c485e948229@github.com>

On Fri, 25 Oct 2024 15:02:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This PR fixes an issue where passing many by-reference parameters to downcall results in escape analysis failures.
>> The problem is that, as the parameters grow, the generated code in the trampoline stub we generate also grows.
>> When it reaches a certain threshold, it becomes too big, and it is no longer inlined in the caller.
>> When this happens, allocations for by-reference parameters (e.g. a segment constructed from `MemorySegment::ofAddress`) can no longer be eliminated.
>> 
>> The solution is two-fold. First, we annotate the generated trampoline with `@ForceInline`. After all, it is rather critical, to guarantee optimal performance, that this code can be always inlined.
>> Second, to keep the size of the generated code under control, we also put a limit on the max number of comparisons that are generated in order to "deduplicate" scope acquire/release calls.
>> The deduplication logic is a bit finicky -- it was put in place because, when confined and shared are passed by-ref, we need to prevent them from being closed in the middle of a native call.
>> So, we save all the seen scopes in a bunch of locals, and then we compare each new scope with _all_ the previous cached locals, and skip acquire if we can.
>> 
>> While this strategy work it does not scale when there are many by-ref parameters - as a by-ref parameter N will need N - 1 comparisons - which means a quadratic number of comparisons is generated.
>> This is fixed in this PR by putting a lid on the maximum number of comparisons that are generated. We also make the comparisons a bit smarter, by always skipping the very first by-ref argument -- the downcall address.
>> It is in fact very common for the downcall address to be in a different scope than that of the other by-ref arguments anyway.
>> 
>> A nice property of the new logic is that by configuring the max number of comparisons we can effectively select between different strategies:
>> * max = 0, means no dedup
>> * max = 1, means one-element cache
>> * max = N, means full dedup (like before)
>> 
>> Thanks to Ioannis (@spasi) for the report and the benchmark. I've beefed the benchmark up by adding a case for 10 arguments, and also adding support for critical downcalls, so we could also test passing by-ref heap segments. Benchmark result will be provided in a separate comment.
>
> test/micro/org/openjdk/bench/java/lang/foreign/libCallByRefHighArity.c line 33:
> 
>> 31: EXPORT void noop_params5(int param0, int param1, void *param2, void *param3, void *param4) {}
>> 32: EXPORT void noop_params10(int param0, int param1, void *param2, void *param3, void *param4,
>> 33:                           int param5, int param6, void *param7, void *param8, void *param9) {}
> 
> Some of these are `int` which mismatches the `ADDRESS` layout used to create the function descriptor.

ugh - true! Will replace with `void*`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21706#discussion_r1817027739

From mcimadamore at openjdk.org  Fri Oct 25 16:47:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Oct 2024 16:47:42 GMT
Subject: RFR: 8342902: Deduplication of acquire calls in BindingSpecializer
 causes escape-analyisis failure [v2]
In-Reply-To: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
References: <kuxbz-kTNWjpKc0Hs7fmVU77r0ZvFAL2s6nUeK1tQbw=.c43991f0-b9a5-42d3-b859-c9872c95bc62@github.com>
Message-ID: <j_9J7a21cKK_GfzeIORez5COi3vo_261eU4AAuoQw3s=.797a55b5-68a1-40d6-8b25-6d824fedd45d@github.com>

> This PR fixes an issue where passing many by-reference parameters to downcall results in escape analysis failures.
> The problem is that, as the parameters grow, the generated code in the trampoline stub we generate also grows.
> When it reaches a certain threshold, it becomes too big, and it is no longer inlined in the caller.
> When this happens, allocations for by-reference parameters (e.g. a segment constructed from `MemorySegment::ofAddress`) can no longer be eliminated.
> 
> The solution is two-fold. First, we annotate the generated trampoline with `@ForceInline`. After all, it is rather critical, to guarantee optimal performance, that this code can be always inlined.
> Second, to keep the size of the generated code under control, we also put a limit on the max number of comparisons that are generated in order to "deduplicate" scope acquire/release calls.
> The deduplication logic is a bit finicky -- it was put in place because, when confined and shared are passed by-ref, we need to prevent them from being closed in the middle of a native call.
> So, we save all the seen scopes in a bunch of locals, and then we compare each new scope with _all_ the previous cached locals, and skip acquire if we can.
> 
> While this strategy work it does not scale when there are many by-ref parameters - as a by-ref parameter N will need N - 1 comparisons - which means a quadratic number of comparisons is generated.
> This is fixed in this PR by putting a lid on the maximum number of comparisons that are generated. We also make the comparisons a bit smarter, by always skipping the very first by-ref argument -- the downcall address.
> It is in fact very common for the downcall address to be in a different scope than that of the other by-ref arguments anyway.
> 
> A nice property of the new logic is that by configuring the max number of comparisons we can effectively select between different strategies:
> * max = 0, means no dedup
> * max = 1, means one-element cache
> * max = N, means full dedup (like before)
> 
> Thanks to Ioannis (@spasi) for the report and the benchmark. I've beefed the benchmark up by adding a case for 10 arguments, and also adding support for critical downcalls, so we could also test passing by-ref heap segments. Benchmark result will be provided in a separate comment.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix issue with native benchmark lib

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21706/files
  - new: https://git.openjdk.org/jdk/pull/21706/files/e0371b27..72b22396

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21706&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21706&range=00-01

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21706/head:pull/21706

PR: https://git.openjdk.org/jdk/pull/21706

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>

On Thu, 24 Oct 2024 13:19: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 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

Changes requested by aivanov (Reviewer).

test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:

> 1: /*

I believe this test becomes irrelevant without `SecurityManager`.

The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:

> 1: /*

I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.

If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.

The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 44:

> 42:     private static JFrame frame;
> 43:     private static JPopupMenu popupMenu;
> 44:     private static volatile boolean isAlwaysOnTop1 = false;

Suggestion:

    private static volatile boolean isAlwaysOnTop = false;

There's only one flag now, it needs no modifier.

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 54:

> 52: 
> 53:             SwingUtilities.invokeAndWait(bug6691503::testApplication);
> 54:             robot.delay(200);

The additional delay is redundant.

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:

> 39:  * @bug 6694823
> 40:  * @summary Checks that popup menu cannot be partially hidden
> 41:  *          by the task bar.

I believe this test is irrelevant without the security manager.

The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.

Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.

We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:

> 1: /*

Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.

Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2395179909
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816616064
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816806950
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816827134
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816826424
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816840082
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816896526

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@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>
Message-ID: <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>

On Fri, 25 Oct 2024 15:12:00 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/javax/swing/UIDefaults/6622002/bug6622002.java line 1:
> 
>> 1: /*
> 
> Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.
> 
> Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.

This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.

Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.

However, a more thorough analysis is required.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816923550

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@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>
Message-ID: <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>

On Fri, 25 Oct 2024 15:29:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:
>> 
>>> 1: /*
>> 
>> Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.
>> 
>> Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.
>
> This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.
> 
> Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.
> 
> However, a more thorough analysis is required.

The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817034884

From bpb at openjdk.org  Fri Oct 25 17:04:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 17:04:22 GMT
Subject: RFR: 8341666: FileInputStream doesn't support readAllBytes() or
 readNBytes(int) on pseudo devices [v4]
In-Reply-To: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
References: <bTUxlxPLOV-fIjnATWu-xj0d2zMqJSyyVXLws1JQXes=.65b7d9a1-5f36-4565-ac25-5ae07916e02e@github.com>
Message-ID: <w6TN7dBkdbZxIBw4Bd5-_POOQXdMt9sVnolLsePLOs0=.6c5acc46-21f0-4cf6-a974-d76e29c0f982@github.com>

> Modify `FileInputStream` (FIS) to fall back to the superclass implementations of `readAllBytes()`, `readNBytes(int)`, `skip()`, and `transferTo` when the input source would otherwise fail with "Illegal Seek" in the FIS implementation, such as for the standard input or a named pipe.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8341666: Fix Windows oversight

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21673/files
  - new: https://git.openjdk.org/jdk/pull/21673/files/0bb34b4d..e091f157

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21673&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21673&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21673/head:pull/21673

PR: https://git.openjdk.org/jdk/pull/21673

From asemenyuk at openjdk.org  Fri Oct 25 17:18:11 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 25 Oct 2024 17:18:11 GMT
Subject: RFR: 8325089: jpackage utility creates an "infinite",
 undeleteable directory tree [v7]
In-Reply-To: <WkGJdVFU7U9hlqn_XUuwwDjnFUlmm7yJExWK2DjWnIw=.69e1bb23-1176-4250-b087-f99574539b5b@github.com>
References: <9-y-5qjhyLseg76Y6sQ0OPx0b-c3Q4Y_Y_vl4hjxwmQ=.ee394f8e-3256-45d5-8c0a-54f711700c07@github.com>
 <WkGJdVFU7U9hlqn_XUuwwDjnFUlmm7yJExWK2DjWnIw=.69e1bb23-1176-4250-b087-f99574539b5b@github.com>
Message-ID: <m12T5FfHIqGREYiAgEL7cEbBG-A6UtskAIpQgyrrRGE=.39e73b30-ef97-4977-ac55-07a098a3e8b4@github.com>

On Fri, 25 Oct 2024 15:06:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make jpackage correctly handle the output directory (`--dest`) that is:
>>  - a subdirectory of the input directory;
>>  - the same as the input directory.
>> 
>> Make jpackage correctly handle temp directory (`--temp`) that is:
>>  - a subdirectory of the input directory.
>> 
>> jpackage will produce an app image or a package in the above directory configurations without running in an infinite loop.
>> 
>> The new test/jdk/tools/jpackage/share/InOutPathTest.java test covers all the above scenarios.
>> 
>> `IOUtils.copyRecursive()` fixed to never run in a recursive loop by building the list of non-recursive file/dir copy commands and executing them outside the recursive directory tree traversal.
>> 
>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java, src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java, test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DeployParamsTest.java files fixed to get rid of `DeployParams.input` and `DeployParams.output` fields and replace them with the new `StandardBundlerParam.OUTPUT_DIR` param.
>> 
>> The above changes altered the logic of configuring the output directory, thus added a new `BasicTest.testNoOutputDir()` test to test jpackage without `--dest` parameter. This required adding new API to test helper classes.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   All new InOutPathTest test cases pass

Test updated. On Windows it will execute the following command lines:

jpackage.exe --input .\test.72d35365\input --dest .\test.72d35365\output --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello  --temp .\test.72d35365\input\tmp --app-content .\test.72d35365\input\tmp
jpackage.exe --input .\test.4a142b7a\input --dest .\test.4a142b7a\output --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello  --app-content .\test.4a142b7a\output\bar
jpackage.exe --input .\test.95a8ec80\input --dest .\test.95a8ec80\output --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello  --app-content .\test.95a8ec80\input\foo
jpackage.exe --input .\test.652154c7\input --dest .\test.652154c7\output --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello  --app-content .\test.652154c7\output
jpackage.exe --input .\test.dc40ecd3\input --dest .\test.dc40ecd3\output --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello  --app-content .\test.dc40ecd3\input
jpackage.exe --input .\test.b682c86a\input --dest .\test.b682c86a\output --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello  --app-content .\test.b682c86a\output\InOutPathTest
jpackage.exe --input .\test.1f844f72\input --dest .\test.1f844f72\input\out --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello  --temp .\test.1f844f72\input\tmp
jpackage.exe --input .\test.80984a5d\input --dest .\test.80984a5d\input\out --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello
jpackage.exe --input .\test.9a82b116\input --dest .\test.9a82b116\input --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello
jpackage.exe --input .\test.65e1cf6b\input --dest .\test.65e1cf6b\output --name InOutPathTest --type app-image --main-jar duke.jar --main-class Hello  --temp .\test.65e1cf6b\input\tmp
jpackage.exe --input .\test.3cbe2211\input --dest .\test.3cbe2211\output --name InOutPathTest --type exe --main-jar duke.jar --main-class Hello  --temp .\test.3cbe2211\input\tmp --app-content .\test.3cbe2211\input\tmp
jpackage.exe --input .\test.3cbe2211\input.0 --dest .\test.3cbe2211\output --name InOutPathTest --type msi --main-jar duke.jar --main-class Hello  --temp .\test.3cbe2211\input.0\tmp --app-content .\test.3cbe2211\input.0\tmp
jpackage.exe --input .\test.5be3e44e\input --dest .\test.5be3e44e\output --name InOutPathTest --type exe --main-jar duke.jar --main-class Hello  --app-content .\test.5be3e44e\output\bar
jpackage.exe --input .\test.5be3e44e\input.0 --dest .\test.5be3e44e\output --name InOutPathTest --type msi --main-jar duke.jar --main-class Hello  --app-content .\test.5be3e44e\output\bar
jpackage.exe --input .\test.bdd04e2c\input --dest .\test.bdd04e2c\output --name InOutPathTest --type exe --main-jar duke.jar --main-class Hello  --app-content .\test.bdd04e2c\input\foo
jpackage.exe --input .\test.bdd04e2c\input.0 --dest .\test.bdd04e2c\output --name InOutPathTest --type msi --main-jar duke.jar --main-class Hello  --app-content .\test.bdd04e2c\input.0\foo
jpackage.exe --input .\test.82280073\input --dest .\test.82280073\output --name InOutPathTest --type exe --main-jar duke.jar --main-class Hello  --app-content .\test.82280073\output
jpackage.exe --input .\test.82280073\input.0 --dest .\test.82280073\output --name InOutPathTest --type msi --main-jar duke.jar --main-class Hello  --app-content .\test.82280073\output
jpackage.exe --input .\test.600fb6a7\input --dest .\test.600fb6a7\output --name InOutPathTest --type exe --main-jar duke.jar --main-class Hello  --app-content .\test.600fb6a7\input
jpackage.exe --input .\test.600fb6a7\input.0 --dest .\test.600fb6a7\output --name InOutPathTest --type msi --main-jar duke.jar --main-class Hello  --app-content .\test.600fb6a7\input.0
jpackage.exe --input .\test.3c8afb1e\input --dest .\test.3c8afb1e\input\out --name InOu