Re: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]

2021-01-19 Thread Claes Redestad
> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which > has fast-paths for common encoding) and avoiding a `toCharArray` call on the > input by refactoring the `normalizeNativePath` code to operate on `String`. > This might have a cost on files on Mac that need

Re: RFR: 8259867: Move encoding checks into ZipCoder

2021-01-19 Thread Lance Andersen
On Sat, 16 Jan 2021 17:49:38 GMT, eirbjo wrote: > ZipFile.Source.initCEN verifies that entry names are encoding into bytes > valid in the entry's encoding. It does so by calling encoding-specific > checking methods, so it also needs to determine which check method to call > for each entry. >

Re: [jdk16] RFR: 8259796: timed CompletableFuture.get may swallow InterruptedException [v2]

2021-01-19 Thread Alan Bateman
On Tue, 19 Jan 2021 02:50:54 GMT, Martin Buchholz wrote: >> 8259796: timed CompletableFuture.get may swallow InterruptedException > > Martin Buchholz has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains one commit: > > JDK-8259796

Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v3]

2021-01-19 Thread Alan Bateman
On Mon, 11 Jan 2021 14:22:20 GMT, Johannes Kuhn wrote: >> This issue requires a Reviewer from someone working in this area. Please do >> not sponsor or integrate until that review has been done. > >> >> >> This issue requires a Reviewer from someone working in this area. Please do >> not

Re: RFR: 8132984: incorrect type for Reference.discovered [v3]

2021-01-19 Thread Roger Riggs
On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett wrote: >> Please review this change which fixes the type of the private >> Reference.discovered field. It was Reference, but that's wrong because >> it can be any Reference object. >> >> I've changed it to Reference and let that flow through,

Re: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]

2021-01-19 Thread Alan Bateman
On Tue, 19 Jan 2021 12:02:13 GMT, Claes Redestad wrote: >> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which >> has fast-paths for common encoding) and avoiding a `toCharArray` call on the >> input by refactoring the `normalizeNativePath` code to operate on `String`.

Re: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]

2021-01-19 Thread Alan Bateman
On Tue, 19 Jan 2021 12:26:08 GMT, Claes Redestad wrote: >> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which >> has fast-paths for common encoding) and avoiding a `toCharArray` call on the >> input by refactoring the `normalizeNativePath` code to operate on `String`.

Re: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]

2021-01-19 Thread Alan Bateman
On Tue, 19 Jan 2021 12:02:13 GMT, Claes Redestad wrote: >> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which >> has fast-paths for common encoding) and avoiding a `toCharArray` call on the >> input by refactoring the `normalizeNativePath` code to operate on `String`.

[11u] RFR: 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

2021-01-19 Thread Doerr, Martin
Hi, JDK-7146776 is backported to 11.0.11-oracle. I'd like to backport it for parity. Change doesn't apply cleanly because of Copyright year changes and a minor difference in a hunk which gets removed by this change: 11u Code contains host.equals(""), patch wants to remove host.isEmpty() from

[jdk16] Integrated: 8259796: timed CompletableFuture.get may swallow InterruptedException

2021-01-19 Thread Martin Buchholz
On Sun, 17 Jan 2021 18:39:55 GMT, Martin Buchholz wrote: > 8259796: timed CompletableFuture.get may swallow InterruptedException This pull request has now been integrated. Changeset: f7b96d34 Author:Martin Buchholz URL: https://git.openjdk.java.net/jdk16/commit/f7b96d34 Stats:

Re: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

2021-01-19 Thread Mandy Chung
On Mon, 18 Jan 2021 12:09:23 GMT, Claes Redestad wrote: > Change `MethodHandles.byteArrayViewVarHandle` to throw > `ArrayIndexOutOfBoundsException` rather than the more generic > `IndexArrayOutOfBoundsException`. This feels more natural, and reduces the > risk for subtle behavioral mismatch

Re: RFR: 8259842: Remove Result cache from StringCoding [v7]

2021-01-19 Thread Roger Riggs
On Mon, 18 Jan 2021 09:26:07 GMT, Claes Redestad wrote: >> The `StringCoding.resultCached` mechanism is used to remove the allocation >> of a `StringCoding.Result` object on potentially hot paths used in some >> `String` constructors. Using a `ThreadLocal` has overheads though, and the >>

Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v3]

2021-01-19 Thread Naoto Sato
On Mon, 18 Jan 2021 05:52:57 GMT, Leo Jiang wrote: >> This is the changes for JDK 16 msg drop 10. > > Leo Jiang has updated the pull request incrementally with one additional > commit since the last revision: > > fix the missing copyright year for standard.properties Marked as reviewed by

Re: RFR: 8132984: incorrect type for Reference.discovered [v4]

2021-01-19 Thread Kim Barrett
> Please review this change which fixes the type of the private > Reference.discovered field. It was Reference, but that's wrong because > it can be any Reference object. > > I've changed it to Reference and let that flow through, updating some > other variables that were previously somewhat

Re: RFR: 8132984: incorrect type for Reference.discovered [v3]

2021-01-19 Thread Kim Barrett
On Tue, 19 Jan 2021 11:15:17 GMT, Peter Levart wrote: >> Kim Barrett has updated the pull request incrementally with one additional >> commit since the last revision: >> >> plevart improvement > > This looks good. Thanks @plevart , @rkennke , @RogerRiggs , and @mlchung for reviews.

Re: RFR: 8132984: incorrect type for Reference.discovered [v3]

2021-01-19 Thread Mandy Chung
On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett wrote: >> Please review this change which fixes the type of the private >> Reference.discovered field. It was Reference, but that's wrong because >> it can be any Reference object. >> >> I've changed it to Reference and let that flow through,

Re: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

2021-01-19 Thread Mandy Chung
On Tue, 19 Jan 2021 20:59:24 GMT, Claes Redestad wrote: > I agree the change is allowable within the current spec. The behavior change > is observable, though, and however unlikely there might be code that relies > on exact class of the exception being thrown. > So while perhaps not strictly

Re: RFR: 8259925: [Vector API] Unreasonable IndexOutOfBoundsException message when length < vlen

2021-01-19 Thread Paul Sandoz
On Mon, 18 Jan 2021 13:32:24 GMT, Jie Fu wrote: > Hi all, > > For this reproducer: > > import jdk.incubator.vector.ByteVector; > import jdk.incubator.vector.VectorSpecies; > > public class Test { > static final VectorSpecies SPECIES_128 = ByteVector.SPECIES_128; > static byte[] a =

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

2021-01-19 Thread Alex Menkov
On Sun, 17 Jan 2021 12:55:35 GMT, David Holmes wrote: >> Alex Menkov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Non-lava launchers should process all "-J" arguments > > Alex, > > This approach results in two scans of the argument

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

2021-01-19 Thread Alex Menkov
On Sun, 17 Jan 2021 12:55:35 GMT, David Holmes wrote: >> Alex Menkov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Non-lava launchers should process all "-J" arguments > > Alex, > > This approach results in two scans of the argument

Re: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

2021-01-19 Thread Claes Redestad
On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung wrote: > The change to AIOOBE is reasonable. Have you considered making this just as > an implementation change and leave the spec as is? What would be the benefits? AFAICT the CSR is still needed since it's a small behavioral change, and updating

RFR: Merge jdk16

2021-01-19 Thread Jesper Wilhelmsson
Forwardport JDK 16 -> JDK 17 - Commit messages: - Merge - 8259796: timed CompletableFuture.get may swallow InterruptedException The webrevs contain the adjustments done while merging with regards to each parent branch: - master:

Re: IllegalStateException in CharsetDecoder when inspecting JarFile contents on Java 15

2021-01-19 Thread Vitaly Davidovich
Hi Claes, You’re fast! :) Thanks for the bug report and working on a fix. Best, Vitaly On Tue, Jan 19, 2021 at 5:00 PM Claes Redestad wrote: > Filed: https://bugs.openjdk.java.net/browse/JDK-8260010 > > I have a potential fix ready, just trying to distill a minimal test case. > > /Claes > >

