Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13]

2021-06-14 Thread Igor Veresov
On Wed, 9 Jun 2021 08:53:40 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r >> 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which >> annotated with @IntrinsicCandidate and it only has a corresponding C1 >> intrinsic version. >

Re: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v13]

2021-06-14 Thread Yi Yang
On Sat, 12 Jun 2021 08:22:32 GMT, Thomas Stuefe wrote: > Hi Yi, > > you may need to add the option to the obsolete-flags-table though as > described in arguments.cpp: > > https://github.com/openjdk/jdk/blob/5cee23a9ed0b7fe2657be7492d9c1f78fcd02ebf/src/hotspot/share/runtime/arguments.cpp#L489-L

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Peter Firmstone
On 15/06/2021 2:23 am, David Lloyd wrote: On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone wrote: 1. Develop authorization layer security provider services in OpenJDK, back port it to Java 8 and Java 11 (these provide most of the utilised functionality of SecurityManager, allowing d

Integrated: 8268626: Remove native pre-jdk9 support for jtreg failure handler

2021-06-14 Thread Leonid Mesnik
On Fri, 11 Jun 2021 18:44:38 GMT, Leonid Mesnik wrote: > jtreg failure handler uses native lib to implement getPid for preJDK9. > Currently. it is not needed and might be removed. This pull request has now been integrated. Changeset: 2e70bc35 Author:Leonid Mesnik URL: https://git.o

Re: RFR: 8266310: deadlock while loading the JNI code [v6]

2021-06-14 Thread Mandy Chung
On Fri, 11 Jun 2021 10:00:14 GMT, Aleksei Voitylov wrote: >> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java >> line 84: >> >>> 82: >>> 83: private static OutputAnalyzer createJar(String outputJar, String... >>> classes) throws Throwable { >>> 84:

Re: RFR: 8266310: deadlock while loading the JNI code [v7]

2021-06-14 Thread Mandy Chung
On Fri, 11 Jun 2021 10:03:44 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the >> two lock objects - a lock object associated with the class being loaded, and >> the ClassLoader.loadedLibraryNames hash map, locked during the native >> li

[jdk17] RFR: 8266518: Refactor and expand scatter/gather tests

2021-06-14 Thread Paul Sandoz
Refactor scatter/gather tests to be included in the load/store test classes and expand to support access between `ShortVector` and and `char[]`, and access between `ByteVector` and `boolean[]`. Vector tests pass on linux-x64 linux-aarch64 macosx-x64, and windows-x64. - Commit messa

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread David Lloyd
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone wrote: > 1. Develop authorization layer security provider services in OpenJDK, > back port it to Java 8 and Java 11 (these provide most of the > utilised functionality of SecurityManager, allowing developers to > only implement those whi

[jdk17] RFR: 8268353: Test libsvml.so is and is not present in jdk image

2021-06-14 Thread Paul Sandoz
Test that when the jdk.incubator.vector module is present that libsvml.so is present, and test the opposite case. - Commit messages: - 8268353: Test libsvml.so is and is not present in jdk image Changes: https://git.openjdk.java.net/jdk17/pull/47/files Webrev: https://webrevs.open

Integrated: Merge jdk17

2021-06-14 Thread Jesper Wilhelmsson
On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 17295b1b Author:Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/17295b1bb02b2121978f1459b2e75c5e1031e7ea Stats: 721 l

Re: RFR: Merge jdk17 [v2]

2021-06-14 Thread Jesper Wilhelmsson
> Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson 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.java.net/jdk/pull/4484/fil

Re: RFR: Merge jdk17 [v2]

2021-06-14 Thread Daniel Fuchs
On Mon, 14 Jun 2021 15:58:15 GMT, Jesper Wilhelmsson wrote: >> Forwardport JDK 17 -> JDK 18 > > Jesper Wilhelmsson 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. Looked a

Withdrawn: 8268353: Test libsvml.so is and is not present in jdk image

2021-06-14 Thread Paul Sandoz
On Tue, 8 Jun 2021 23:27:52 GMT, Paul Sandoz wrote: > Test that when the jdk.incubator.vector module is present that libsvml.so is > present, and test the opposite case. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4421

Re: RFR: Merge jdk17

2021-06-14 Thread Daniel D . Daugherty
On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 Thumbs up! Thanks for doing this sync forward. - Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4484

[jdk17] RFR: 8268566: java/foreign/TestResourceScope.java timed out

2021-06-14 Thread Maurizio Cimadamore
This patch contains another minor tweak to TestResourceScope as we have seen this test timing out at least once (on arm64). I realized that some of the logic recently introduced in the test could lead to the test waiting forever: for instance, if all threads are executed right away before the m

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Sean Mullan
On 6/14/21 7:34 AM, Rafael Winterhalter wrote: Why not add the property once this is the case, though? As it is now, I read the 'forRemoval' property to indicate a problem that should be instantly addressed. With Java 8 being a common baseline for libraries and the version being supported unti

Re: RFR: 8265474: Dubious 'null' assignment in CompactByteArray.expand

2021-06-14 Thread Andrey Turbanov
On Wed, 23 Dec 2020 16:06:30 GMT, Andrey Turbanov wrote: > I propose to remove 'null' assignment of field CompactByteArray.values in > `expand` method. In the next statement this field is overridden with another > value - `tempArray`. > This code was there from initial load of OpenJDK sources.

RFR: Merge jdk17

2021-06-14 Thread Jesper Wilhelmsson
Forwardport JDK 17 -> JDK 18 - Commit messages: - 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow - 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed" - 826863

[11u] java/nio/channels/AsynchronousFileChannel/Basic.java crashes on Windows x64

2021-06-14 Thread Doerr, Martin
Hi, we observe crashes in jdk 11.0.12 on Windows: https://bugs.openjdk.java.net/browse/JDK-8267440 I haven’t found any backport which looks like obviously causing it. We had different theories which include: * Antivirus tool which keeps the test file open. * Error in handling of OVERLAP

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Rafael Winterhalter
Why not add the property once this is the case, though? As it is now, I read the 'forRemoval' property to indicate a problem that should be instantly addressed. With Java 8 being a common baseline for libraries and the version being supported until (at least) 2030, I don't see how this removal woul

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Peter Firmstone
On 14/06/2021 6:37 pm, Alan Bateman wrote: There are some libraries where the maintainers have put effort into working with a SM. Yes, I am one of them, very much so. At first it's a shock, but the show must go on, it could be an opportunity to address some long standing issues also. If

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Ron Pressler
The JEP addresses this: > In future JDK releases, we will degrade the Security Manager APIs so that > they remain in place but have limited or no functionality. ... This will allow libraries that support the Security Manager and were compiled against previous Java releases to continue to wor

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Peter Firmstone
Binary compatibility only? Security.getSecurityManager() always returns null. Security.setSecurityManager() always throws a SecurityException (compatible because existing SecurityManager is allowed to prevent the call from succeeding). SecurityManager constructor always throws a SecurityExce

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Rafael Winterhalter
One example for a currently necessary "doPrivileged" are Java agents where a class loading triggers agent code where the agent shares the stack with any code that loads a class for the first time. Otherwise, Byte Buddy wraps anything that might require privileges as privileged action to allow setti

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Alan Bateman
On 14/06/2021 08:35, Peter Firmstone wrote: I wouldn't want to see SecurityManager and Policy be neutralized, it's better to remove it and fail early so people update their software, there's a risk they may update without realizing it's no longer fully functional.   Get rid of the baggage so

[jdk17] Integrated: 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed"

2021-06-14 Thread Chris Hegarty
On Fri, 11 Jun 2021 15:26:50 GMT, Chris Hegarty wrote: > There is the possibility for a race in the test, where the outbound socket > buffer is still being filled, after 5 seconds, when the main test thread > tries to close the resource scope. > > The test has been updated to set the send/rece

Integrated: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException

2021-06-14 Thread Rafael Winterhalter
On Sun, 9 May 2021 21:59:29 GMT, Rafael Winterhalter wrote: > During annotation parsing, the parser assumes that a declared property is of > an array type if the parsed annotation property is defined as an array. In > this case, the component type is `null`, and a `NullPointerException` is >

Low level hooks in JDK for permission checks.

2021-06-14 Thread Peter Firmstone
Making things clearer if I can: Some thoughts on hooks: * Utilize java.security.Provider, so as not to expose jdk implementation code.  Eg: a module declaration or META-INF/services/java.security.Provider to obtain relevant instances of java.security.Guard, where Permission implementat

Re: JEP 411: Deprecation with removal would break most existing Java libraries

2021-06-14 Thread Peter Firmstone
My thoughts on how to proceed with this is: 1. Develop authorization layer security provider services in OpenJDK, back port it to Java 8 and Java 11 (these provide most of the utilised functionality of SecurityManager, allowing developers to only implement those which they need, without