Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Sure, here's a new webrev: http://cr.openjdk.java.net/~shade/8148936/webrev.02/ Cheers, -Aleksey On 02/04/2016 02:34 PM, Ivan Gerasimov wrote: > Hi Aleksey! > > Looks good to me! > > Two minorish comments > > 1) > 431 formatUnsignedLong0(lsb >> 48, 4, buf, 19, 4); > I would

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Looks even better, thanks! Sincerely yours, Ivan On 04.02.2016 14:54, Aleksey Shipilev wrote: Sure, here's a new webrev: http://cr.openjdk.java.net/~shade/8148936/webrev.02/ Cheers, -Aleksey On 02/04/2016 02:34 PM, Ivan Gerasimov wrote: Hi Aleksey! Looks good to me! Two minorish

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Hi Aleksey! Looks good to me! Two minorish comments 1) 431 formatUnsignedLong0(lsb >> 48, 4, buf, 19, 4); I would suggest using unsigned shift >>> here just to avoid thinking about whether the sign matters or not. Not a big deal, of course. 2) Do you want to add the bug id

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Hi Aleksey, On 2016-02-04 12:54, Aleksey Shipilev wrote: Sure, here's a new webrev: http://cr.openjdk.java.net/~shade/8148936/webrev.02/ +1 Long::fastUUID feels odd, but I see why you ended up with that. Perhaps add a javadoc with a reference to the method in UUID that uses it? I can't

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 02/02/2016 07:25 PM, Mikael Vidstedt wrote: > Please review this change which introduces a Copy::conjoint_swap and an > Unsafe.copySwapMemory method to call it from Java, along with the > necessary changes to have java.nio.Bits call it instead of the Bits.c code. > >

Re: RFR: 8072777: java/lang/ref/ReferenceEnqueuePending.java: some references aren't queued

> On Feb 4, 2016, at 3:38 PM, Mandy Chung wrote: > > >> On Feb 1, 2016, at 4:05 PM, Kim Barrett wrote: >> >>> But this could be an opportunity to also clean-up the code a bit. The >>> checkResult method has an 'obj' parameter whose purpose is

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 2016-02-04 04:22, Andrew Haley wrote: On 02/02/2016 07:25 PM, Mikael Vidstedt wrote: Please review this change which introduces a Copy::conjoint_swap and an Unsafe.copySwapMemory method to call it from Java, along with the necessary changes to have java.nio.Bits call it instead of the

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 5/02/2016 4:34 AM, Roger Riggs wrote: Hi Stuart, On 2/3/2016 5:32 PM, Stuart Marks wrote: On 2/2/16 7:05 PM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: It will be good to get this into the JDK. Lots of people have been asking for this. I think this API is a big

Re: JDK-8052260 (Reference.isEnqueued()) Discussion

> On Feb 4, 2016, at 2:37 PM, Hans Boehm wrote: > > The discussion at https://bugs.openjdk.java.net/browse/JDK-8052260 > correctly points out that the spec implies that this should be true if the > reference has ever been enqueued, while the implementation returns false >

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

On 2/4/16 5:05 PM, David Holmes wrote: The initial task was to provide a replacement for sun.misc.Signal. Sun.misc.Signal provides to Java the same set of signals the VM is able to handle and exposes via the JVM_findSignal, JVM_RegisterSignal, and JVM_RaiseSignal. The VM carefully handles the

Re: RFR 8138578:MethodHandles.Lookup.findSpecial() Javadoc fails to consider static methods

Gentle reminder! On 1/29/2016 6:13 PM, shilpi rastogi wrote: Hi All, Please review the updated patch- http://cr.openjdk.java.net/~srastogi/8138578/webrev.01/ I verified Lookup.unreflectSpecial() also throws java.lang.IllegalAccessException so updated the JavaDoc. Thanks, Shilpi

RFR: 8071368 Use more concrete types for NamedFunction constants in the code

Hi All, Please review the following- https://bugs.openjdk.java.net/browse/JDK-8071368 http://cr.openjdk.java.net/~srastogi/8071368/webrev.02/ Thanks, Shilpi

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Hi, Looking at the webrev it seems that the Javadoc for Long.formatUnsignedLong has not been removed. Regards, Florent On Thu, Feb 4, 2016 at 2:04 PM, Aleksey Shipilev < aleksey.shipi...@oracle.com> wrote: > Thanks guys, pushed. > Now, on to StringJoiner... > > -Aleksey > > On 02/04/2016

Re: RFR: 8148928: java/util/stream/test/**/SequentialOpTest.java timed out intermittently

> On 4 Feb 2016, at 03:18, Hamlin Li wrote: > > Hi everyone, > > Would you please help to review the fix for bug > https://bugs.openjdk.java.net/browse/JDK-8148928, > java/util/stream/test/**/SequentialOpTest.java timed out intermittently. > webrev:

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

Thanks guys, pushed. Now, on to StringJoiner... -Aleksey On 02/04/2016 03:10 PM, Ivan Gerasimov wrote: > Looks even better, thanks! > > Sincerely yours, > Ivan > > On 04.02.2016 14:54, Aleksey Shipilev wrote: >> Sure, here's a new webrev: >>

Re: RFR:JDK-8146747:java.time.Duration.toNanos() and toMillis() exception on negative durations

Hi, There is no problem. Thank you for the fix! shinyafox(Shinya Yoshida) 2016/02/04 14:28 "nadeesh tv" : > > Hi all, > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8146747/webrev.01/ > Regards, > Nadeesh > On 2/3/2016 5:48 PM, nadeesh tv wrote: > >>

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

> On Feb 4, 2016, at 5:05 PM, David Holmes wrote: > > Java hasn't needed a public signal handling API for the last 20 years. It's > only getting one now because modularity is forcing us to cut-off > sun.misc.Signal from the few use-cases that do need it. And we now

Re: RFR (S) 8148936: Adapt UUID.toString() to Compact Strings

On 02/04/2016 04:29 PM, Florent Guillaume wrote: > Looking at the webrev it seems that the Javadoc for > Long.formatUnsignedLong has not been removed. There are two following methods that are related to that Javadoc. But I agree, these should be cleaned up along with other *Latin1/*UTF16 methods

Re: RFR-8148748: ArrayList.subList().spliterator() is not late-binding

Hello! Thank you for clarification. As far as I know currently JIT-compiled null checks are almost always implicit (via trapped page-fault). Well, ok, I'm not a Hotspot expert (probably for C1 this still matters). I will keep this code as is. Webrev was not changed:

Re: RFR (XS) (urgent) 8149044: jdk/internal/misc/JavaLangAccess/FormatUnsigned.java fails all platforms

HI Aleksey, Looks fine. I assume any remaining JavaLangAccess have other tests :-) Thanks, -Joe On 2/4/2016 10:29 AM, Aleksey Shipilev wrote: Hi, jdk/internal/misc/JavaLangAccess/FormatUnsigned.java started failing after UUID.toString() optimizations purged the methods from JavaLangAccess:

Re: RFR 9: 8087286 Need a way to handle control-C and possibly some other signals

Hi Stuart, On 2/3/2016 5:32 PM, Stuart Marks wrote: On 2/2/16 7:05 PM, David Holmes wrote: On 3/02/2016 8:08 AM, Stuart Marks wrote: It will be good to get this into the JDK. Lots of people have been asking for this. I think this API is a big mistake. The primary usecase seems to be

RFR (XS) (urgent) 8149044: jdk/internal/misc/JavaLangAccess/FormatUnsigned.java fails all platforms

Hi, jdk/internal/misc/JavaLangAccess/FormatUnsigned.java started failing after UUID.toString() optimizations purged the methods from JavaLangAccess: https://bugs.openjdk.java.net/browse/JDK-8149044 My bad, I should have ran JavaLangAccess tests after the original change. The fix is to remove

Re: RFR (XS) (urgent) 8149044: jdk/internal/misc/JavaLangAccess/FormatUnsigned.java fails all platforms

Thanks for a quick review, Joe! Pushed. -Aleksey On 02/04/2016 09:32 PM, joe darcy wrote: > HI Aleksey, > > Looks fine. I assume any remaining JavaLangAccess have other tests :-) > > Thanks, > > -Joe > > On 2/4/2016 10:29 AM, Aleksey Shipilev wrote: >> Hi, >> >>

Re: RFR: 8072777: java/lang/ref/ReferenceEnqueuePending.java: some references aren't queued

> On Feb 1, 2016, at 4:05 PM, Kim Barrett wrote: > >> But this could be an opportunity to also clean-up the code a bit. The >> checkResult method has an 'obj' parameter whose purpose is not immediately >> obvious. […] >> >> I don't know why such complications are

RE: RFR: 8148446: (tz) Support tzdata2016a

Hi Masayoshi/all, Please review the updated Webrev at: http://cr.openjdk.java.net/~rpatil/8148446/webrev.01/ Regards, Ramanand. -Original Message- From: Masayoshi Okutsu Sent: Thursday, February 04, 2016 12:17 PM To: Ramanand Patil; i18n-...@openjdk.java.net Cc: