Re: RFR: Some patches for sherman

Thanks, John. I need to adjust my expectations. The word "constant" means something different to hotspot engineers. I'm still hoping to someday simply say, "here's a final field - just go ahead and trust that it's truly final" On Fri, Mar 30, 2018 at 4:38 PM, John Rose

Re: RFR: More cleanup patches

On 3/31/18 12:29 AM, Martin Buchholz wrote: On Fri, Mar 30, 2018 at 4:31 AM, mandy chung > wrote: For this change, I am okay with most of the changes except I prefer the while loop to the for-loop with the local variable

Re: RFR: Some patches for sherman

On Fri, Mar 30, 2018 at 5:01 PM, Paul Sandoz wrote: > If the res field is non-volatile then is C2 already capable of hoisting > the field access out of the loop as if the result was assigned to a local > variable? > > final ZipFile z = … > final z_res = z.res; > while

Re: RFR: Some patches for sherman

If the res field is non-volatile then is C2 already capable of hoisting the field access out of the loop as if the result was assigned to a local variable? final ZipFile z = … final z_res = z.res; while (...) { use(z_res); } Paul. > On Mar 30, 2018, at 4:38 PM, John Rose

Re: RFR: Some patches for sherman

In short, Peter is right; sorry Martin. That annotation is private to java.base and not currently a feature that has support beyond its uses in java.base. The purpose of @Stable is to allow lazily evaluated variables (both static and non-static) to be constant-folded like static finals. In the

Re: Re: RFR: Some patches for sherman

The qualified people may not be reading this mailing list. Adding authors/reviewers of Stable.java. The question is whether in final ZipFile z = ... while (...) { use(z.res); } annotating instance field ZipFile.res as @Stable will enable the optimization of reading the res field only once.

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

Hi Raffaello, On Mar 30, 2018, at 2:57 PM, raffaello.giulie...@gmail.com wrote: >>> […] >>> >>> The new code also has a better specification than the current one, while >>> being mostly compatible. Indeed, the current specification leaves room >>> for interpretation and thus cannot ensure that

Re: RFR: More cleanup patches

Maybe I'm starting to understand. // attempt to load class in module defined to this loader assert loadedModule.loader() == this; return findClassInModuleOrNull(loadedModule, cn); Precondition of calling findClassInModuleOrNull is that loadedModule.loader() ==

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

Hi Brian, On 2018-03-30 22:42, Brian Burkhalter wrote: > Hello Raffaello, > > On Mar 30, 2018, at 9:50 AM, raffaello.giulie...@gmail.com > wrote: > >> the topic I would like to work on is to solve the bugs described at >>

Re: RFR: More cleanup patches

On Fri, Mar 30, 2018 at 3:53 AM, Alan Bateman wrote: > On 30/03/2018 02:55, Martin Buchholz wrote: > >> >> 8200125: Fix some classloader/module typos >> http://cr.openjdk.java.net/~martin/webrevs/jdk/loader-typos/ >> https://bugs.openjdk.java.net/browse/JDK-8200125 >> >

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

Thanks, Jon! On Mar 30, 2018, at 1:54 PM, Jonathan Gibbons wrote: > See > http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html > for the original.

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

On 03/30/2018 01:42 PM, Brian Burkhalter wrote: Per the JDK 11 schedule [5] there could well be sufficient time to run this submission through the review processes. I suggest, once your OCA has been processed, to proceed by posting your proposed changes for review on this mailing list. Note

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

Hello Raffaello, On Mar 30, 2018, at 9:50 AM, raffaello.giulie...@gmail.com wrote: > the topic I would like to work on is to solve the bugs described at > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4511638 about the > results produced by the current implementation of >

Re: RFR: 8195649: reorganize tests for java.util.Optional

Thanks. Regarding groups="unit" I wasn't entirely sure what to do about it. My first thought was that it's disused and to remove it, but then I looked and found that a bunch of other tests also declare themselves in the "unit" group: test/jdk/java/io/BufferedReader/Lines.java

Re: RFR: 8195649: reorganize tests for java.util.Optional

Very nice +1. You can probably remove the "groups = “unit”" from the @Test declarations. Paul. > On Mar 29, 2018, at 6:12 PM, Stuart Marks wrote: > > Hi all, > > Please review this changeset, which reorganizes (basically rewrites) the > tests for Optional and

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

On Fri, Mar 30, 2018 at 12:05 PM, Xueming Shen wrote: > > Hi David, > > (1) Deflater.setDictionary(ByteBuffer) missed a "@since 11" Oops, easy fix. > (2) infalte(...) may not need to catch DFE twice, better (?) to just update > the inputPos/input > at outsider

Re: RFR: 8200359: (tz) Upgrade time-zone data to tzdata2018d

Looks good. Naoto On 3/30/18 5:35 AM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA integration (tzdata2018d) into JDK11. Bug: https://bugs.openjdk.java.net/browse/JDK-8200359 Webrev: http://cr.openjdk.java.net/~rpatil/8200359/webrev.00/ All the TimeZone related tests are

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

Hi David, (1) Deflater.setDictionary(ByteBuffer) missed a "@since 11" (2) infalte(...) may not need to catch DFE twice, better (?) to just update the inputPos/input at outsider catch as if (input == null) this.inputPos = inputPos + inputConsumed; else

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

Thanks! On Fri, Mar 30, 2018 at 11:52 AM, Xueming Shen wrote: > On 3/30/18, 7:07 AM, Alan Bateman wrote: >> >> On 29/03/2018 13:18, David Lloyd wrote: >>> >>> : >>> OK great. In that case, I think all feedback has been accounted for, >>> and this should be ready to go

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

On 3/30/18, 7:07 AM, Alan Bateman wrote: On 29/03/2018 13:18, David Lloyd wrote: : OK great. In that case, I think all feedback has been accounted for, and this should be ready to go AFAIK. I skimmed through the patch attached to your last mail. I also saw Sherman's mail offering to look at

Clean-room implementation of Double::toString(double) and Float::toString(float)

Hi, the topic I would like to work on is to solve the bugs described at https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4511638 about the results produced by the current implementation of Double::toString(double). I noticed that after all these years most of the issues illustrated in the bug

Re: RFR: More cleanup patches

On Fri, Mar 30, 2018 at 4:55 AM, mandy chung wrote: > > > On 3/30/18 7:38 PM, Peter Levart wrote: > > > > On 03/30/2018 01:31 PM, mandy chung wrote: > > > > On 3/30/18 6:53 PM, Alan Bateman wrote: > > > > 8200134: Improve ModuleHashesBuilder >

Re: RFR: More cleanup patches

On Fri, Mar 30, 2018 at 4:31 AM, mandy chung wrote: > > For this change, I am okay with most of the changes except I prefer the > while loop to the for-loop with the local variable declaration. > I prefer the idiom with the declaration in the for loop ("keep variable

Re: [JDK-6341887] RFR: Patch V3: java.util.zip: Add ByteBuffer methods to Inflater/Deflater

On 29/03/2018 13:18, David Lloyd wrote: : OK great. In that case, I think all feedback has been accounted for, and this should be ready to go AFAIK. I skimmed through the patch attached to your last mail. I also saw Sherman's mail offering to look at the existing wording about the flush

RFR: 8200359: (tz) Upgrade time-zone data to tzdata2018d

Hi all, Please review the latest TZDATA integration (tzdata2018d) into JDK11. Bug: https://bugs.openjdk.java.net/browse/JDK-8200359 Webrev: http://cr.openjdk.java.net/~rpatil/8200359/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand.

Re: RFR: More cleanup patches

On 3/30/18 7:38 PM, Peter Levart wrote: On 03/30/2018 01:31 PM, mandy chung wrote: On 3/30/18 6:53 PM, Alan Bateman wrote: 8200134: Improve ModuleHashesBuilder http://cr.openjdk.java.net/~martin/webrevs/jdk/ModuleHashesBuilder/ https://bugs.openjdk.java.net/browse/JDK-8200134 I

Re: RFR: More cleanup patches

On 03/30/2018 01:31 PM, mandy chung wrote: On 3/30/18 6:53 PM, Alan Bateman wrote: 8200134: Improve ModuleHashesBuilder http://cr.openjdk.java.net/~martin/webrevs/jdk/ModuleHashesBuilder/ https://bugs.openjdk.java.net/browse/JDK-8200134 I suspect Mandy will want to look at this one. We

Re: RFR: More cleanup patches

On 3/30/18 6:53 PM, Alan Bateman wrote: 8200134: Improve ModuleHashesBuilder http://cr.openjdk.java.net/~martin/webrevs/jdk/ModuleHashesBuilder/ https://bugs.openjdk.java.net/browse/JDK-8200134 I suspect Mandy will want to look at this one. We also need to decide if there is a better place

Re: RFR: More cleanup patches

On 30/03/2018 02:55, Martin Buchholz wrote: 8199800: Optimize Boolean.parseBoolean(String) http://cr.openjdk.java.net/~martin/webrevs/jdk/Boolean-parseBoolean/ https://bugs.openjdk.java.net/browse/JDK-8199800 Looks okay. 8200364: Remove unnecessary boxing via primitive wrapper valueOf(String)

Re: RFR: More cleanup patches

Hi Martin, On 30/03/2018 02:55, Martin Buchholz wrote: 8200364: Remove unnecessary boxing via primitive wrapper valueOf(String) methods http://cr.openjdk.java.net/~martin/webrevs/jdk/valueOf-boxing/ https://bugs.openjdk.java.net/browse/JDK-8200364 The changes above look fine to me. I'll let

Fwd: Re: RFR: Some patches for sherman

I'm forwarding this private message to core-libs-dev so a qualified person may read it... Regards, Peter Forwarded Message Subject:Re: RFR: Some patches for sherman Date: Fri, 30 Mar 2018 06:18:26 + From: Peter Levart To: Martin