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

2021-06-11 Thread Yi Yang
On Sat, 12 Jun 2021 06:50:48 GMT, Thomas Stuefe wrote: > This change removed a product flag so I wonder how it could be integrated > without a CSR? It's a diagnostic product flag, so it’ okay to remove it without issuing CSR. But I am not 100% sure. @dholmes-ora, do you have any comment about

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

2021-06-11 Thread Thomas Stuefe
On Sat, 12 Jun 2021 06:29:50 GMT, Volker Simonis wrote: > This change removed a product flag so I wonder how it could be integrated > without a CSR? And if the intention was to remove it, should it not have been marked as obsolete first? - PR: https://git.openjdk.java.net/jdk/pul

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

2021-06-11 Thread Volker Simonis
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-11 Thread Yi Yang
On Fri, 11 Jun 2021 18:05:45 GMT, Igor Veresov wrote: > I guess you need to do the "integrate" command again. Okay,thank you all for taking time to look at this - PR: https://git.openjdk.java.net/jdk/pull/3615

Integrated: 8265518: C1: Intrinsic support for Preconditions.checkIndex

2021-06-11 Thread Yi Yang
On Thu, 22 Apr 2021 06:55:41 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: 8268626: Remove native pre-jdk9 support for jtreg failure handler

2021-06-11 Thread Erik Joelsson
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. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4476

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

2021-06-11 Thread Leonid Mesnik
jtreg failure handler uses native lib to implement getPid for preJDK9. Currently. it is not needed and might be removed. - Commit messages: - native lib support removed. Changes: https://git.openjdk.java.net/jdk/pull/4476/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr

Re: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2]

2021-06-11 Thread Vicente Romero
On Fri, 11 Jun 2021 18:17:10 GMT, Vicente Romero wrote: >> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) >> which was intended to openjdk/jdk. >> >> Please review this PR which is syncing the implementation of >> `DirectMethodHandleDesc.Kind.valueOf(int)` and >> `Di

Re: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2]

2021-06-11 Thread Vicente Romero
> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) > which was intended to openjdk/jdk. > > Please review this PR which is syncing the implementation of > `DirectMethodHandleDesc.Kind.valueOf(int)` and > `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec.

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

2021-06-11 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-11 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: [jdk17] RFR: 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with "IllegalStateException: This segment is already closed"

2021-06-11 Thread Chris Hegarty
On Fri, 11 Jun 2021 16:27:07 GMT, Daniel Fuchs 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/

Re: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling

2021-06-11 Thread Vicente Romero
On Fri, 11 Jun 2021 15:15:12 GMT, Vicente Romero wrote: >> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) >> which was intended to openjdk/jdk. >> >> Please review this PR which is syncing the implementation of >> `DirectMethodHandleDesc.Kind.valueOf(int)` and >> `Di

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

2021-06-11 Thread Daniel Fuchs
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

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

2021-06-11 Thread Chris Hegarty
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/receive buffer sizes in an attempt/hint to limit the accepted/connecte

Re: [jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling

2021-06-11 Thread Vicente Romero
On Fri, 11 Jun 2021 15:01:20 GMT, Vicente Romero wrote: > This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) > which was intended to openjdk/jdk. > > Please review this PR which is syncing the implementation of > `DirectMethodHandleDesc.Kind.valueOf(int)` and > `DirectMe

Re: RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling [v2]

2021-06-11 Thread Vicente Romero
On Thu, 10 Jun 2021 23:26:21 GMT, Vicente Romero wrote: >> Please review this PR which is just syncing the implementation of >> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the >> method's spec is that if the value of the `refKind` parameter is: >> MethodHandleInfo.REF

Withdrawn: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling

2021-06-11 Thread Vicente Romero
On Tue, 8 Jun 2021 16:46:36 GMT, Vicente Romero wrote: > Please review this PR which is just syncing the implementation of > DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the > method's spec is that if the value of the `refKind` parameter is: > MethodHandleInfo.REF_invo

[jdk17] RFR: 8267421: j.l.constant.DirectMethodHandleDesc.Kind.valueOf(int) implementation doesn't conform to the spec regarding REF_invokeInterface handling

2021-06-11 Thread Vicente Romero
This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which was intended to openjdk/jdk. Please review this PR which is syncing the implementation of `DirectMethodHandleDesc.Kind.valueOf(int)` and `DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading

RFR: 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML

2021-06-11 Thread Masanori Yano
Hi all, Could you please review the 8268457 bug fixes? The problem is that ToHTMLStream applies processing for non-surrogate pairs to the surrogate pair. This fix changes the processing for non-surrogate pairs to the else condition. - Commit messages: - clean up whitespace - 8268

Re: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home [v2]

2021-06-11 Thread ScientificWare
On Wed, 9 Jun 2021 14:13:06 GMT, Erik Joelsson wrote: >> ScientificWare has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Changes to keep home_dtd null check. >> >> As suggested in conversation moving `+ File.separator` is more elegan

Integrated: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home

2021-06-11 Thread ScientificWare
On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare wrote: > This concerns [dtdbuilder > tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder). > > In jshell, try `System.getProperty("html32") + ""` you'll get a `String`. > > So, in `DTDBuilder.java` when

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

2021-06-11 Thread Aleksei Voitylov
On Mon, 31 May 2021 23:57:09 GMT, Mandy Chung wrote: >> Aleksei Voitylov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> address review comments > > test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java > line

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

2021-06-11 Thread Aleksei Voitylov
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

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

2021-06-11 Thread Aleksei Voitylov
> 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 library > load operation. > > Problem being fixed: > > The initial

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

2021-06-11 Thread Aleksei Voitylov
On Mon, 31 May 2021 20:56:14 GMT, Mandy Chung wrote: >> Aleksei Voitylov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> address review comments > > src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 207: > >> 205

Re: RFR: 8265909 : build.tools.dtdbuilder.DTDBuilder.java failed detecting missing path of dtd_home [v2]

2021-06-11 Thread ScientificWare
On Wed, 9 Jun 2021 14:13:06 GMT, Erik Joelsson wrote: >> ScientificWare has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Changes to keep home_dtd null check. >> >> As suggested in conversation moving `+ File.separator` is more elegan