RFR: 8202473: A type variable with multiple bounds does not correctly place type annotation

2020-09-14 Thread Rafael Winterhalter
This patch assures that an annotation on a type bound is placed on the correct bound index. - Commit messages: - 8202473: A type variable with multiple bounds does not correctly place type annotation Changes: https://git.openjdk.java.net/jdk/pull/155/files Webrev:

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

2020-09-14 Thread David Holmes
On 14/09/2020 6:18 pm, Richard Reingruber wrote: On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes wrote: Hi, this is the continuation of the review of the implementation for: https://bugs.openjdk.java.net/browse/JDK-8227745 https://bugs.openjdk.java.net/browse/JDK-8233915 It allows for JIT

Re: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

2020-09-14 Thread Joe Wang
On Mon, 14 Sep 2020 23:15:10 GMT, Naoto Sato wrote: >> Thanks, Lance, >> >>> The change looks fine. I might have created a CSR just to track the doc >>> change. >> >> Yes, and thanks for the CSR review too! > > Thanks, Joe. > >> The change looks fine. However, are other methods in the same

Re: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

2020-09-14 Thread Joe Wang
On Mon, 14 Sep 2020 22:18:34 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/159

Re: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

2020-09-14 Thread Naoto Sato
On Mon, 14 Sep 2020 22:52:50 GMT, Joe Wang wrote: >> Hi Naoto, >> >> The change looks fine. I might have created a CSR just to track the doc >> change. > > The change looks fine. However, are other methods in the same situation, e.g. > void setTimeZone​(TimeZone value), > getInstance​(Locale

Re: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

2020-09-14 Thread Naoto Sato
On Mon, 14 Sep 2020 23:13:25 GMT, Naoto Sato wrote: >> The change looks fine. However, are other methods in the same situation, >> e.g. void setTimeZone​(TimeZone value), >> getInstance​(Locale aLocale), etc.? Or, would it better to add a general >> statement about passing in null values? > >

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

2020-09-14 Thread Lance Andersen
Hi Joe, Ok, will create one tomorrow. Best Lance > On Sep 14, 2020, at 7:07 PM, Joe Darcy wrote: > > Hi Lance, > > I'd prefer to err on the side of having a CSR; thanks, > > -Joe > > On 9/14/2020 3:55 PM, Lance Andersen wrote: >> Hi Joe, >> >> I guess it could. Given it is not used

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

2020-09-14 Thread Joe Darcy
Hi Lance, I'd prefer to err on the side of having a CSR; thanks, -Joe On 9/14/2020 3:55 PM, Lance Andersen wrote: Hi Joe, I guess it could.  Given it is not used within the implementation(or defined outside of the spec), I will defer to you preference  :-) On Sep 14, 2020, at 6:49 PM, Joe

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v2]

2020-09-14 Thread Ian Graves
On Mon, 14 Sep 2020 22:03:02 GMT, Mandy Chung wrote: >> Ian Graves has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Merging streams > > Looks good to me. Updated to merge streams in line with @stuart-marks suggestion. -

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

2020-09-14 Thread Lance Andersen
Hi Joe, I guess it could. Given it is not used within the implementation(or defined outside of the spec), I will defer to you preference :-) > On Sep 14, 2020, at 6:49 PM, Joe Darcy wrote: > > Should issue have a CSR review for the behavior change? > > -Joe > > On 9/12/2020 7:25 PM,

Re: RFR: 8252730: jlink does not create reproducible builds on different servers [v2]

2020-09-14 Thread Ian Graves
> Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces > ordering based on `Archive` module names to > ensure stable files (and file signatures) across generated JDK images by > jlink. Ian Graves

Re: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

2020-09-14 Thread Joe Wang
On Mon, 14 Sep 2020 22:41:55 GMT, Lance Andersen wrote: >> Hi, >> >> Please review this simple doc fix. > > Hi Naoto, > > The change looks fine. I might have created a CSR just to track the doc > change. The change looks fine. However, are other methods in the same situation, e.g. void

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

2020-09-14 Thread Joe Darcy
Should issue have a CSR review for the behavior change? -Joe On 9/12/2020 7:25 PM, Jaikiran Pai wrote: On Sat, 12 Sep 2020 17:38:34 GMT, Lance Andersen wrote: Can I please get a review and a sponsor for this patch which fixes the issue reported in

Re: RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

2020-09-14 Thread Lance Andersen
On Mon, 14 Sep 2020 22:18:34 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Hi Naoto, The change looks fine. I might have created a CSR just to track the doc change. - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/159

RFR: 8220483: Calendar.setTime(Date date) throws NPE with Date date = null

2020-09-14 Thread Naoto Sato
Hi, Please review this simple doc fix. - Commit messages: - 8220483: Calendar.setTime(Date date) throws NPE with Date date = null Changes: https://git.openjdk.java.net/jdk/pull/159/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=159=00 Issue:

Re: RFR: 8252730: jlink does not create reproducible builds on different servers

2020-09-14 Thread Mandy Chung
On Mon, 14 Sep 2020 20:35:24 GMT, Ian Graves wrote: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces > ordering based on `Archive` module names to > ensure stable files (and file signatures)

Re: RFR: JDK-8230652: Improve verbose output

2020-09-14 Thread Alexander Matveev
On Sat, 12 Sep 2020 18:30:08 GMT, Andy Herrick wrote: > JDK-8230652 > Extracting the commands displayed by verbose output (including commands > called thru ToolProvider) , to contain the the > command, it's output, and it's return value on separate lines and formatted > in a way that they can

Re: RFR: 8252730: jlink does not create reproducible builds on different servers

2020-09-14 Thread Ian Graves
On Mon, 14 Sep 2020 21:32:19 GMT, Stuart Marks wrote: >> Related to [JDK-8252730 jlink does not create reproducible builds on >> different >> servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces >> ordering based on `Archive` module names to >> ensure stable files (and file

Re: RFR: 8252730: jlink does not create reproducible builds on different servers

2020-09-14 Thread Stuart Marks
On Mon, 14 Sep 2020 20:35:24 GMT, Ian Graves wrote: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces > ordering based on `Archive` module names to > ensure stable files (and file signatures)

Re: Fwd: RFR: 8223187: Investigate setLocale() call in jpackage native launcher

2020-09-14 Thread alexander . matveev
Hi Bernd, Not sure if we should enforce English version of error messages on non-English locale. I think user will expect messages in system locale if possible. User can change system locale to English if English version of error messages are required to submit something like bug report.

Integrated: 8223187: Remove setLocale() call in jpackage native launcher

2020-09-14 Thread Alexander Matveev
On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev wrote: > setlocale() affects several C functions. We do not use most of these > functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing > it I retested jpackage by

RFR: 8252730: Ordering modules to guarantee repeatable jlink image writes

2020-09-14 Thread Ian Graves
Related to [JDK-8252730 jlink does not create reproducible builds on different servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces ordering based on `Archive` module names to ensure stable files (and file signatures) across generated JDK images by jlink. - Commit

Re: RFR: 8252537: Updated @exception with @throws

2020-09-14 Thread Roger Riggs
On Wed, 9 Sep 2020 19:29:30 GMT, Vipin Sharma wrote: > Updated @exception with @throws for core-libs, it fixes all open sub-tasks of > JDK-8252536. > > Open Subtasks part of this fix are: > 1. JDK-8252537 > 2. JDK-8252539 > 3. JDK-8252540 > 4. JDK-8252541 > > Previous conversation on this: >

Re: RFR: 8251397: NPE on ClassValue.ClassValueMap.cacheArray [v2]

2020-09-14 Thread Severin Gehwolf
On Mon, 14 Sep 2020 14:33:34 GMT, Galder Zamarreño wrote: >> @galderz Hmm, sorry. Apparently it's the PR title which makes up the >> synopsis. Probably has to be changed in the UI >> here. I didn't know that :( > > PR title changed... @galderz OK. Lets try the integrate/sponsor workflow.

Re: RFR: 8223187: Investigate setLocale() call in jpackage native launcher

2020-09-14 Thread Naoto Sato
On Sat, 12 Sep 2020 02:15:29 GMT, Alexander Matveev wrote: > setlocale() affects several C functions. We do not use most of these > functions. We only using isspace() and toLower(). > Based on how we use it I do not see any needs for setlocale(). After removing > it I retested jpackage by

Re: RFR: JDK-8230652: Improve verbose output

2020-09-14 Thread Alexey Semenyuk
On Sat, 12 Sep 2020 18:30:08 GMT, Andy Herrick wrote: > JDK-8230652 > Extracting the commands displayed by verbose output (including commands > called thru ToolProvider) , to contain the the > command, it's output, and it's return value on separate lines and formatted > in a way that they can

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

2020-09-14 Thread Richard Reingruber
On Mon, 14 Sep 2020 04:58:47 GMT, David Holmes wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape

Re: RFR: 8251397: NPE on ClassValue.ClassValueMap.cacheArray [v2]

2020-09-14 Thread Galder Zamarreño
On Mon, 14 Sep 2020 13:09:11 GMT, Severin Gehwolf wrote: >> Add release fence to ClassValueMap constructor. >> >> * Release fence guarantees that cacheArray field will published >> with a non-null value. >> * Without this fix, CacheValueMap.cacheArray can sometimes be >>seen as null. > >

Re: RFR: 8251397: Add release fence to ClassValueMap constructor [v2]

2020-09-14 Thread Severin Gehwolf
On Mon, 14 Sep 2020 12:59:00 GMT, Galder Zamarreño wrote: >> Note that I've opened >> [SKARA-633](https://bugs.openjdk.java.net/browse/SKARA-633) for >> pre-population of the commit >> message with an appropriate summary. > > Add release fence to ClassValueMap constructor. > > * Release

Re: RFR: 8251397: Add release fence to ClassValueMap constructor [v2]

2020-09-14 Thread Galder Zamarreño
> * Release fence guarantees that cacheArray field will published with a > non-null value. > * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null. > > This is a follow up to @PaulSandoz's feedback >

Re: RFR: 8251397: Add release fence to ClassValueMap constructor [v2]

2020-09-14 Thread Galder Zamarreño
On Mon, 14 Sep 2020 12:04:30 GMT, Severin Gehwolf wrote: >> @galderz Now it's the other way round. Commit message the bot mentions >> [here](https://github.com/openjdk/jdk/pull/94#issuecomment-691478179) should >> be something like this: >> 8251397: NPE on ClassValue.ClassValueMap.cacheArray >>

Re: RFR: 8245194: Unix domain socket channel implementation [v4]

2020-09-14 Thread Michael McMahon
> Continuing this review as a PR on github with the comments below > incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to

Re: RFR: 8251397: Add release fence to ClassValueMap constructor

2020-09-14 Thread Severin Gehwolf
On Mon, 14 Sep 2020 08:25:51 GMT, Severin Gehwolf wrote: >> @galderz The PR has this synopsis `8251397: Add release fence to >> ClassValueMap constructor`. The bug has this `8251397: >> NPE on ClassValue.ClassValueMap.cacheArray`. @dholmes-ora asked to make them >> matching. Let's fix that

Re: RFR: 8251397: Add release fence to ClassValueMap constructor

2020-09-14 Thread Severin Gehwolf
On Mon, 14 Sep 2020 12:02:14 GMT, Severin Gehwolf wrote: >> You can add what you have as synopsis now via /summary and the bot. > > @galderz Now it's the other way round. Commit message the bot mentions > [here](https://github.com/openjdk/jdk/pull/94#issuecomment-691478179) should > be

Re: RFR: 8245194: Unix domain socket channel implementation [v3]

2020-09-14 Thread Michael McMahon
> Continuing this review as a PR on github with the comments below > incorporated. I expect there will be a few more > iterations before integrating. > On 06/09/2020 19:47, Alan Bateman wrote: >> On 26/08/2020 15:24, Michael McMahon wrote: >>> >>> As I mentioned the other day, I wasn't able to

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char)

2020-09-14 Thread Andrew Haley
On 12/09/2020 00:06, Jason Tatton wrote: > The current indexOf char intrinsics for StringUTF16 and the new one > here for StringLatin1 both use the AVX2 – i.e. 256 bit instructions, > these are also affected by the frequency scaling which affects the > AVX-512 instructions you pointed out. Of

Re: RFR: 8251397: Add release fence to ClassValueMap constructor

2020-09-14 Thread Severin Gehwolf
On Mon, 14 Sep 2020 08:03:51 GMT, Galder Zamarreño wrote: >> Please ensure the PR title and the bug synopsis match before this in >> integrated! >> >> Please DO NOT force-push updates as you lose the history of commits and >> anyone following this cannot see what changes >> were actually

Re: RFR: 8251397: Add release fence to ClassValueMap constructor

2020-09-14 Thread Severin Gehwolf
On Mon, 14 Sep 2020 08:24:15 GMT, Severin Gehwolf wrote: >> Are you expecting anything else from me? @jerboaa already proposed as >> sponsor above. > > @galderz The PR has this synopsis `8251397: Add release fence to > ClassValueMap constructor`. The bug has this `8251397: > NPE on

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

2020-09-14 Thread Richard Reingruber
On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape

Re: RFR: 8251397: Add release fence to ClassValueMap constructor

2020-09-14 Thread Galder Zamarreño
On Mon, 14 Sep 2020 02:56:43 GMT, David Holmes wrote: >> @galderz We'll have to wait until somebody marks your github handle as OCA >> approved or some such :-/ > > Please ensure the PR title and the bug synopsis match before this in > integrated! > > Please DO NOT force-push updates as you

Re: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2]

2020-09-14 Thread Aleksei Voitylov
On Mon, 14 Sep 2020 04:18:39 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > Marked as reviewed by dholmes (Reviewer). thank you

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

2020-09-14 Thread David Holmes
On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape