Re: RFR: 8336254: Virtual thread implementation + test updates

2024-07-15 Thread David Holmes
On Thu, 11 Jul 2024 17:30:21 GMT, Alan Bateman wrote: > Bringover some of the changes accumulated in the loom repo to the main line, > most of these changes are test updates and have been baking in the loom repo > for several months. The motive is partly to reduce the large set of changes > th

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

2024-07-15 Thread fabioromano1
On Mon, 15 Jul 2024 19:58:23 GMT, fabioromano1 wrote: >> 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

RFR: 8336275: Move common Method and Constructor fields to Executable

2024-07-15 Thread Chen Liang
Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable. - Commit messages: - Inline some common ctor + method fields to executable Changes: https://git.openjdk.org/jdk/p

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v4]

2024-07-15 Thread Chen Liang
On Tue, 16 Jul 2024 00:39:19 GMT, ExE Boss wrote: >> Chen Liang has updated the pull request incrementally with four additional >> commits since the last revision: >> >> - Make LambdaForm.Name index final >> - Revert "8335922: Incorrect stable usage of LambdaForm$Name.index" >> >>This

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v5]

2024-07-15 Thread Chen Liang
> The `@Stable` on the `index` field is incorrect, as stable only avoids > inlining `0`. On a strategic view, this index field should just become final > so that `Name` becomes eligible for value class migration once valhalla > comes. This patch makes the `index` field final and updates the usag

Re: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2]

2024-07-15 Thread SendaoYan
On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` >> doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> Fix solution similar to >> [JDK-8157850](https://

Integrated: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts

2024-07-15 Thread SendaoYan
On Wed, 12 Jun 2024 02:00:41 GMT, SendaoYan wrote: > Hi all, > Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` > doesn't receive jvm options from jtreg. > I think it's necessory to receive jvm options from jtreg. > Fix solution similar to > [JDK-8157850](https://bugs.o

Re: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2]

2024-07-15 Thread SendaoYan
On Mon, 15 Jul 2024 16:02:49 GMT, Jaikiran Pai wrote: > > Does this PR need 2rd reviewer. > > core-libs area doesn't mandate 2 reviews. The current PR is a test > infrastructure change and doesn't impact the functionality of the test. The > change has been tested in our CI and appears to work

Re: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2]

2024-07-15 Thread duke
On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` >> doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> Fix solution similar to >> [JDK-8157850](https://

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v4]

2024-07-15 Thread ExE Boss
On Mon, 15 Jul 2024 22:56:23 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids >> inlining `0`. On a strategic view, this index field should just become final >> so that `Name` becomes eligible for value class migration once valhalla >> comes. Thi

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3]

2024-07-15 Thread Chen Liang
On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote: >> The `@Stable` on the `index` field is incorrect, as stable only avoids >> inlining `0`. On a strategic view, this index field should just become final >> so that `Name` becomes eligible for value class migration once valhalla >> comes. Thi

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v4]

2024-07-15 Thread Chen Liang
> The `@Stable` on the `index` field is incorrect, as stable only avoids > inlining `0`. On a strategic view, this index field should just become final > so that `Name` becomes eligible for value class migration once valhalla > comes. This patch makes the `index` field final and updates the usag

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

2024-07-15 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

[jdk23] Integrated: 8334653: ISO 4217 Amendment 177 Update

2024-07-15 Thread Justin Lu
On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu wrote: > Please review this PR, which is a backport of commit > [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91) > from the [openjdk/jdk](https://git.openjdk.org/jdk) mainline branch. > > This change incorpor

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5]

2024-07-15 Thread Archie Cobbs
On Mon, 15 Jul 2024 13:12:41 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 153: >> >>> 151: */ >>> 152: public GZIPInputStream(InputStream in, int size, >>> 153: boolean allowConcatenation, boolean ignoreExtraBytes) >>> thro

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 17:00:24 GMT, Rémi Forax wrote: > Even if the int vs long issue is fixed for this case, i think we should > recommand to call `withInvokeExactBehavior()` after creating any VarHandle so > all the auto-conversions are treated as runtime errors. > > This is what i do with my

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

2024-07-15 Thread Rémi Forax
On Mon, 15 Jul 2024 11:33:30 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 [v3]

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 16:40:06 GMT, Maurizio Cimadamore wrote: > > So +1 to merge this and hopefully backport it at least to 21? > > Backport to 21 is difficult, given the handshake code there is different > (and, FFM is preview there). But, might be more possible for 22. I have > notified Rola

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 16:35:26 GMT, Uwe Schindler wrote: > So +1 to merge this and hopefully backport it at least to 21? Backport to 21 is difficult, given the handshake code there is different (and, FFM is preview there). But, might be more possible for 22. I have notified Roland re. the `int`

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3]

2024-07-15 Thread Chen Liang
On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote: >> 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 de

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

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 16:30:11 GMT, Maurizio Cimadamore wrote: >>> > > Even with `arrayElementVarHandle` it's about the same >>> > >>> > >>> > This is very odd, and I don't have a good explanation as to why that is >>> > the case. What does the baseline (confined arena) look like for >>> > `ar

Re: RFR: 8336289: Obliterate most references to _snprintf in the Windows JDK [v2]

2024-07-15 Thread Kim Barrett
On Sat, 13 Jul 2024 05:34:24 GMT, Julian Waters wrote: >> snprintf has been available for all officially and unofficially supported >> compilers for Windows, Visual Studio since version 2015 and gcc since, well, >> forever. snprintf is conforming to C99 since the start when compiling using >>

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

2024-07-15 Thread Alan Bateman
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. JDK-8303884 was created to track a much larger re-examination of the jlink option parameter. I think the issue w

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 14:02:27 GMT, Maurizio Cimadamore wrote: > So, that means that `arrayElementVarHandle` is ~4x faster than memory > segment? Isn't that a bit odd? I did some more analyis of the benchmark. I first eliminated the closing thread, and started with two simple benchmarks: @Ben

RFR: 8336254: Virtual thread implementation + test updates

2024-07-15 Thread Alan Bateman
Bringover some of the changes accumulated in the loom repo to the main line, most of these changes are test updates and have been baking in the loom repo for several months. The motive is partly to reduce the large set of changes that have accumulated in the loom repo, and partly to improve robu

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3]

2024-07-15 Thread Jorn Vernee
On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote: >> 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 de

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3]

2024-07-15 Thread Aleksey Shipilev
On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote: >> 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 de

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2]

2024-07-15 Thread Aleksey Shipilev
On Mon, 15 Jul 2024 15:47:50 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 778: >> >>> 776: var newParameters = new TreeMap(new >>> Comparator<>() { >>> 777: public int compare(Name n1, Name n2) { >>> 778: r

Re: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2]

2024-07-15 Thread Jaikiran Pai
On Mon, 15 Jul 2024 15:29:03 GMT, SendaoYan wrote: > Does this PR need 2rd reviewer. core-libs area doesn't mandate 2 reviews. The current PR is a test infrastructure change and doesn't impact the functionality of the test. The change has been tested in our CI and appears to work fine without

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v3]

2024-07-15 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. Chen Liang has

Re: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts

2024-07-15 Thread SendaoYan
On Fri, 12 Jul 2024 07:04:33 GMT, Jaikiran Pai wrote: > What you propose in this PR looks fine to me and matches some other tests > which do a similar thing. Maybe we should do the same thing in some other > tests in this directory, to keep them consistent. For now though, I think > what you h

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2]

2024-07-15 Thread Chen Liang
On Mon, 15 Jul 2024 14:29:29 GMT, Aleksey Shipilev wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> We have sufficient space in short, use +1 offset > > src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.ja

[jdk23] Integrated: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation

2024-07-15 Thread Chen Liang
On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and > erroneous links in the doc files. This pull request has now been integrated. Changeset: 908d1e92 Author:Chen Liang URL: https://git.openjdk.org/jdk/comm

Re: [jdk23] RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation

2024-07-15 Thread Pavel Rappo
On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and > erroneous links in the doc files. Marked as reviewed by prappo (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20166#pullrequestreview-217806

Re: [jdk23] RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation

2024-07-15 Thread Chen Liang
On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and > erroneous links in the doc files. Thanks for the reviews! - PR Comment: https://git.openjdk.org/jdk/pull/20166#issuecomment-2228806864

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2]

2024-07-15 Thread Aleksey Shipilev
On Mon, 15 Jul 2024 14:09:22 GMT, Chen Liang wrote: >> 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 de

Re: RFR: 8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts [v2]

2024-07-15 Thread SendaoYan
On Fri, 12 Jul 2024 07:39:11 GMT, SendaoYan wrote: >> Hi all, >> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java` >> doesn't receive jvm options from jtreg. >> I think it's necessory to receive jvm options from jtreg. >> Fix solution similar to >> [JDK-8157850](https://

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

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 15:18:20 GMT, Jorn Vernee wrote: > > > This is what I was thinking of as well. close() on a shared arena can be > > > called by any thread, so it would be possible to have an executor service > > > with 1-n threads that is dedicated to closing memory. > > > > > > This dela

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

2024-07-15 Thread Jorn Vernee
On Mon, 15 Jul 2024 11:29:49 GMT, Rémi Forax wrote: > > This is what I was thinking of as well. close() on a shared arena can be > > called by any thread, so it would be possible to have an executor service > > with 1-n threads that is dedicated to closing memory. > > This delays both the clos

Re: RFR: 8335938: Review XxxBuilder.original and XxxModel.parent [v2]

2024-07-15 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. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The

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

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 11:33:30 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: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2]

2024-07-15 Thread Chen Liang
On Mon, 15 Jul 2024 14:09:22 GMT, Chen Liang wrote: >> 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 de

Re: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]

2024-07-15 Thread jengebr
On Wed, 19 Jun 2024 12:52:46 GMT, Alan Bateman wrote: >> @AlanBateman -- could you please take a look? Thanks. > >> @AlanBateman -- could you please take a look? Thanks. > > There was a lot of heap analysis done a few years ago that shined a light on > the number of empty collections in a typic

Re: RFR: 8173970: jar tool should have a way to extract to a directory [v8]

2024-07-15 Thread Jaikiran Pai
> 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? > > The commit in this PR introduces the `-o` and `--output-dir` option to the > `jar` command. The option takes a path to a destination dir

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index [v2]

2024-07-15 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. Chen Liang has

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 13:49:57 GMT, Jorn Vernee wrote: > > > Even with `arrayElementVarHandle` it's about the same > > > > > > This is very odd, and I don't have a good explanation as to why that is the > > case. What does the baseline (confined arena) look like for > > `arrayElementVarHandle`

Re: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v4]

2024-07-15 Thread Aleksey Shipilev
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote: >> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless >> cloning of Object[0] instances. This cloning is intended to prevent callers >> from changing array contents, but many `CopyOnWriteArrayList`s are allocated >> to s

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

2024-07-15 Thread Jorn Vernee
On Mon, 15 Jul 2024 13:09:21 GMT, Maurizio Cimadamore wrote: > > Even with `arrayElementVarHandle` it's about the same > > This is very odd, and I don't have a good explanation as to why that is the > case. What does the baseline (confined arena) look like for > `arrayElementVarHandle` ? Pre

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index

2024-07-15 Thread Aleksey Shipilev
On Mon, 15 Jul 2024 12:28:51 GMT, Chen Liang wrote: > Indeed, for some reason I thought the range of short is -256 to 255 instead > of -65536 to 65535 Yeah, I thought something like this was going on; it would be a smart way to leverage that negative side in two-complement form is one value la

Re: RFR: 8334714: Class-File API leaves preview

2024-07-15 Thread ExE Boss
On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona 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. >

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8]

2024-07-15 Thread Maurizio Cimadamore
On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting >> the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loa

Re: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v9]

2024-07-15 Thread Maurizio Cimadamore
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting > the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` metho

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5]

2024-07-15 Thread Jaikiran Pai
On Mon, 15 Jul 2024 10:06:20 GMT, Jaikiran Pai wrote: >> Archie Cobbs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 12 commits: >> >> - Bump @since from 23 to 24. >> - Merge branch 'master' into JDK-8322256 >> - Relabel "trai

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 12:47:30 GMT, Jorn Vernee wrote: > Even with `arrayElementVarHandle` it's about the same This is very odd, and I don't have a good explanation as to why that is the case. What does the baseline (confined arena) look like for `arrayElementVarHandle` ? - PR Comm

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 12:34:37 GMT, Jorn Vernee wrote: > This is the baseline if I change `closing` to use a confined arena: > > ``` > BenchmarkMode Cnt ScoreError > Units > ConcurrentClose.sharedClose avgt 10 8.089 ± 0.006

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

2024-07-15 Thread Jorn Vernee
On Mon, 15 Jul 2024 12:14:52 GMT, Maurizio Cimadamore wrote: > Ah! I had `arrayElementVarHandle` in mind - maybe you can try that? Even with `arrayElementVarHandle` it's about the same - PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228425705

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

2024-07-15 Thread Jorn Vernee
On Mon, 15 Jul 2024 11:33:30 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: 8335922: Incorrect @Stable usage of LambdaForm$Name.index

2024-07-15 Thread Chen Liang
On Mon, 15 Jul 2024 01:45:57 GMT, Chen Liang wrote: > 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 defaul

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 12:13:23 GMT, Maurizio Cimadamore wrote: > > I also tried using `MethodHandles::arrayElementGetter` for the access, but > > the numbers I got were pretty much the same: > > This is quite strange, as the code involved should be quite similar to those > with memory segments

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 12:10:02 GMT, Maurizio Cimadamore wrote: > I also tried using `MethodHandles::arrayElementGetter` for the access, but > the numbers I got were pretty much the same: This is quite strange, as the code involved should be quite similar to those with memory segments (e.g. you

Integrated: 8335642: Hide Transform implementation for Class-File API

2024-07-15 Thread Chen Liang
On Tue, 9 Jul 2024 18:47:35 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 `canWriteDire

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

2024-07-15 Thread Chen Liang
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: 8335480: Only deoptimize threads if needed when closing shared arena [v3]

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 12:00:31 GMT, Maurizio Cimadamore wrote: > When I remove the `has_scoped_access()` check before the deopt, I expect the > `otherAccess` thread to be affected, but the effect isn't nearly as big as > with the FFM thread. I think this is likely due to the `otherAccess` > ben

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 11:47:43 GMT, Jorn Vernee wrote: > I've update the benchmark to run with 3 separate threads: 1 thread that is > just creating and closing shared arenas in a loop, 1 that is accessing memory > using the FFM API, and 1 that is accessing a `byte[]`. > > Current: > > ``` > Ben

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

2024-07-15 Thread Jorn Vernee
On Mon, 15 Jul 2024 11:33:30 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-15 Thread Rémi Forax
On Mon, 15 Jul 2024 10:50:34 GMT, Jorn Vernee wrote: > This is what I was thinking of as well. close() on a shared arena can be > called by any thread, so it would be possible to have an executor service > with 1-n threads that is dedicated to closing memory. This delays both the closing of th

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

2024-07-15 Thread Jorn Vernee
> 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 > closing shared arenas at the same time (see attached benchmark

Re: RFR: 8335922: Incorrect @Stable usage of LambdaForm$Name.index

2024-07-15 Thread Aleksey Shipilev
On Mon, 15 Jul 2024 01:45:57 GMT, Chen Liang wrote: > 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 defaul

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

2024-07-15 Thread Jorn Vernee
On Mon, 15 Jul 2024 09:02:29 GMT, Uwe Schindler wrote: > Of course we can do that in a separate thread (this is my idea how to improve > the closes in lucene). This is what I was thinking of as well. `close()` on a shared arena can be called by any thread, so it would be possible to have an ex

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

2024-07-15 Thread Jorn Vernee
On Mon, 15 Jul 2024 08:41:38 GMT, Doug Simon wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> track has_scoped_access for compiled methods > > src/hotspot/share/jvmci/jvmciRuntime.cpp line 2186: > >> 2184: n

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5]

2024-07-15 Thread Jaikiran Pai
On Thu, 6 Jun 2024 17:03:57 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data >> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In >> order to do this, after a GZIP trailer frame is read, it attempts to read a >>

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5]

2024-07-15 Thread Jaikiran Pai
On Thu, 6 Jun 2024 17:03:57 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data >> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In >> order to do this, after a GZIP trailer frame is read, it attempts to read a >>

Re: RFR: 8225763: Inflater and Deflater should implement AutoCloseable [v3]

2024-07-15 Thread Jaikiran Pai
On Sun, 16 Jun 2024 06:36:00 GMT, Jaikiran Pai wrote: >> Can I please get a review of this enhancement which proposes to enhance >> `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`? >> >> The actual work for this was done a few years back when we discussed the >> prop

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

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 09:17:31 GMT, Maurizio Cimadamore wrote: >>> One only closing arenas, another set that consumes scoped memory and a >>> third group doing totally unrelated stuff. >> >> Exactly. My general feeling is that the cost of handshaking a thread >> dominates everything else, so do

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 09:11:53 GMT, Maurizio Cimadamore wrote: > avoiding unnecessary deoptimization (as in this PR) is not going to help much, What would definitively help is to somehow reduce the number of threads to handshake when calling close - e.g. have an arena that is shared but only to

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

2024-07-15 Thread Maurizio Cimadamore
On Mon, 15 Jul 2024 09:02:29 GMT, Uwe Schindler wrote: > One only closing arenas, another set that consumes scoped memory and a third > group doing totally unrelated stuff. Exactly. My general feeling is that the cost of handshaking a thread dominates everything else, so doing improvements aro

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

2024-07-15 Thread Adam Sotona
On Mon, 15 Jul 2024 05:53:12 GMT, Adam Sotona wrote: > 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due > to IllegalArgumentException: hash must be nonzero This pull request has now been integrated. Changeset: 52cd9bb5 Author:Adam Sotona URL: https://git

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

2024-07-15 Thread Adam Sotona
On Mon, 15 Jul 2024 05:53:12 GMT, Adam Sotona wrote: > 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due > to IllegalArgumentException: hash must be nonzero Thank you. - PR Comment: https://git.openjdk.org/jdk/pull/20180#issuecomment-2228021104

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

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 08:54:11 GMT, Maurizio Cimadamore wrote: > > I have one problem with the benchmark: I think it is not measuring the > > whole setup in a way that is our workload: The basic problem is that we > > don't want to deoptimize threads which are not related to MemorySegments. > >

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

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 08:57:08 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> track has_scoped_access for compiled methods > > test/micro/org/openjdk/bench/java/lang/foreign/ConcurrentClose.

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

2024-07-15 Thread Maurizio Cimadamore
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-15 Thread Maurizio Cimadamore
On Sun, 14 Jul 2024 11:01:58 GMT, Uwe Schindler wrote: > I have one problem with the benchmark: I think it is not measuring the whole > setup in a way that is our workload: The basic problem is that we don't want > to deoptimize threads which are not related to MemorySegments. So basically, >

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

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 08:41:01 GMT, Alan Bateman wrote: >> This is the whole magic around the shared arena. It is not public API and >> internal to Hotspot/VM: >> - >> https://github.com/openjdk/jdk/blob/a96de6d8d273d75a6500e10ed06faab9955f893b/src/java.base/share/classes/jdk/internal/misc/X-Scop

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

2024-07-15 Thread Alan Bateman
On Mon, 15 Jul 2024 08:38:59 GMT, Uwe Schindler wrote: >> src/hotspot/share/prims/scopedMemoryAccess.cpp line 179: >> >>> 177: // >>> 178: // The safepoint at which we're stopped may be in between the >>> liveness check >>> 179: // and actual memory access, but is itself

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

2024-07-15 Thread Uwe Schindler
On Mon, 15 Jul 2024 08:28:16 GMT, Doug Simon wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> track has_scoped_access for compiled methods > > src/hotspot/share/prims/scopedMemoryAccess.cpp line 179: > >> 177:

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

2024-07-15 Thread Doug Simon
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-15 Thread Doug Simon
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: [jdk23] RFR: 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero

2024-07-15 Thread Jaikiran Pai
On Mon, 15 Jul 2024 05:53:12 GMT, Adam Sotona wrote: > 8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due > to IllegalArgumentException: hash must be nonzero This is a clean backport of a P3 bug. Looks good to me for JDK 23. - Marked as reviewed by jpai (

Re: RFR: 8333768: Minor doc updates to java.lang.{Float, Double} [v5]

2024-07-15 Thread Raffaello Giulietti
On Sat, 13 Jul 2024 22:44:31 GMT, Joe Darcy wrote: >> Misc small doc updates and addition of `@Overrides` annotations. > > 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/

Re: [jdk23] RFR: 8336259: Wrong link to stylesheet.css in JavaDoc API documentation

2024-07-15 Thread Iris Clark
On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote: > Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and > erroneous links in the doc files. Confirmed identical to original PR. - Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/

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

2024-07-15 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 one additional commit since the last revision: Fix a needless whitespace change - Changes: - all: https://git.ope

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

2024-07-15 Thread Jan Kratochvil
On Mon, 15 Jul 2024 05:56:12 GMT, Jan Kratochvil wrote: >> 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 bra