Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-03-01 Thread Anton Kozlov
On Mon, 15 Feb 2021 17:59:54 GMT, Vladimir Kempik wrote: >> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810: >> >>> 808: #ifdef __APPLE__ >>> 809: // Less-than word types are stored one after another. >>> 810: // The code unable to handle this, bailout. >> >>

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-03-01 Thread Anton Kozlov
On Mon, 1 Mar 2021 10:46:34 GMT, Andrew Haley wrote: >> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not >> there, but "Arm can assign codes that are not published in this manual. All >> values not assigned by Arm are reserved and must not be used.". I assume the

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v22]

2021-03-01 Thread Anton Kozlov
> Please review the implementation of JEP 391: macOS/AArch64 Port. > > It's heavily based on existing ports to linux/aarch64, macos/x86_64, and > windows/aarch64. > > Major changes are in: > * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks > JDK-8253817, JDK-8253818)

Re: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v5]

2021-03-01 Thread Stuart Marks
> This rewrites the doc of ArraysSupport.newLength, adds detail to the > exception message, and adds a test. In addition to some renaming and a bit of > refactoring of the actual code, I also made two changes of substance to the > code: > > 1. I fixed a problem with overflow checking. In the

Re: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v4]

2021-03-01 Thread Stuart Marks
> This rewrites the doc of ArraysSupport.newLength, adds detail to the > exception message, and adds a test. In addition to some renaming and a bit of > refactoring of the actual code, I also made two changes of substance to the > code: > > 1. I fixed a problem with overflow checking. In the

Re: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message [v3]

2021-03-01 Thread Stuart Marks
> This rewrites the doc of ArraysSupport.newLength, adds detail to the > exception message, and adds a test. In addition to some renaming and a bit of > refactoring of the actual code, I also made two changes of substance to the > code: > > 1. I fixed a problem with overflow checking. In the

Integrated: 8261670: Add javadoc for the XML processing limits

2021-03-01 Thread Joe Wang
On Thu, 25 Feb 2021 22:04:41 GMT, Joe Wang wrote: > Add the documentation for XML processing limits to module summary. The limits > were previously documented in Java tutorial and guide. This pull request has now been integrated. Changeset: 6635d7a5 Author:Joe Wang URL:

Re: RFR: 8261670: Add javadoc for the XML processing limits [v4]

2021-03-01 Thread Joe Wang
On Tue, 2 Mar 2021 00:19:22 GMT, Naoto Sato wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Change the description of the property table to indicate that the list of >> the properties is not exhaustive > > Marked as

Re: RFR: JDK-8261518: jpackage looks for main module in current dir when there is no module-path

2021-03-01 Thread Alexander Matveev
On Mon, 1 Mar 2021 15:55:39 GMT, Andy Herrick wrote: > when the app modules have already been jlinked with the runtime, and there is > no need for module-path, jpackage was acting as if the module-path was "." > and picking up jars in the current directory. Marked as reviewed by almatvee

Re: Inconsistency in Constructor.getGenericParameterTypes()

2021-03-01 Thread Joe Darcy
Hi Remi, As package level statement would be helpful as long as it was linked to from specific types and methods (as java.lang.Class and java.lang.Package are part of core reflection but not the java.lang.reflect package). As you state, core reflection is *mostly* a view of what is

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5]

2021-03-01 Thread Jie Fu
On Sun, 28 Feb 2021 13:31:38 GMT, Jie Fu wrote: >> `@requires vm.compiler2.enabled` had been added. >> Thanks. > > @PaulSandoz , are you also OK with the latest version? > Thanks. > @DamonFool I think Vladimir is correct in the layering, in this respect i > think we can make things a littler

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v7]

2021-03-01 Thread Jie Fu
> Hi all, > > Vector API fails to work when: > - case 1: MaxVectorSize is set to <=8, or > - case 2: C2 is disabled > > The reason is that {max/preferred} VectorShape initialization fails in both > cases. > And the root cause is that VectorSupport_GetMaxLaneCount [1] returns > unreasonable

Re: RFR: 8261670: Add javadoc for the XML processing limits [v4]

2021-03-01 Thread Naoto Sato
On Mon, 1 Mar 2021 23:59:11 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The >> limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8261670: Add javadoc for the XML processing limits [v4]

2021-03-01 Thread Lance Andersen
On Mon, 1 Mar 2021 23:59:11 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The >> limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8261670: Add javadoc for the XML processing limits [v4]

2021-03-01 Thread Iris Clark
On Mon, 1 Mar 2021 23:59:11 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The >> limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last

Re: RFR: 8261670: Add javadoc for the XML processing limits [v4]

2021-03-01 Thread Joe Wang
> Add the documentation for XML processing limits to module summary. The limits > were previously documented in Java tutorial and guide. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: Change the description of the property table to

Re: Inconsistency in Constructor.getGenericParameterTypes()

2021-03-01 Thread Remi Forax
Hi Joe, i think the overview of the package java.lang.reflect should discuss the fact that the reflection view is what is stored in the classfile, not exactly a reflection of the java code. So depending on what you are requesting, you can see synthetic parameters generated by javac or only the

Re: Inconsistency in Constructor.getGenericParameterTypes()

2021-03-01 Thread Joe Darcy
Hi Oliver, Perhaps the time has come to make a run at discussing this situation in the javadoc. One challenge in writing this material up is to phrase and structure the text so it offers a net-clarification of the situation. In other words, to not distract or confuse most readers on what is

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v26]

2021-03-01 Thread Jim Laskey
> This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . > > javadoc can be found at >

Re: RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently [v2]

2021-03-01 Thread Paul Sandoz
On Mon, 1 Mar 2021 19:30:00 GMT, Maurizio Cimadamore wrote: >> This simple fix reduces the amount of concurrency on the foreign memory >> TestHandshake test. As this test spins a new accessor thread for each >> available processors, on machines which feature an high number of available >>

Integrated: JDK-8261839: Error creating runtime package on macos without mac-package-identifier

2021-03-01 Thread Andy Herrick
On Thu, 25 Feb 2021 21:15:44 GMT, Andy Herrick wrote: > …age-identifier This pull request has now been integrated. Changeset: 642f45f9 Author:Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/642f45f9 Stats: 24 lines in 4 files changed: 8 ins; 5 del; 11 mod 8261839:

Re: RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently [v2]

2021-03-01 Thread Maurizio Cimadamore
On Fri, 26 Feb 2021 17:56:21 GMT, Paul Sandoz wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Address review comments > > test/jdk/java/foreign/TestHandshake.java line 60: > >> 58: >> 59: static final

Re: RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently [v2]

2021-03-01 Thread Maurizio Cimadamore
> This simple fix reduces the amount of concurrency on the foreign memory > TestHandshake test. As this test spins a new accessor thread for each > available processors, on machines which feature an high number of available > processors (because of multi-threading), and which are slower in

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5]

2021-03-01 Thread Paul Sandoz
On Sun, 28 Feb 2021 13:31:38 GMT, Jie Fu wrote: >> `@requires vm.compiler2.enabled` had been added. >> Thanks. > > @PaulSandoz , are you also OK with the latest version? > Thanks. @DamonFool I think Vladimir is correct in the layering, in this respect i think we can make things a littler

Re: RFR: JDK-8261518: jpackage looks for main module in current dir when there is no module-path

2021-03-01 Thread Alexey Semenyuk
On Mon, 1 Mar 2021 15:55:39 GMT, Andy Herrick wrote: > when the app modules have already been jlinked with the runtime, and there is > no need for module-path, jpackage was acting as if the module-path was "." > and picking up jars in the current directory. Marked as reviewed by asemenyuk

Re: RFR: JDK-8261839: Error creating runtime package on macos without mac-package-identifier

