Re: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character [v3]

2022-03-01 Thread Chris Hegarty
> The module finder implementation incorrectly uses the path-separator > character from the default file system, when mapping the relative path > of an entry in an exploded module to a package name. This causes > problems on Windows [*] when using a module finder with a custom file > system that

Re: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3]

2022-03-01 Thread Maxim Kartashev
On Mon, 28 Feb 2022 21:30:27 GMT, Roger Riggs wrote: >> Olga Mikhaltsova has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add a new line to the end of test file for JDK-8282008 > > (I'm still working on a more nuanced fix that works with

Integrated: 8282047: Enhance StringDecode/Encode microbenchmarks

2022-03-01 Thread Claes Redestad
On Thu, 17 Feb 2022 15:11:11 GMT, Claes Redestad wrote: > Splitting out these micro changes from #7231 > > - Clean up and simplify setup and code > - Add variants with different inputs with varying lengths and encoding > weights, but also relevant mixes of each so that we both cover

Re: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character [v3]

2022-03-01 Thread Daniel Fuchs
On Tue, 1 Mar 2022 08:13:57 GMT, Chris Hegarty wrote: >> The module finder implementation incorrectly uses the path-separator >> character from the default file system, when mapping the relative path >> of an entry in an exploded module to a package name. This causes >> problems on Windows [*]

Re: Should System.exit be controlled by a Scope Local?

2022-03-01 Thread Andrew Haley
On 3/1/22 11:45, Andrew Haley wrote: Sure, you wouldn't be able to use the default thread pool, but that's no big deal, I would have thought. I'm sorry, I'll say that again. :-) I meant to say "you wouldn't be able to use the default thread pool if you wanted to use threads with some

RFR: 8267319: Use larger default key sizes and algorithms based on CNSA

2022-03-01 Thread Valerie Peng
It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: - SHA-384 for secure hashing - AES-256 for symmetric encryption - RSA with 3072

Re: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6]

2022-03-01 Thread Lutz Schmidt
On Tue, 1 Mar 2022 19:12:17 GMT, Claes Redestad wrote: >> @theRealAph , @a74nh or someone familiar with aarch64 code, please review >> aarch64 changes. > >> @theRealAph , @a74nh or someone familiar with aarch64 code, please review >> aarch64 changes. > > Note that the aarch64 changes I've

Re: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2]

2022-03-01 Thread Paul Sandoz
On Tue, 1 Mar 2022 02:22:49 GMT, Quan Anh Mai wrote: >> Hi, >> >> `Objects.requireNonNull` may fail to be inlined. The call is expensive and >> may lead to objects escaping to the heap while the null check is cheap and >> is often elided. I have observed this when using the vector API when a

Re: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2]

2022-03-01 Thread Quan Anh Mai
On Tue, 1 Mar 2022 02:22:49 GMT, Quan Anh Mai wrote: >> Hi, >> >> `Objects.requireNonNull` may fail to be inlined. The call is expensive and >> may lead to objects escaping to the heap while the null check is cheap and >> is often elided. I have observed this when using the vector API when a

Integrated: 8282143: Objects.requireNonNull should be ForceInline

2022-03-01 Thread Quan Anh Mai
On Sat, 19 Feb 2022 05:51:52 GMT, Quan Anh Mai wrote: > Hi, > > `Objects.requireNonNull` may fail to be inlined. The call is expensive and > may lead to objects escaping to the heap while the null check is cheap and is > often elided. I have observed this when using the vector API when a call

Re: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2]

2022-03-01 Thread Paul Sandoz
On Wed, 2 Mar 2022 00:32:46 GMT, Quan Anh Mai wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> the other > > Thanks a lot for your reviews, do I need a second review for this? > @ExE-Boss IMO generally we only

Re: Should System.exit be controlled by a Scope Local?

2022-03-01 Thread Sean Mullan
On 3/1/22 8:01 AM, Andrew Haley wrote: On 3/1/22 11:45, Andrew Haley wrote: Sure, you wouldn't be able to use the default thread pool, but that's no big deal, I would have thought. I'm sorry, I'll say that again. :-) I meant to say "you wouldn't be able to use the default thread pool if

Re: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6]

2022-03-01 Thread Vladimir Kozlov
On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace >> `StringCoding.hasNegatives` with `countPositives`. The new method does a >> very similar pass, but alters the intrinsic to return the number of leading >>

Re: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F

2022-03-01 Thread Roger Riggs
On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although > it is an incompatible change, I believe it is worth the fix. For that, a CSR > has been drafted. Marked as reviewed by rriggs (Reviewer). - PR:

Re: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3]

2022-03-01 Thread Roger Riggs
On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program >> Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe

Re: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F

2022-03-01 Thread Naoto Sato
On Tue, 1 Mar 2022 11:22:35 GMT, Lance Andersen wrote: > Are there any TCK tests that need to be modified or Added? I made a very > quick scan of the open/test/jdk/java/time/tck/java/time/ dirs and did not see > any tests but of course I could have missed it There are test cases in the `TCK`

Re: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6]

2022-03-01 Thread Lutz Schmidt
On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace >> `StringCoding.hasNegatives` with `countPositives`. The new method does a >> very similar pass, but alters the intrinsic to return the number of leading >>

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

2022-03-01 Thread Jatin Bhateja
> Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR > nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH

Re: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6]

2022-03-01 Thread Claes Redestad
On Tue, 1 Mar 2022 18:32:00 GMT, Vladimir Kozlov wrote: > @theRealAph , @a74nh or someone familiar with aarch64 code, please review > aarch64 changes. Note that the aarch64 changes I've put in for now implements `countPositives` to return `0` if there's a negative value anywhere, otherwise

Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA

2022-03-01 Thread Anthony Scarpino
On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for

Re: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21]

2022-03-01 Thread Stuart Marks
On Sun, 20 Feb 2022 19:50:01 GMT, liach wrote: >> @liach Hi. please have a look at the latest commit. >> do you think it be better now? > > Oops, didn't notice there was this helpful `init` method. Does look much more > straightforward now. I'm starting to look at this again. First, a quick

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

2022-03-01 Thread Jatin Bhateja
> Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR > nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH

RFR: 8282432: Optimize masked "test" Vector API with predicate feature

2022-03-01 Thread Xiaohong Gong
The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the

Integrated: 8282444: Module finder incorrectly assumes default file system path-separator character

2022-03-01 Thread Chris Hegarty
On Mon, 28 Feb 2022 11:12:17 GMT, Chris Hegarty wrote: > The module finder implementation incorrectly uses the path-separator > character from the default file system, when mapping the relative path > of an entry in an exploded module to a package name. This causes > problems on Windows [*] when

Re: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F

2022-03-01 Thread Lance Andersen
On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although > it is an incompatible change, I believe it is worth the fix. For that, a CSR > has been drafted. I think the change makes sense. Are there any TCK tests that

Re: Should System.exit be controlled by a Scope Local?

2022-03-01 Thread Andrew Haley
On 2/28/22 15:32, Andrew Haley wrote: I think all we'd need is a set of capabilities bound to a scope local at thread startup, and I guess it'd default to "all capabilities". Trusted code could then override any of those capabilities. We'd have to make sure that capabilities were inherited by