Re: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

2014-01-16 Thread Jochen Theodorou
Hi, since I am indirectly the reporter of this bug I have one remark for the test. The error happens only for compiled lambda forms. The given test does imho not use a compiled lambda form. In other words, afaik the test would pass without the fix. As such it would be useless as regression

Re: RFR 8031961 ProcessBuilder.Basic should use NIO Files to copy files

2014-01-16 Thread Alan Bateman
On 16/01/2014 03:22, Roger Riggs wrote: Please review this minor test improvement to replace spawning /bin/cp to copy files with NIO Files.copy. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-process-cp-8031961/ Just looking at JDK-6686751 and it's not clear what the issue was with -p. I

Re: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

2014-01-16 Thread A. Sundararajan
The test sets compile threshold to be zero (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 ). I think compilation occurs on the first invoke. Also, I ran the test on a jdk8 build without Vladimir's fix - I saw the exception being thrown. I ran it by passing the above option in the

Re: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

2014-01-16 Thread Jochen Theodorou
Am 16.01.2014 09:48, schrieb A. Sundararajan: The test sets compile threshold to be zero (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 ). I think compilation occurs on the first invoke. Also, I ran the test on a jdk8 build without Vladimir's fix - I saw the exception being thrown. I ran

Re: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

2014-01-16 Thread Vladimir Ivanov
Jochen, The test provokes the bug, since it sets compilation threshold to 0: -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 Best regards, Vladimir Ivanov On 1/16/14 12:40 PM, Jochen Theodorou wrote: Hi, since I am indirectly the reporter of this bug I have one remark for the test. The

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-16 Thread Volker Simonis
On Wed, Jan 15, 2014 at 12:05 PM, Volker Simonis volker.simo...@gmail.comwrote: On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman alan.bate...@oracle.comwrote: On 15/01/2014 06:24, David Holmes wrote: I'm not a fan of runtime checks of this kind though if it is only a very samll number of

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-16 Thread Alan Bateman
On 16/01/2014 09:38, Volker Simonis wrote: Hi Alan, I think sun.nio.ch.IOUtil seems even more appropriate to me for these constants. What do you think? Would it be OK for you if I initialize them right in the static initializer of IOUtil based on os.name http://os.name or do you prefer

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-16 Thread Volker Simonis
On Thu, Jan 16, 2014 at 11:05 AM, Alan Bateman alan.bate...@oracle.com wrote: On 16/01/2014 09:38, Volker Simonis wrote: Hi Alan, I think sun.nio.ch.IOUtil seems even more appropriate to me for these constants. What do you think? Would it be OK for you if I initialize them right in the

Re: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

2014-01-16 Thread Paul Sandoz
On Jan 10, 2014, at 2:42 PM, Paul Sandoz paul.san...@oracle.com wrote: I have also removed the inconsistently applied synchronized block. Either we apply it consistently to reporting or not at all. It was originally there because we were not sure that the happens-before relationship [1]

Re: RFR 8031961 ProcessBuilder.Basic should use NIO Files to copy files

2014-01-16 Thread roger riggs
Hi Alan, I suspect that Solaris didn't support -p (as per the comment) but it was not worth a lot of investigation for an old issue and old SE 6. Roger On 1/16/2014 3:45 AM, Alan Bateman wrote: On 16/01/2014 03:22, Roger Riggs wrote: Please review this minor test improvement to replace

Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN

2014-01-16 Thread Paul Sandoz
On Jan 15, 2014, at 10:28 PM, Brian Burkhalter brian.burkhal...@oracle.com wrote: Issue:https://bugs.openjdk.java.net/browse/JDK-6667086 Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/ According to micro-benckmarks, there is no statistically significant performance

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

2014-01-16 Thread Alexander Zuev
Sherman, Kumar, i have fixed the glitches you have found and changed the test so it creates a new jar based on the golden.jar content (to have a reasonable set of various data to start with), then adding to it 65536 empty files to test how we cope with such a huge jars. The testing time

Re: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources

2014-01-16 Thread Paul Sandoz
On Jan 16, 2014, at 2:27 AM, Mandy Chung mandy.ch...@oracle.com wrote: There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path. Empty path on bootclasspath is skipped by the bootstrap class loader when searching classes while it defaults to

Re: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources

2014-01-16 Thread Paul Sandoz
On Jan 16, 2014, at 4:51 PM, Mandy Chung mandy.ch...@oracle.com wrote: On 1/16/2014 7:39 AM, Paul Sandoz wrote: On Jan 16, 2014, at 2:27 AM, Mandy Chung mandy.ch...@oracle.com wrote: There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path.

RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread roger riggs
Please review: The native macros for checking and returning when exceptions are thrown have been renamed to include the JNU_ prefix consistent with other functions in jni_util.h. The macros have been renamed and existing uses in the jdk repository for networking, pack200, and have been updated.

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread Alan Bateman
On 16/01/2014 16:26, roger riggs wrote: Please review: The native macros for checking and returning when exceptions are thrown have been renamed to include the JNU_ prefix consistent with other functions in jni_util.h. The macros have been renamed and existing uses in the jdk repository for

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread roger riggs
Hi Alan, The macros are generally useful even without being used on a method that involves jni. An overly aggressive find caught the uses in java/util/jar/pack. But yes, it might be better to limit their scope to functions that involve jni. Roger On 1/16/2014 11:41 AM, Alan Bateman

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

2014-01-16 Thread Alan Bateman
On 16/01/2014 10:34, Volker Simonis wrote: : I just thought because poll is more file-descriptor oriented and not network specific. And the constants are also used for example in: src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: src/solaris/classes/sun/nio/ch/sctp/Sctp*

Re: Review request for JDK-6760902: inconsistent behavior in bootstrap class loader for classes and resources

2014-01-16 Thread Mandy Chung
On 1/16/2014 7:39 AM, Paul Sandoz wrote: On Jan 16, 2014, at 2:27 AM, Mandy Chung mandy.ch...@oracle.com wrote: There is an inconsistency in searching classes vs resources if bootclasspath contains an empty path. Empty path on bootclasspath is skipped by the bootstrap class loader when

Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN

2014-01-16 Thread Joe Darcy
On 01/15/2014 01:28 PM, Brian Burkhalter wrote: Issue: https://bugs.openjdk.java.net/browse/JDK-6667086 Webrev: http://cr.openjdk.java.net/~bpb/6667086/webrev/ According to micro-benckmarks, there is no statistically significant performance change due to applying this patch but the code

Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN

2014-01-16 Thread Brian Burkhalter
Oh I forgot to mention about the optimizations in the comments. I also read about those and was thinking to capture them in a separate issue for clarity. Thanks, Brian - Original Message - From: paul.san...@oracle.com Cc: core-libs-dev@openjdk.java.net Sent: Thursday, January 16, 2014

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread Kumar Srinivasan
Hi Roger, Its confusing to use a JNU_ prefixed macro on a method not involvng jni, why not rename these to modulo JNU_ ? I am cc'ing Alex as he has a related bug fix in his queue for pack's jni code. Kumar Hi Alan, The macros are generally useful even without being used on a method that

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread Ulf Zibis
Am 16.01.2014 17:26, schrieb roger riggs: Please review: webrev: http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ I more would like a while (true) loop, rather than a do loop. -Ulf

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread roger riggs
Hi, The current do {...} while(0) is the established idiom in the jdk. It does not have the potential problem of unintentionally allowing an infinite loop if the body contains a 'continue'. Roger On 1/16/2014 12:56 PM, Ulf Zibis wrote: Am 16.01.2014 17:26, schrieb roger riggs: Please

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

2014-01-16 Thread Xueming Shen
Hi, The proposed changeset is to improve the performance (both speed and memory usage) of String.toLowerCase/toUpperCase, by (1) to separate the most likely use scenario (non supplementary character, no special case mapping handling) into simple/quick iteration loop code path (2) to use the

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-16 Thread srikalyan
Hi David On 1/15/14, 9:04 PM, David Holmes wrote: On 16/01/2014 10:19 AM, srikalyan chandrashekar wrote: Hi Peter/David, we could finally get a trace of exception with fastdebug build and ReferenceHandler modified (with runImpl() added and called from run()). The logs, disassembled code is

Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN

2014-01-16 Thread Brian Burkhalter
Hi Joe, On Jan 16, 2014, at 9:23 AM, Joe Darcy wrote: A few comments here. If you are making this change in Double, you would make the corresponding change in Float too. Please see the updated webrev http://cr.openjdk.java.net/~bpb/6667086/webrev.2/. Some explanation on why I wrote these

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread Kumar Srinivasan
Roger, one more thing, shouldn't the parameters be unique ? I think Martin had me do this for all macros in the java launcher for example please see this changeset, I recently pushed. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6c50c972a101 Kumar On 1/16/2014 9:30 AM, Kumar Srinivasan wrote:

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread Ulf Zibis
Hi, thanks, I thought this is an endless loop until the inner condition is fulfilled, not really noting, that 0==false (one more reason to use true/false instead 1/0, IMHO). Can you explain the trick, why you use a one-time-loop instead of a single statement? -Ulf Am 16.01.2014 19:13,

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

2014-01-16 Thread Ulf Zibis
Hi Sherman, nice performance trick :-) Do you remember the discussion about : https://bugs.openjdk.java.net/browse/JDK-6939278 ;-) (this bug was originally filed by me!) -Ulf Am 16.01.2014 19:08, schrieb Xueming Shen: Hi, The proposed changeset is to improve the performance (both speed and

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread roger riggs
Check out the stackoverflow.com and bytes.com for explanations with examples. Using the pattern gives consistent results in a wide range of source contexts and parameter strings. Macros are textual substitutions; the c compiler only sees it after all the substitutions are done. The |do ...

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread roger riggs
Hi Kumar, The parameter names are purely local to the macro. They do not need to be unique. If the macro was longer (though it is now a lot longer than the original), it might make the code more readable. (Though I'm sure someone has a different convention). Roger On 1/16/2014 1:57 PM,

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread Ulf Zibis
Very much thanks Roger. I still would prefer false over 0 to avoid misinterpretation like I did :-( -Ulf Am 16.01.2014 20:44, schrieb roger riggs: Check out the stackoverflow.com and bytes.com for explanations with examples. Using the pattern gives consistent results in a wide range of source

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

2014-01-16 Thread roger riggs
The webrev has been updated to revert the java.util.jar/pack CHECK_* macros and to clean up the macro definitions in jni_util.h. I plan to give the review some more time in case there are more comments coming. Roger On Thu, Jan 16, 2014 at 8:26 AM, roger riggs roger.ri...@oracle.com

Re: RFR 8029452: Fork/Join task ForEachOps.ForEachOrderedTask clarifications and minor improvements

2014-01-16 Thread Mike Duigou
Very helpful. Thank you for adding the comments. Mike On Jan 16 2014, at 03:26 , Paul Sandoz paul.san...@oracle.com wrote: On Jan 10, 2014, at 2:42 PM, Paul Sandoz paul.san...@oracle.com wrote: I have also removed the inconsistently applied synchronized block. Either we apply it

Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN

2014-01-16 Thread Joseph Darcy
Hi Brian, On 1/16/2014 10:51 AM, Brian Burkhalter wrote: Hi Joe, On Jan 16, 2014, at 9:23 AM, Joe Darcy wrote: A few comments here. If you are making this change in Double, you would make the corresponding change in Float too. Please see the updated webrev

Re: JDK 9 RFC on 6667086: Double.doubleToLongBits(final double value) contains inefficient test for NaN

2014-01-16 Thread Brian Burkhalter
Hi Joe, On Jan 16, 2014, at 2:54 PM, Joseph Darcy wrote: Please see the updated webrevhttp://cr.openjdk.java.net/~bpb/6667086/webrev.2/. New webrev looks good. The change has been pushed. Note that I filed this linked issue to capture the Math.next{After,Up}({float,double}) changes

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-16 Thread srikalyan chandrashekar
Hi David, the disassembled code is also attached to the bug. Per my analysis the exception was thrown when Reference Handler was on line 143 as put in the earlier email. -- Thanks kalyan On 1/16/14 6:16 PM, David Holmes wrote: On 17/01/2014 4:48 AM, srikalyan wrote: Hi David On 1/15/14,

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-16 Thread David Holmes
On 17/01/2014 1:31 PM, srikalyan chandrashekar wrote: Hi David, the disassembled code is also attached to the bug. Per my Sorry missed that. analysis the exception was thrown when Reference Handler was on line 143 as put in the earlier email. But if the numbers in the dissassembly match

Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

2014-01-16 Thread srikalyan chandrashekar
On 1/16/14 8:38 PM, David Holmes wrote: On 17/01/2014 1:31 PM, srikalyan chandrashekar wrote: Hi David, the disassembled code is also attached to the bug. Per my Sorry missed that. analysis the exception was thrown when Reference Handler was on line 143 as put in the earlier email. But if