Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2]

2024-07-14 Thread Uwe Schindler
On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote: >> This PR limits the number of cases in which we deoptimize frames when >> closing a shared Arena. The initial intent of this was to improve the >> performance of shared arena closure in cases where a lot of threads are >> accessing and clo

Re: RFR: 8335480: Only deoptimize threads if needed when closing shared arena [v2]

2024-07-14 Thread Uwe Schindler
On Sat, 13 Jul 2024 16:43:16 GMT, RĂ©mi Forax wrote: > Knowing that all the segments are freed during close() is something you may > want. But having the execution time of close() be linear with the number of > threads is also problematic. Maybe, it means that we need another kind of > Arena th

Re: RFR: 8315034 : File.mkdirs() occasionally fails to create folders on Windows shared folder

2024-07-14 Thread Jaikiran Pai
On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote: > File.mkdirs() occasionally fails to create folders on Windows shared folders. > It turned out that Windows API FindFirstFileW created the error > ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error > still returns

Re: RFR: 8335642: Hide Transform implementation for Class-File API [v3]

2024-07-14 Thread Chen Liang
> Removes ClassFile API transformation implementation details accidentally > leaked to public API. Users don't have access to classes necessary to > correctly implement these transform resolutions. In addition, removed > improper `canWriteDirect` and made `ClassFileBuilder::transform` chain > r

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v25]

2024-07-14 Thread fabioromano1
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the New

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v26]

2024-07-14 Thread fabioromano1
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the New

Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v27]

2024-07-14 Thread fabioromano1
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the New

Re: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided

2024-07-14 Thread Jaikiran Pai
On Tue, 2 Jul 2024 12:20:17 GMT, Yasumasa Suenaga wrote: > We cannot pass GNU style options like `--enable-preview` to `jlink > --add-option`. It is hard to use for complex application. > > We have workaround for this issue (see JBS), but I think it is better to fix > on JDK side. Hello @YaSu

Re: RFR: 8335642: Hide Transform implementation for Class-File API [v2]

2024-07-14 Thread Chen Liang
On Wed, 10 Jul 2024 07:30:36 GMT, Adam Sotona wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> return tag required > > Looks good to me. > Nice cleanup job! @asotona I have fixed the merge conflict (imports) and reru

Integrated: 8335905: CompoundElement API cleanup

2024-07-14 Thread Chen Liang
On Tue, 9 Jul 2024 21:42:46 GMT, Chen Liang wrote: > `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, > thus we can remove `Iterable elements()` and `forEachElements(Consumer)`. This pull request has now been integrated. Changeset: a9f5e76a Author:Chen Liang URL:

Re: RFR: 8335905: CompoundElement API cleanup [v2]

2024-07-14 Thread Chen Liang
On Tue, 9 Jul 2024 23:29:28 GMT, Chen Liang wrote: >> `CompoundElement` already inherits `Iterable` and its `forEach(Consumer)`, >> thus we can remove `Iterable elements()` and `forEachElements(Consumer)`. > > Chen Liang has updated the pull request incrementally with one additional > commit si

RFR: 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant

2024-07-14 Thread Chen Liang
Remove `AnnotationConstantValueEntry` and `AnnotationValue.OfConstant`. This is a relic of the old model from https://github.com/openjdk/jdk-sandbox/commit/bb7e29474ecfcfbd1eb01d237593eb80d062944f. In addition, this is bug-prone: the byte, short, char, and boolean constants use the int entry, a

RFR: 8335938: Review XxxBuilder.original and XxxModel.parent

2024-07-14 Thread Chen Liang
Remove unused `Class/Field/Method/CodeBuilder.original()`, and make `Field/Method/CodeModel.parent()` return present only if it's bound (i.e. not buffered transformed). See the CSR for details. - Commit messages: - 8335938: Review XxxBuilder.original and XxxModel.parent Changes: h

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-14 Thread Axel Boldt-Christmas
> When inflating a monitor the `ObjectMonitor*` is written directly over the > `markWord` and any overwritten data is displaced into a displaced `markWord`. > This is problematic for concurrent GCs which needs extra care or looser > semantics to use this displaced data. In Lilliput this data als

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v6]

2024-07-14 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 11:09:35 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/share/oops/instanceKlass.cpp line 1090: > >> 1088: >> 1089: // Step

RFR: 8335922: Incorrect stable usage of LambdaForm$Name.index

2024-07-14 Thread Chen Liang
The `@Stable` on the `index` field is incorrect, as stable only avoids inlining `0`. Solution is to use bit flip on the actual index (and rename the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0 the default value is used as an unset indicator. - Commit

Re: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v20]

2024-07-14 Thread lingjun-cg
> ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic > instructions. But when run with JDK 11, there is no such problem. The reason > is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and St

Re: RFR: 8333396: Use StringBuilder internally for java.text.Format.* formatting [v21]

2024-07-14 Thread lingjun-cg
> ### Performance regression of DecimalFormat.format > From the output of perf, we can see the hottest regions contain atomic > instructions. But when run with JDK 11, there is no such problem. The reason > is the removed biased locking. > The DecimalFormat uses StringBuffer everywhere, and St

Re: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12]

2024-07-14 Thread Jan Kratochvil
On Thu, 11 Jul 2024 10:39:23 GMT, Severin Gehwolf wrote: >> Jan Kratochvil has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 103 commits: >> >> - Fix the gtest >> - fix compilation warning >> - fix the gtest >> - less refactoriz

Re: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12]

2024-07-14 Thread Jan Kratochvil
On Thu, 11 Jul 2024 12:47:38 GMT, Severin Gehwolf wrote: >> Jan Kratochvil has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 103 commits: >> >> - Fix the gtest >> - fix compilation warning >> - fix the gtest >> - less refactoriz

Re: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12]

2024-07-14 Thread Jan Kratochvil
On Thu, 11 Jul 2024 12:49:24 GMT, Severin Gehwolf wrote: >> Jan Kratochvil has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 103 commits: >> >> - Fix the gtest >> - fix compilation warning >> - fix the gtest >> - less refactoriz

RFR: 8336267: Method and Constructor signature parsing can be shared on the root object

2024-07-14 Thread Chen Liang
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. - Commit messages: - 8336267: Method and Constructor signature parsing can be shared on the root o

Re: RFR: 8303884: jlink --add-options plugin does not allow GNU style options to be provided

2024-07-14 Thread Yasumasa Suenaga
On Sun, 14 Jul 2024 14:38:39 GMT, Jaikiran Pai wrote: > Hello @YaSuenag, I haven't had a chance to build your change locally and try > it myself, but I suspect this change isn't enough to address the issue. Does > this change allow for: > > ``` > jlink ... --add-options --add-exports java.base

Integrated: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero

2024-07-14 Thread Adam Sotona
On Mon, 8 Jul 2024 13:09:50 GMT, Adam Sotona wrote: > Class-File API constant pool implementation requires non-zero entry hash code. > Unfortunately current implementation computes zero hash code for specific CP > entries. > > This patch removes invalid and obsolete `AbstractPoolEntry::phiMix`

Re: RFR: 8335642: Hide Transform implementation for Class-File API [v3]

2024-07-14 Thread Adam Sotona
On Sun, 14 Jul 2024 13:49:09 GMT, Chen Liang wrote: >> Removes ClassFile API transformation implementation details accidentally >> leaked to public API. Users don't have access to classes necessary to >> correctly implement these transform resolutions. In addition, removed >> improper `canWrit

Re: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v12]

2024-07-14 Thread Jan Kratochvil
On Thu, 11 Jul 2024 06:54:27 GMT, Jan Kratochvil wrote: >> The testcase requires root permissions. >> >> Fix by Severin Gehwolf. >> Testcase by Jan Kratochvil. > > Jan Kratochvil has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 10

Re: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control groups are not detected [v13]

2024-07-14 Thread Jan Kratochvil
> The testcase requires root permissions. > > Fix by Severin Gehwolf. > Testcase by Jan Kratochvil. Jan Kratochvil has updated the pull request incrementally with 10 additional commits since the last revision: - Merge branch 'master-jdk-8322420_cgroup_hierarchy_walk_init-test' into master-cg

[jdk23] RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero

2024-07-14 Thread Adam Sotona
8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero - Commit messages: - Backport 3f2636d9b71f5270c83d17dcf5d18cf907978475 Changes: https://git.openjdk.org/jdk/pull/20180/files Webrev: https://webrevs.open