2021-03-01 Thread Alexander Zuev
On Thu, 25 Feb 2021 21:15:44 GMT, Andy Herrick wrote: > …age-identifier Looks fine. - Marked as reviewed by kizune (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2730

RFR: JDK-8261518: jpackage looks for main module in current dir when there is no module-path

2021-03-01 Thread Andy Herrick
when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory. - Commit messages: - JDK-8261518: jpackage looks for main module in current dir

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-03-01 Thread Jim Laskey
On Mon, 1 Mar 2021 15:12:46 GMT, Roger Riggs wrote: >> throw new IllegalArgumentException("The random number generator "" + name + >> "" can not be located"); > > The message only captures the failure if the result of `fm.get()` is null. > It does not capture the failure if the name is found

Re: RFR: JDK-8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java

2021-03-01 Thread Christoph Göttschkes
On Sat, 27 Feb 2021 08:03:34 GMT, Alan Bateman wrote: >> Please review this small patch which fixes the coding style of >> CharacterDataPrivateUse.java > > Looks fine. This source file was a .template until a few weeks ago, probably > should have fixed the indentation issues when moving it to

Re: RFR: 8262379: Add regression test for JDK-8257746

2021-03-01 Thread Severin Gehwolf
On Mon, 1 Mar 2021 14:33:06 GMT, Harold Seigel wrote: >> Fails prior the patch of JDK-8257746, passes after. As expected. >> >> Thoughts? > > The new tests looks good. Thanks for adding it. > > Harold Thanks for the review @hseigel! - PR:

Integrated: 8262379: Add regression test for JDK-8257746

2021-03-01 Thread Severin Gehwolf
On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf wrote: > Fails prior the patch of JDK-8257746, passes after. As expected. > > Thoughts? This pull request has now been integrated. Changeset: 4c9adce2 Author:Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/4c9adce2

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-03-01 Thread Roger Riggs
On Mon, 1 Mar 2021 13:23:48 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java >> line 232: >> >>> 230: Provider provider = fm.get(name); >>> 231: if (!isSubclass(category, provider)) { >>> 232: throw new

Re: RFR: 8262379: Add regression test for JDK-8257746

2021-03-01 Thread Harold Seigel
On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf wrote: > Fails prior the patch of JDK-8257746, passes after. As expected. > > Thoughts? The new tests looks good. Thanks for adding it. Harold - Marked as reviewed by hseigel (Reviewer). PR:

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-03-01 Thread Jim Laskey
On Fri, 26 Feb 2021 21:32:12 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 57 commits: >> >> - Merge branch 'master' into 8248862 >> - Adjust ThreadLocalRandom javadoc inheritence >> -

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-03-01 Thread Jim Laskey
On Fri, 26 Feb 2021 21:25:38 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 57 commits: >> >> - Merge branch 'master' into 8248862 >> - Adjust ThreadLocalRandom javadoc inheritence >> -

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

2021-03-01 Thread Jim Laskey
On Fri, 26 Feb 2021 19:30:09 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 57 commits: >> >> - Merge branch 'master' into 8248862 >> - Adjust ThreadLocalRandom javadoc inheritence >> -

Re: RFR: 8262379: Add regression test for JDK-8257746

2021-03-01 Thread Severin Gehwolf
On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf wrote: > Fails prior the patch of JDK-8257746, passes after. As expected. > > Thoughts? @poonamparhar @hseigel Could you please take a look? It's just a simple regression test for the JDK-8257746 NPE regression. - PR:

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v4]

2021-03-01 Thread Peter Levart
On Sun, 28 Feb 2021 10:28:56 GMT, Attila Szegedi wrote: >> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with >> "AssertionError: Should have GCd a method handle by now" > > Attila Szegedi has updated the pull request with a new target base due to a > merge or a rebase.

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]

2021-03-01 Thread Andrew Haley
On Fri, 12 Feb 2021 11:42:59 GMT, Vladimir Kempik wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194: >> >>> 192: // may get turned off by -fomit-frame-pointer. >>> 193: frame os::get_sender_for_C_frame(frame* fr) { >>> 194: return frame(fr->link(), fr->link(),

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

2021-03-01 Thread Andrew Haley
On Fri, 5 Feb 2021 17:20:55 GMT, Anton Kozlov wrote: >> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93: >> >>> 91: CPU_MARVELL = 'V', >>> 92: CPU_INTEL = 'i', >>> 93: CPU_APPLE = 'a', >> >> The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture >>

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]

2021-03-01 Thread Andrew Haley
On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]

2021-03-01 Thread Andrew Haley
On Thu, 4 Feb 2021 23:01:52 GMT, Gerard Ziemski wrote: >> Anton Kozlov has updated the pull request incrementally with six additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos >> - Add comments to WX transitions >> >>

RFR: 8262503: Support records in Dynalink

2021-03-01 Thread Attila Szegedi
8262503: Support records in Dynalink - Commit messages: - Document behavior changes - Add support for records to Dynalink - Test the desired functionality Changes: https://git.openjdk.java.net/jdk/pull/2767/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2767=00

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]

2021-03-01 Thread Andrew Haley
On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v9]

2021-03-01 Thread Patrick Concannon
> Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti > documentation to use type test pattern instead of instanceof once JEP 375 > exits preview' ? > > This change updates the example code displayed in the API documentation for > mapMulti to use the type test

Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v7]

2021-03-01 Thread Patrick Concannon
On Wed, 24 Feb 2021 19:26:02 GMT, Stuart Marks wrote: >> Patrick Concannon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8252399: Converted JavadocExamples to test > > src/java.base/share/classes/java/util/stream/Stream.java line 414:

Re: RFR: 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview [v8]

2021-03-01 Thread Patrick Concannon
> Hi, > > Could someone please review my changeset for JDK-8252399: 'Update mapMulti > documentation to use type test pattern instead of instanceof once JEP 375 > exits preview' ? > > This change updates the example code displayed in the API documentation for > mapMulti to use the type test

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v4]

2021-03-01 Thread Aleksey Shipilev
On Sun, 28 Feb 2021 10:28:56 GMT, Attila Szegedi wrote: >> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with >> "AssertionError: Should have GCd a method handle by now" > > Attila Szegedi has updated the pull request with a new target base due to a > merge or a rebase.