Integrated: Merge jdk16

2021-01-19 Thread Jesper Wilhelmsson
On Tue, 19 Jan 2021 21:48:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: cf25383d Author:Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/cf25383d Stats: 88 lines in 2 files changed: 29 ins;

Re: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

2021-01-19 Thread Claes Redestad
On Tue, 19 Jan 2021 20:30:46 GMT, Claes Redestad wrote: >> The change to AIOOBE is reasonable.Have you considered making this just >> as an implementation change and leave the spec as is? > >> The change to AIOOBE is reasonable. Have you considered making this just as >> an implementation

Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v5]

2021-01-19 Thread Johannes Kuhn
> Simple fix - one line change: > https://openjdk.github.io/cr/?repo=jdk=2000=00#sdiff-0. > > Most of the changes come from an additional test that fails without this fix: > > Error: Unable to load main class somelib.test.TestMain in module somelib > java.lang.IllegalAccessError:

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

2021-01-19 Thread David Holmes
On Tue, 19 Jan 2021 23:02:54 GMT, Alex Menkov wrote: >> The fix adds NMT handling for non-java launchers > > Alex Menkov has updated the pull request incrementally with one additional > commit since the last revision: > > Non-lava launchers should process all "-J" arguments Hi Alex, I

Re: RFR: 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

2021-01-19 Thread Mandy Chung
On 1/19/21 12:33 PM, Claes Redestad wrote: On Tue, 19 Jan 2021 19:42:38 GMT, Mandy Chung wrote: The change to AIOOBE is reasonable. Have you considered making this just as an implementation change and leave the spec as is? What would be the benefits? AFAICT the CSR is still needed since

Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v4]

2021-01-19 Thread Johannes Kuhn
> Simple fix - one line change: > https://openjdk.github.io/cr/?repo=jdk=2000=00#sdiff-0. > > Most of the changes come from an additional test that fails without this fix: > > Error: Unable to load main class somelib.test.TestMain in module somelib > java.lang.IllegalAccessError:

Re: RFR: JDK-8259395 Patching automatic module with additional packages re-creates module without "requires java.base" [v3]

2021-01-19 Thread Johannes Kuhn
On Tue, 19 Jan 2021 16:14:51 GMT, Alan Bateman wrote: >>> >>> >>> This issue requires a Reviewer from someone working in this area. Please do >>> not sponsor or integrate until that review has been done. >> >> Ok, increased the number of required reviewers to 2. >> Hope that was the right

Re: RFR: 8259707: LDAP channel binding does not work with StartTLS extension

2021-01-19 Thread Sean Mullan
On Thu, 14 Jan 2021 19:28:27 GMT, Alexey Bakhtin wrote: > Please review a small patch to enable LDAP TLS Channel Binding with StartTLS > Extension. > Test from the bug report and jtreg javax/naming tests are passed. Can you add a test for this or is it too hard? There are existing tests for

Re: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v4]

2021-01-19 Thread Valerie Peng
On Mon, 18 Jan 2021 13:39:04 GMT, Claes Redestad wrote: >> - The MD5 intrinsics added by >> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that >> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics >> from which the MD5 intrinsic takes

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

2021-01-19 Thread Alex Menkov
> The fix adds NMT handling for non-java launchers Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Non-lava launchers should process all "-J" arguments - Changes: - all: https://git.openjdk.java.net/jdk/pull/2106/files

Re: RFR: 8259707: LDAP channel binding does not work with StartTLS extension

2021-01-19 Thread Alexey Bakhtin
On Tue, 19 Jan 2021 20:24:21 GMT, Sean Mullan wrote: >> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS >> Extension. >> Test from the bug report and jtreg javax/naming tests are passed. > > Can you add a test for this or is it too hard? There are existing tests for

Integrated: 8132984: incorrect type for Reference.discovered

