Re: RFR 8153123 : Streamline StackWalker code

> On Apr 4, 2016, at 4:45 PM, Brent Christian > wrote: > > Hi, > > I'd like to check in some footprint and code reduction changes to the > java.lang.StackWalker implementation. > > Webrev: > http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ > Bug: >

RFR 8153123 : Streamline StackWalker code

Hi, I'd like to check in some footprint and code reduction changes to the java.lang.StackWalker implementation. Webrev: http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153123 A summary of the changes: * remove the

Re: RFR: 8151876: (tz) Support tzdata2016c

Looks good to me. But I'd like someone from java.time to review the changes to see if it's OK for java.time. Masayoshi On 4/4/2016 6:50 PM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA (tzdata2016c) integration to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, Stepping back just a bit. The old Cleaner running on the Reference processing thread had a few (2) very well controlled functions, reference processing and deallocating DirectByteBuffers. Maybe we can't do too much better than that. The old worst case performance/latency wise was

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hi Tagir, good catch! I like the proposal. > > (different longs can be converted into the same double, so DISTINCT is > not preserved here; not sure whether this is possible for ints) > I think IntStream.asDoubleStream() can also preserve DISTINCT as different ints can't be mapped to the same

RFR(XXS): 8149519: Investigate implementation of java.specification.version

Hi, can I please have a review for this small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 https://bugs.openjdk.java.net/browse/JDK-8149519 Currently the value of the java.specification.version property comes from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is

Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

On 04/04/2016 12:04, Erik Joelsson wrote: Makefile looks good. If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of libjava, should you also remove it from the mapfile for libjava? Yes, libjava/mapfile-vers will need to be updated too. It otherwise looks okay to me, just a

Re: RFR:JDK-8148849:Truncating Duration

Hi, I need one more review for this change Regards, Nadeesh On 3/30/2016 7:03 PM, Stephen Colebourne wrote: Yes, that looks OK now. thanks Stephen On 30 March 2016 at 12:25, nadeesh tv wrote: Hi Stephen, Thanks for the comments. Please see the updated webrev

Re: RFR:JDK-8148947:DateTimeFormatter pattern letter 'g'

Gentle reminder On 3/30/2016 11:41 PM, nadeesh tv wrote: Hi all, BUG ID : https://bugs.openjdk.java.net/browse/JDK-8148947 Webrev : http://cr.openjdk.java.net/~ntv/8148947/webrev.00/ Added new pattern letter 'g' for Modified Julian day. Apart from that made clarification to JulianFields

Re: RFR: jsr166 jdk9 integration wave 6

On 04/03/2016 06:17 PM, fo...@univ-mlv.fr wrote: De: "Martin Buchholz" http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ aka introducing a new constructor seems to be a regression to me, the less overloads we have the better

Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

Makefile looks good. If you move Java_sun_rmi_transport_GC_maxObjectInspectionAge out of libjava, should you also remove it from the mapfile for libjava? /Erik On 2016-04-04 12:26, Chris Hegarty wrote: [ including build-dev ] sun.misc.GC is not "Critical APIs", as defined by JEP 260, so

Re: RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

[ including build-dev ] sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native

RFR [9] 8153286: Move sun.misc.GC to java.rmi ( sun.rmi.transport )

sun.misc.GC is not "Critical APIs", as defined by JEP 260, so should be moved out of sun.misc and placed into a more appropriate package, where it can be encapsulated. Since GC is only used by RMI, I proposed to move it to the java.rmi module. Since it has a native component, and no other code

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

On 04/03/2016 03:51 AM, Claes Redestad wrote: > BufferedInputStream is loaded early, and uses > AtomicReferenceFieldUpdater to provide CAS functionality to allow for > closing streams asynchronously. Using Unsafe directly instead does > the exact same thing in the end, but avoids loading a few

RFR: 8151876: (tz) Support tzdata2016c

Hi all, Please review the latest TZDATA (tzdata2016c) integration to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ All the TimeZone related tests are passed after integration. Please note that this patch includes

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

On 03/04/16 21:39, Claes Redestad wrote: Thanks for looking at this, Alan! Cleaned things up here: http://cr.openjdk.java.net/~redestad/8153334/webrev.02/ Looks good Claes. -Chris.