Re: RFR: 8283426: Fix 'exeption' typo [v2]

2022-03-21 Thread Alexey Ivanov
On Mon, 21 Mar 2022 09:02:17 GMT, Andrey Turbanov wrote: >> Fix repeated typo `exeption` > > Andrey Turbanov has updated the pull request incrementally with one > additional commit since the last revision: > > 8283426: Fix 'exeption' typo > > Apply suggestion > > Co-authored-by:

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port

2022-03-21 Thread Magnus Ihse Bursie
On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the > https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive > Unmatched board.

Re: RFR: 8257733: Move module-specific data from make to respective module [v10]

2022-03-21 Thread Magnus Ihse Bursie
> A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually* used by > make for the whole build.) > > These data files should move

Re: RFR: 8257733: Move module-specific data from make to respective module [v11]

2022-03-21 Thread Magnus Ihse Bursie
> A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually* used by > make for the whole build.) > > These data files should move

Integrated: 8283277: ISO 4217 Amendment 171 Update

2022-03-21 Thread Naoto Sato
On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE > redenomination (removing 3 zeros). Its effective date is 4/1, but I went > ahead as JDK19 won't be released by 4/1. This pull request has now been integrated.

Re: RFR: JDK-8283415: Update java.lang.ref to use sealed classes [v2]

2022-03-21 Thread Joe Darcy
> Another refactoring to use sealed classes where possible, this time in the > java.lang.ref package. > > Copyright dates will be updated, if needed, before a push. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the

Re: RFR: 8257733: Move module-specific data from make to respective module [v12]

2022-03-21 Thread Magnus Ihse Bursie
> A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually* used by > make for the whole build.) > > These data files should move

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

2022-03-21 Thread Magnus Ihse Bursie
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix typos > > This doesn't seem right to me to put x11wrappergen into share. > > This is X11 specific. It should

Re: RFR: JDK-8282798 java.lang.runtime.Carrier [v11]

2022-03-21 Thread Jim Laskey
> We propose to provide a runtime anonymous carrier class object generator; > java.lang.runtime.Carrier. This generator class is designed to share > anonymous classes when shapes are similar. For example, if several clients > require objects containing two integer fields, then Carrier will

Re: RFR: JDK-8282798 java.lang.runtime.Carrier [v10]

2022-03-21 Thread Jim Laskey
On Mon, 21 Mar 2022 07:29:21 GMT, ExE Boss wrote: >> The package is java.lang.runtime not java.lang.invoke so both fields are not >> accessible. > > Well, you could use `SharedSecrets.getJavaLangInvokeAccess().findStatic(…)` > and `SharedSecrets.getJavaLangInvokeAccess().findVirtual(…)` in 

Re: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize

2022-03-21 Thread Severin Gehwolf
On Thu, 17 Mar 2022 13:40:53 GMT, Severin Gehwolf wrote: > Please review this container test improvement. The test in question only > makes sense iff the total swap space size as reported by the container aware > OperatingSystemMXBean is `0`. If that's not the case, then something else >

Integrated: JDK-8283415: Update java.lang.ref to use sealed classes

2022-03-21 Thread Joe Darcy
On Sat, 19 Mar 2022 22:30:13 GMT, Joe Darcy wrote: > Another refactoring to use sealed classes where possible, this time in the > java.lang.ref package. > > Copyright dates will be updated, if needed, before a push. This pull request has now been integrated. Changeset: 14b9e80b Author:

Re: RFR: 8257733: Move module-specific data from make to respective module [v13]

2022-03-21 Thread Erik Joelsson
On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8279508: Auto-vectorize Math.round API [v15]

2022-03-21 Thread Jatin Bhateja
On Mon, 21 Mar 2022 17:56:22 GMT, Quan Anh Mai wrote: >> constant and register to register moves are never issued to execution ports, >> rematerializing value rather than reading from memory will give better >> performance. > > I have come across this a little bit. While `movl r, i` may not

Re: Unused paramter 'boolean newln' in java.lang.VersionProps#print(boolean err, boolean newln)

2022-03-21 Thread Mandy Chung
VersionProps::print(boolean err, boolean newln) is called by VersionProps::println(boolean) and VersionProps::print(boolean) which is called from the launcher java -version and -showversion option [1]. Mandy [1]

Integrated: 8257733: Move module-specific data from make to respective module

2022-03-21 Thread Magnus Ihse Bursie
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote: > A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually* used by >

Re: RFR: JDK-8282798 java.lang.runtime.Carrier [v11]

2022-03-21 Thread John Rose
On 21 Mar 2022, at 11:05, ExE Boss wrote: > Actually, this lookup object should probably be kept cached. +1. Good “cache”.

RFR: JDK-8283480: Make AbstractStringBuilder sealed

2022-03-21 Thread Joe Darcy
As part of updating the core libraries to be sealed, the package-access AbstractStringBuilder, implementation superclass of StringBuilder and StringBuffer, can be marked as sealed with those two subclasses on its permits list. - Commit messages: - Merge branch 'master' into

Re: RFR: JDK-8283480: Make AbstractStringBuilder sealed

2022-03-21 Thread Jonathan Gibbons
On Tue, 22 Mar 2022 00:01:59 GMT, Joe Darcy wrote: > As part of updating the core libraries to be sealed, the package-access > AbstractStringBuilder, implementation superclass of StringBuilder and > StringBuffer, can be marked as sealed with those two subclasses on its > permits list. Marked

Re: RFR: JDK-8283480: Make AbstractStringBuilder sealed

2022-03-21 Thread Roger Riggs
On Tue, 22 Mar 2022 00:01:59 GMT, Joe Darcy wrote: > As part of updating the core libraries to be sealed, the package-access > AbstractStringBuilder, implementation superclass of StringBuilder and > StringBuffer, can be marked as sealed with those two subclasses on its > permits list. Marked

Re: RFR: JDK-8283480: Make AbstractStringBuilder sealed

2022-03-21 Thread Jim Laskey
On Tue, 22 Mar 2022 00:01:59 GMT, Joe Darcy wrote: > As part of updating the core libraries to be sealed, the package-access > AbstractStringBuilder, implementation superclass of StringBuilder and > StringBuffer, can be marked as sealed with those two subclasses on its > permits list. LGTM

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Maurizio Cimadamore
On Mon, 21 Mar 2022 14:17:21 GMT, Jorn Vernee wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8257733: Move module-specific data from make to respective module [v14]

2022-03-21 Thread Magnus Ihse Bursie
> A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually* used by > make for the whole build.) > > These data files should move

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Maurizio Cimadamore
On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] -

RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Maurizio Cimadamore
This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. [1] - https://openjdk.java.net/jeps/424 - Commit messages: - Fix TestLayouts on

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Julia Boes
On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] -

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Erik Joelsson
On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] -

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Jorn Vernee
On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] -

Re: RFR: 8257733: Move module-specific data from make to respective module [v9]

2022-03-21 Thread Phil Race
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix typos > > This doesn't seem right to me to put x11wrappergen into share. > > This is X11 specific. It should

Re: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..)

2022-03-21 Thread Lance Andersen
Hi Volker, I have read through what you have provided/pointed to, thank you, and on the surface what you are suggesting sounds reasonable. That being said given that this API dates back to 1997ish, I think we have to be careful not introduce any regressions with existing applications with the

Re: RFR: 8257733: Move module-specific data from make to respective module [v13]

2022-03-21 Thread Magnus Ihse Bursie
> A lot (but not all) of the data in make/data is tied to a specific module. > For instance, the publicsuffixlist is used by java.base, and fontconfig by > java.desktop. (A few directories, like mainmanifest, is *actually* used by > make for the whole build.) > > These data files should move

Re: RFR: 8257733: Move module-specific data from make to respective module [v13]

2022-03-21 Thread Mandy Chung
On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFR: 8279508: Auto-vectorize Math.round API [v15]

2022-03-21 Thread Quan Anh Mai
On Sun, 13 Mar 2022 04:27:44 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4178: >> >>> 4176: movl(scratch, 1056964608); >>> 4177: movq(xtmp1, scratch); >>> 4178: vbroadcastss(xtmp1, xtmp1, vec_enc); >> >> You could put the constant in the constant table

Re: RFR: JDK-8282798 java.lang.runtime.Carrier [v11]

2022-03-21 Thread ExE Boss
On Mon, 21 Mar 2022 14:24:30 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; >> java.lang.runtime.Carrier. This generator class is designed to share >> anonymous classes when shapes are similar. For example, if several clients >> require

Re: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes

2022-03-21 Thread Mandy Chung
On Mon, 21 Mar 2022 06:08:32 GMT, Athijegannathan Sundararajan wrote: > $ javac com/acme/*.java > > is fine. Am I missing something? If you make P.Q private, it will fail the compilation. To make `DelegatingMethodHandle` a sealed class, we could make `AsVarargsCollector` and `WrappedMember`

Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview)

2022-03-21 Thread Maurizio Cimadamore
On Mon, 21 Mar 2022 17:16:49 GMT, Erik Joelsson wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8257733: Move module-specific data from make to respective module [v13]

2022-03-21 Thread Jonathan Gibbons
On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by

Re: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..)

2022-03-21 Thread Alan Bateman
On 04/03/2022 10:04, Volker Simonis wrote: : 1. Relax the specification of `InflaterInputStream::read(..)` and specifically note in the API documentation that a call to `InflaterInputStream::read(byte[] b, int off, int len)` may write more than *k* characters into `b` where *k* is the returned

Re: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes [v2]

2022-03-21 Thread Jaikiran Pai
On Sun, 20 Mar 2022 14:01:50 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 206: >> >>> 204: int max = (int)Math.min(n, Integer.MAX_VALUE); >>> 205: int total = 0; >>> 206: byte[] b = new byte[512]; >> >> n may be

Re: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable

2022-03-21 Thread ExE Boss
On Mon, 21 Feb 2022 12:16:53 GMT, Andrey Turbanov wrote: > Method `isAssignableFrom` is opposite: it brings unnecessary complexity in > the code. And it's easy to confuse orders of parameters. Even JBS confirms > that: Maybe we should add `Class::isSubclassOf(Class that)` that performs

Re: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3]

2022-03-21 Thread Xin Liu
On Wed, 9 Mar 2022 08:33:36 GMT, Xin Liu wrote: >> If AbstractStringBuilder only grow, the inflated value which has been >> encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an >> ArrayAllocation in StringUTF16::compress(). >> >>

Re: RFR: 8279508: Auto-vectorize Math.round API [v15]

2022-03-21 Thread Jatin Bhateja
On Tue, 22 Mar 2022 01:55:38 GMT, Quan Anh Mai wrote: >> A read from constant table will incur minimum of L1I access penalty to >> access code blob or at worst even more if data is not present in first level >> cache. Change was done for replace vpbroadcastd with vbroadcastss because of >>

Re: RFR: 8279508: Auto-vectorize Math.round API [v15]

2022-03-21 Thread Quan Anh Mai
On Tue, 22 Mar 2022 02:52:07 GMT, Jatin Bhateja wrote: >>> A read from constant table will incur minimum of L1I access penalty to >>> access code blob or at worst even more if data is not present in first >>> level cache >> >> But your approach comes at a cost of frontend bandwidth and port

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2]

2022-03-21 Thread Fei Yang
> This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the > https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive > Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests

Re: RFR: 8279508: Auto-vectorize Math.round API [v15]

2022-03-21 Thread Quan Anh Mai
On Mon, 21 Mar 2022 18:25:36 GMT, Jatin Bhateja wrote: > A read from constant table will incur minimum of L1I access penalty to access > code blob or at worst even more if data is not present in first level cache But your approach comes at a cost of frontend bandwidth and port contention,

Re: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes

2022-03-21 Thread Athijegannathan Sundararajan
On Mon, 21 Mar 2022 18:17:06 GMT, Mandy Chung wrote: > > $ javac com/acme/*.java > > is fine. Am I missing something? > > If you make P.Q private, it will fail the compilation. > Yes, I got that part. I did make a comment earlier ("Two of those subclasses are nested "private" in another

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2]

2022-03-21 Thread David Holmes
On Tue, 22 Mar 2022 03:31:16 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the >> https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive >> Unmatched

Re: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes

2022-03-21 Thread ExE Boss
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation > hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two > subclasses, one defined as a nested class and only a separate type in the

Re: RFR: 8283426: Fix 'exeption' typo [v2]

2022-03-21 Thread Andrey Turbanov
> Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo Apply suggestion Co-authored-by: Alexey Ivanov <70774172+aivanov-...@users.noreply.github.com> -

Re: RFR: JDK-8282798 java.lang.runtime.Carrier [v10]

2022-03-21 Thread ExE Boss
On Mon, 21 Mar 2022 06:29:53 GMT, Rémi Forax wrote: >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 309: >> >>> 307: static { >>> 308: LOOKUP = MethodHandles.lookup(); >>> 309: UNSAFE = Unsafe.getUnsafe(); >> >> It might be better to use

Re: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port

2022-03-21 Thread Fei Yang
On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the > https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive > Unmatched board.

RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port

2022-03-21 Thread Fei Yang
This PR implements JEP 422: Linux/RISC-V Port [1]. The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also

Re: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes

2022-03-21 Thread Athijegannathan Sundararajan
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation > hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two > subclasses, one defined as a nested class and only a separate type in the

Re: RFR: 8283426: Fix 'exeption' typo

2022-03-21 Thread Alexey Ivanov
On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` Marked as reviewed by aivanov (Reviewer). src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java line 201: > 199: /* > 200: * The method could not be implemented due to

Re: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes [v2]

2022-03-21 Thread Vyom Tewari
On Sun, 20 Mar 2022 14:05:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which handles >> https://bugs.openjdk.java.net/browse/JDK-8283411? >> >> The commit here moves the temporary byte array from being a member of the >> class to a local variable within the `skip`

Re: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes

2022-03-21 Thread Athijegannathan Sundararajan
On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation > hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two > subclasses, one defined as a nested class and only a separate type in the

Re: RFR: JDK-8282798 java.lang.runtime.Carrier [v10]

2022-03-21 Thread Rémi Forax
On Mon, 21 Mar 2022 05:17:31 GMT, ExE Boss wrote: >> Jim Laskey has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - Typos >> - Update Carrier.java >> - Redo API to use list, bring Carrier.component back > >

Re: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..)

2022-03-21 Thread Volker Simonis
Ping... On Thu, Mar 10, 2022 at 8:26 PM Lance Andersen wrote: > Hi Volker, > > Thank you for the reminder > > This is on my radar as well but have not had a chance spend any time on > this as yet. > > > > On Mar 9, 2022, at 2:33 PM, Volker Simonis > wrote: > > @Alan, @Lance, > > Sorry for my