2021-01-19 Thread Kim Barrett
On Sat, 26 Dec 2020 03:25:51 GMT, Kim Barrett wrote: > Please review this change which fixes the type of the private > Reference.discovered field. It was Reference, but that's wrong because > it can be any Reference object. > > I've changed it to Reference and let that flow through, updating

Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL

2021-01-19 Thread Eirik Bjørsnøs
Hello, sun.net.www.protocol.jar.Handler.parseURL unconditionally calls String.substring twice on the spec string, even when ParseUtil.canonizeString later determines that no canonization was required. By letting canonizeString do the substring calls, but only when it determines that it is

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

2021-01-19 Thread Alex Menkov
On Tue, 19 Jan 2021 23:16:30 GMT, David Holmes wrote: > What do you mean by this? The -J args are not "translated" here but later in > TranslateApplicationArgs. I meant that they are translated in TranslateApplicationArgs. Looks like it's not clear. Updated the comment as you suggested.

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v3]

2021-01-19 Thread Alex Menkov
> The fix adds NMT handling for non-java launchers Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Updated comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/2106/files - new:

Re: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL

2021-01-19 Thread Eirik Bjørsnøs
> > > By letting canonizeString do the substring calls, but only when it > determines that it is needed, we can remove some unnecessary String and > byte[] allocations. > While English is not my mother tongue, I'm thinking we could maybe let the Vatican deal with canonizations and rename this to

Re: RFR: 8132984: incorrect type for Reference.discovered [v3]

2021-01-19 Thread Peter Levart
On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett wrote: >> Please review this change which fixes the type of the private >> Reference.discovered field. It was Reference, but that's wrong because >> it can be any Reference object. >> >> I've changed it to Reference and let that flow through,

Re: RFR: 8259947: (fs) Optimize UnixPath.encode implementation

2021-01-19 Thread Claes Redestad
On Tue, 19 Jan 2021 10:46:32 GMT, Aleksey Shipilev wrote: >> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which >> has fast-paths for common encoding) and avoiding a `toCharArray` call on the >> input by refactoring the `normalizeNativePath` code to operate on

Re: RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v2]

2021-01-19 Thread Claes Redestad
> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which > has fast-paths for common encoding) and avoiding a `toCharArray` call on the > input by refactoring the `normalizeNativePath` code to operate on `String`. > This might have a cost on files on Mac that need

Re: RFR: 8132984: incorrect type for Reference.discovered [v3]

2021-01-19 Thread Roman Kennke
On Mon, 18 Jan 2021 23:42:08 GMT, Kim Barrett wrote: >> Please review this change which fixes the type of the private >> Reference.discovered field. It was Reference, but that's wrong because >> it can be any Reference object. >> >> I've changed it to Reference and let that flow through,

Re: RFR: 8259947: Optimize UnixPath.encode

2021-01-19 Thread Chris Hegarty
On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad wrote: > This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which > has fast-paths for common encoding) and avoiding a `toCharArray` call on the > input by refactoring the `normalizeNativePath` code to operate on `String`. >

Re: RFR: 8259867: Move encoding checks into ZipCoder

2021-01-19 Thread Claes Redestad
On Sat, 16 Jan 2021 17:49:38 GMT, eirbjo wrote: > ZipFile.Source.initCEN verifies that entry names are encoding into bytes > valid in the entry's encoding. It does so by calling encoding-specific > checking methods, so it also needs to determine which check method to call > for each entry. >

Re: Performance regression in BuiltinClassLoader?

2021-01-19 Thread Claes Redestad
Since it's the exploded jdk build, why not `make ejb`?! Only half joking: it's short and easy to remember for those who prefer just building the exploded image - while not setting up trip wires for newcomers and the unwary. /Claes On 2021-01-19 06:48, Thomas Stüfe wrote: Renaming that thing

Re: RFR: 8259947: (fs) Optimize UnixPath.encode implementation

2021-01-19 Thread Aleksey Shipilev
On Tue, 19 Jan 2021 00:35:51 GMT, Claes Redestad wrote: > This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which > has fast-paths for common encoding) and avoiding a `toCharArray` call on the > input by refactoring the `normalizeNativePath` code to operate on `String`. >