Re: JDK 9 RFR of 8032397: Remove sun.misc.Ref

2014-01-22 Thread Alan Bateman
On 22/01/2014 01:17, Joe Darcy wrote: Hi Alan, Updated webrev at http://cr.openjdk.java.net/~darcy/8032397.1/ @see in sun.misc.Ref removed. Regression tests updated to not refer to sun.misc.Ref. I looked at the use of Ref in jhat and it is only used if java.lang.ref.Reference is not

hg: jdk8/tl/jdk: 8032217: failure in man page processing

2014-01-22 Thread erik . joelsson
Changeset: ff56039c4870 Author:erikj Date: 2014-01-22 12:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff56039c4870 8032217: failure in man page processing Reviewed-by: dholmes, tbell ! make/Images.gmk

Re: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.

2014-01-22 Thread Alexander Zuev
Kumar, see my notes inline. On 1/21/14 20:11, Kumar Srinivasan wrote: Alex, Thanks for adding the test, few comments: PackTestZip64.java: 1. compareTwoFile, I would read the entire file into ByteArrayInputStream, compare the total first ie. fast fail, but what you have is also ok. I've

Re: JEP 187: Serialization 2.0

2014-01-22 Thread Florian Weimer
On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/187 There's another aspect of the current approach to serialization that is not mentioned: the type information does not come from the calling context, but exclusively from the input stream. This

Re: JEP 187: Serialization 2.0

2014-01-22 Thread Chris Hegarty
On 22/01/14 13:57, Florian Weimer wrote: On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/187 There's another aspect of the current approach to serialization that is not mentioned: the type information does not come from the calling context, but

Re: JEP 187: Serialization 2.0

2014-01-22 Thread Florian Weimer
On 01/22/2014 03:47 PM, Chris Hegarty wrote: On 22/01/14 13:57, Florian Weimer wrote: On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/187 There's another aspect of the current approach to serialization that is not mentioned: the type information

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

2014-01-22 Thread Paul Sandoz
On Jan 21, 2014, at 11:05 PM, Xueming Shen xueming.s...@oracle.com wrote: Hi Paul, thanks for reviewing the changeset, comment inlined below. On 01/20/2014 09:24 AM, Paul Sandoz wrote: Some quick comments. In String.toLowerCase: - it would be nice to get rid of the pseudo goto using

Re: JEP 187: Serialization 2.0 Serialization-aware constructors

2014-01-22 Thread David M. Lloyd
On 01/13/2014 06:26 PM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/187 The concept of explicit deserialization constructors is interesting and is something I've explored a little bit in the context of JBoss Marshalling. The way construction works today (simple

Re: RFR: 8030822: (tz) Support tzdata2013i

2014-01-22 Thread Seán Coffey
Looks good to me Aleksej. Hopefully you can get a reviewer from the i18n dev team also. regards, Sean. On 21/01/14 13:17, Aleksej Efimov wrote: Hi, Can I have a review for 2013i timezone data integration [1] to JDK9. There is one change in tzdb that affects naming for Asia/Amman timezone:

Re: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.

2014-01-22 Thread Kumar Srinivasan
Alex, I am satisfied. Thanks Kumar Kumar, see my notes inline. On 1/21/14 20:11, Kumar Srinivasan wrote: Alex, Thanks for adding the test, few comments: PackTestZip64.java: 1. compareTwoFile, I would read the entire file into ByteArrayInputStream, compare the total first ie. fast

RFR JDK 9: 8032502: java.time add @param tags to readObject

2014-01-22 Thread roger riggs
Please review this javadoc improvement to add @param tags to readObject Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ Thanks, Roger

Re: RFR JDK 9: 8032502: java.time add @param tags to readObject

2014-01-22 Thread Lance Andersen - Oracle
looks fine Roger as am sure this will make the doclint warnings less On Jan 22, 2014, at 4:26 PM, roger riggs wrote: Please review this javadoc improvement to add @param tags to readObject Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ Thanks, Roger Lance

Re: RFR JDK 9: 8032502: java.time add @param tags to readObject

2014-01-22 Thread Joe Darcy
On 01/22/2014 01:26 PM, roger riggs wrote: Please review this javadoc improvement to add @param tags to readObject Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ Thanks, Roger Hi Roger, I'll approve this if you either * replace codeObjectInputStream/code with

Aw: JEP 187: Serialization 2.0 Serialization-aware constructors

2014-01-22 Thread Robert Stupp
Am 22.01.2014 um 17:33 schrieb David M. Lloyd david.ll...@redhat.com: The concept of explicit deserialization constructors is interesting and is something I've explored a little bit in the context of JBoss Marshalling. ... The idea with a serialization-aware constructor is that each

Re: RFR JDK 9: 8032502: java.time add @param tags to readObject

2014-01-22 Thread roger riggs
Thanks for the reminder Joe, I updated the webrev with the 2nd, shorter version. Roger On 1/22/2014 4:33 PM, Joe Darcy wrote: On 01/22/2014 01:26 PM, roger riggs wrote: Please review this javadoc improvement to add @param tags to readObject Webrev:

(7u backport) RFR: 7199674 - (props) user.home property does not return an accessible location in sandboxed environment [macosx]

2014-01-22 Thread Brent Christian
Hi, I would like to backport this fix from 8 to 7u. https://bugs.openjdk.java.net/browse/JDK-7199674 The source code changes apply cleanly to 7u from the 8 changeset, however the makefile changes needed to be tweaked. makefiles/CompileNativeLibraries.gmk did not exist in 7, so equivalent

Re: RFR JDK 9: 8032502: java.time add @param tags to readObject

2014-01-22 Thread Joe Darcy
On 01/22/2014 01:39 PM, roger riggs wrote: Thanks for the reminder Joe, I updated the webrev with the 2nd, shorter version. Ship it :-) -Joe Roger On 1/22/2014 4:33 PM, Joe Darcy wrote: On 01/22/2014 01:26 PM, roger riggs wrote: Please review this javadoc improvement to add @param tags

Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement

2014-01-22 Thread Ulf Zibis
Am 22.01.2014 16:20, schrieb Paul Sandoz: On Jan 21, 2014, at 11:05 PM, Xueming Shen xueming.s...@oracle.com wrote: On 01/20/2014 09:24 AM, Paul Sandoz wrote: - it would be nice to get rid of the pseudo goto using the scan labelled block. webrev has been updated to remove the pseudo goto by

Re: ObjectIn/OutputStream improvements

2014-01-22 Thread Robert Stupp
I found another location in OOS code that might be an optimization point: In java.io.ObjectOutputStream.BlockDataOutputStream#write(byte[], int, int, boolean) the first lines look like this: if (!(copy || blkmode)) { // write directly drain();

Which optimizations does Hotspot apply?

2014-01-22 Thread Robert Stupp
Is there any documentation available which optimizations Hotspot can perform and what collecting a garbage object costs? I know that these are two completely different areas ;) I was inspecting whether the following code for (Object o : someArrayList) { ... } would be faster than for

(7u backport) RFR: 7199674 - (props) user.home property does not return an accessible location in sandboxed environment [macosx]

2014-01-22 Thread Brent Christian
(forgot to include macosx-port-...@openjdk.java.net) Hi, I would like to backport this fix from 8 to 7u. https://bugs.openjdk.java.net/browse/JDK-7199674 The source code changes apply cleanly to 7u from the 8 changeset, however the makefile changes needed to be tweaked.

Re: Which optimizations does Hotspot apply?

2014-01-22 Thread Vitaly Davidovich
You can start here: wikis.oracle.com/display/hotspotinternals/performancetechniques Sent from my phone On Jan 22, 2014 5:37 PM, Robert Stupp sn...@snazy.de wrote: Is there any documentation available which optimizations Hotspot can perform and what collecting a garbage object costs? I know

Re: JDK 9 RFR of 8032397: Remove sun.misc.Ref

2014-01-22 Thread Mandy Chung
On 1/21/2014 5:17 PM, Joe Darcy wrote: Hi Alan, Updated webrev at http://cr.openjdk.java.net/~darcy/8032397.1/ Looks good to me. @see in sun.misc.Ref removed. Regression tests updated to not refer to sun.misc.Ref. I looked at the use of Ref in jhat and it is only used if

Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9

2014-01-22 Thread Vladimir Kozlov
I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 to latest ppc64 sources: http://hg.openjdk.java.net/ppc-aix-port/stage-9 I have build failure on Mac OS X (on other platforms it passed). See the output below. I

hg: jdk8/tl/jdk: 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID

2014-01-22 Thread sean . mullan
Changeset: 57c26829deb6 Author:mullan Date: 2014-01-22 19:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57c26829deb6 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Reviewed-by: vinnie, xuelei !

Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9

2014-01-22 Thread Henry Jen
I haven't tried this, but Tim Bell mentioned this in an email inquiry I had earlier, This will be cured when the fix for 8021266 is pushed to JDK 9 (see attached). In the meantime, the workaround in JPRT is to submit your JDK 9 jobs with '-bootproduct jdk7u7' since the 7u51 release can not

Re: Which optimizations does Hotspot apply?

2014-01-22 Thread Vitaly Davidovich
Remi, Regarding your last point - picking correct data structures and algos is of course step 1 in any optimization. But, provided that's taken care of, there're plausible reasons to attempt to cater to hotspot as well (if that's the jvm in use). There are certainly code shapes that it prefers.

Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9

2014-01-22 Thread Vladimir Kozlov
Thank you very much, Henry The suggested workaround helped! Thanks, Vladimir On 1/22/14 4:18 PM, Henry Jen wrote: I haven't tried this, but Tim Bell mentioned this in an email inquiry I had earlier, This will be cured when the fix for 8021266 is pushed to JDK 9 (see attached). In the

Re: i18n dev RFR: 8030822: (tz) Support tzdata2013i

2014-01-22 Thread Masayoshi Okutsu
Hi Aleksej, I think this one is the first tzdata change for JDK9. So I'd suggest that all the TimeZoneNames*.properties files, which were temporarily created for the translation work, be removed. Thanks, Masayoshi On 1/21/2014 10:17 PM, Aleksej Efimov wrote: Hi, Can I have a review for