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

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 available in JIRA

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

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/ Thanks, Roger [1]https://bugs.openjdk.java.net/browse/JDK-8031961

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

On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov wrote: > Chris, > > Thanks for looking into this. See my answers inline. > > Best regards, > Vladimir Ivanov > > On 1/15/14 9:51 PM, Christian Thalinger wrote: >> [I’m resending something I sent earlier today to Vladimir directly.] >> >> On Jan

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

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 current working directory when searching resources as the application class load

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

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 available in JIRA as attachments. Observations from the l

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

Hi Alex, Kumar, thanks for your findings. See my comments inline. On 1/15/14 2:10, Kumar Srinivasan wrote: Hi Alex, zip.cpp: (nit) I would keep the hex values to be in upper case just like the others for consistency, not a big deal. Fixed. typo: + // Zi

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

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 definitely looks cleaner. Thanks, Brian

Re: RFR: (8030875) Macros for checking and returning on exceptions

Hi Martin, A followup, what is the subtlety that makes it beneficial to wrap even a single statement in a do {} while (0)? It makes sense for macros with multiple statements but not for a single statement substitution of expressions. For a single statement (w/o ';'), it seems like a redundant o

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

Chris, Thanks for looking into this. See my answers inline. Best regards, Vladimir Ivanov On 1/15/14 9:51 PM, Christian Thalinger wrote: [I’m resending something I sent earlier today to Vladimir directly.] On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vli

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

On 15 jan 2014, at 18:52, Volker Simonis wrote: > > > On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis > wrote: > > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > > wrote: > >> Hi Staffan, > >> > >> thanks for the review. Please find my comments inline: > >> > >> On Wed, Jan 15, 2014 at 9

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

On 15 jan 2014, at 18:27, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen >> wrote: >>> >>> Volker, >>> >>> I’ve look at the fo

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

Yes, that looks like a good solution. /Staffan On 15 jan 2014, at 17:34, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > wrote: > Volker, > > I’ve look at the following files: > > src/shar

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

On 1/15/14 21:34, Xueming Shen wrote: On 1/15/14 7:01 AM, Alexander Zuev wrote: Hello, the new webrev with all the typos and comments fixed can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ /Alex (1) jarmagic can be just a static constant somewhere or a stack variab

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

On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen < staffan.lar...@oracle.com> >> wrote: >>> >>> Volker

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

[I’m resending something I sent earlier today to Vladimir directly.] On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031502 > > InvokeBytecodeGenerator can produce incorrect bytecode for a

hg: jdk8/tl/jdk: 8031502: JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

Changeset: 9e91793fd516 Author:vlivanov Date: 2014-01-15 20:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e91793fd516 8031502: JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter Reviewed-by: sundar, lagergren, drc

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

On 1/15/14 7:01 AM, Alexander Zuev wrote: Hello, the new webrev with all the typos and comments fixed can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ /Alex (1) jarmagic can be just a static constant somewhere or a stack variable. not big deal though. (2) the test

Re: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input

Yes :-) -Joe On 01/15/2014 08:04 AM, Brian Burkhalter wrote: Given the identified items are changed accordingly is this approved? Thanks, Brian - Original Message - From: joe.da...@oracle.com To: brian.burkhal...@oracle.com Cc: core-libs-dev@openjdk.java.net Sent: Tuesday, January 14

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

On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > wrote: >> >> Volker, >> >> I’ve look at the following files: >> >> src/share/native/sun/management/DiagnosticComman

Re: RFR(S/L): 8028537: PPC64: Updated the JDK regression tests to run on AIX

Hi Alan, thanks for the suggestion. That's fine for me. I've copied the empty SCTP stubs from the macosx to the aix directory as well and updated the make file accordingly (in the patch for "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests"). Therefore, the changes to the

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

Hi Staffan, thanks for the review. Please find my comments inline: On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I’ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: “legel” -> “legal” (two times) > In Java_sun_management_Di

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

Sundar, thank you. Best regards, Vladimir Ivanov On 1/15/14 7:48 PM, A. Sundararajan wrote: Looks good to me -Sundar On Wednesday 15 January 2014 09:01 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8031502 InvokeB

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

David, thanks for looking at the fix. Good suggestion. Just ran tests on default methods - all pass. Best regards, Vladimir Ivanov On 1/15/14 7:44 PM, David Chase wrote: On 2014-01-15, at 10:31 AM, Vladimir Ivanov wrote: The fix is targeted for 8. Will be also integrated into 9. Testing:

Re: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input

Given the identified items are changed accordingly is this approved? Thanks, Brian - Original Message - From: joe.da...@oracle.com To: brian.burkhal...@oracle.com Cc: core-libs-dev@openjdk.java.net Sent: Tuesday, January 14, 2014 7:28:11 PM GMT -08:00 US/Canada Pacific Subject: Re: JDK 9

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

Looks good to me -Sundar On Wednesday 15 January 2014 09:01 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8031502 InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm when invoking a method from O

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

On 2014-01-15, at 10:31 AM, Vladimir Ivanov wrote: > The fix is targeted for 8. Will be also integrated into 9. > > Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, > nashorn, jruby. Vladimir, Did you test also on defmeth, or has that been incorporated into one of the

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

http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8031502 InvokeBytecodeGenerator can produce incorrect bytecode for a LambdaForm when invoking a method from Object declared in an interface. The problem is the following: (1) java.lang.CharSequen

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

Hello, the new webrev with all the typos and comments fixed can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ /Alex

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

Kumar, thanks for your findings. See my comments inline. On 1/15/14 2:10, Kumar Srinivasan wrote: Hi Alex, zip.cpp: (nit) I would keep the hex values to be in upper case just like the others for consistency, not a big deal. Fixed. typo: + // Zip64 END sugn

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

On 1/15/14 18:34, Alexander Zuev wrote: Sherman et all, self-correction regarding the flags, i misread the specification so flags are: always support UTF-8 file encoding (bit 11) and using EOS marker for the compressed files(bit 4). Damn my fast fingers - not bit 4, bit 3 and it tells we are s

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

Sherman et all, self-correction regarding the flags, i misread the specification so flags are: always support UTF-8 file encoding (bit 11) and using EOS marker for the compressed files(bit 4). /Alex On 1/15/14 18:26, Alexander Zuev wrote: Hi Sherman, Thanks for comments, here are some ans

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

Hi Sherman, Thanks for comments, here are some answers: the answer to (1)-(3) is that i do whatever the JarOutputStream/ZipOutputStream of the current JDK does and for a reason - there was a request from couple of customers to make native unpack200 results binary identical to the results t

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

On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > 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 values it might be okay. >> >> Another option would be to make those classes into "templates" as done

Re: JDK 9 RFR of 8030814: Long.parseUnsignedLong should throw exception on too large input

On Jan 14, 2014, at 8:56 PM, Brian Burkhalter wrote: > Please see the updated webrev > http://cr.openjdk.java.net/~bpb/8030814/webrev.3/. > > Hopefully my verbose description of the very clever overflow test is accurate > and understandable. Also, I cleaned up the JTREG test a bit and added

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

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 values it might be okay. Another option would be to make those classes into "templates" as done with Version.java.template and substitute the right values at buil

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

Volker, I’ve look at the following files: src/share/native/sun/management/DiagnosticCommandImpl.c: nit: “legel” -> “legal” (two times) In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInf