Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 06/05/2013 22:44, Peter Levart wrote: : If anyone is stop()-ing ReferenceHandler thread then it should be stopped. Speaking of that, if ThreadDeath is thrown in the middle of Cleaner's thunk.run() processing, then the Cleaner will exit JVM. I think ThreadDeath should be separately caught a

Re: JDK-8011653: Upgrade to JAXP 1.5

On 06/05/2013 18:49, huizhe wang wrote: : True. I've added 176 new tests. JCK team is also testing using the current build of JAXP RI. I will also run regression tests. The new webrev included fixes to a couple of test failures in the last JPRT build. http://cr.openjdk.java.net/~joehw/jdk8

hg: jdk8/tl/langtools: 8009724: Enhance the DocTree API with DocTreePath

Changeset: a7ff36d06fa2 Author:jlahoda Date: 2013-05-06 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a7ff36d06fa2 8009724: Enhance the DocTree API with DocTreePath Summary: Adding DocTreePath and DocTreePathScanner similar to TreePath and TreePathScanner, respe

hg: jdk8/tl/jdk: 8010192: Enable native JGSS provider on Mac

Changeset: 814dcc08df52 Author:weijun Date: 2013-05-07 12:30 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/814dcc08df52 8010192: Enable native JGSS provider on Mac Reviewed-by: valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/

hg: jdk8/tl/jdk: 8013252: Regex Matcher .start and .end should be accessible by group name; ...

Changeset: b4a013f4eff4 Author:sherman Date: 2013-05-06 21:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4a013f4eff4 8013252: Regex Matcher .start and .end should be accessible by group name 8013254: Constructor \w need update to add the support of \p{Join_Control} Summa

hg: jdk8/tl/jdk: 3 new changesets

Changeset: e13cf31e5a96 Author:mduigou Date: 2013-05-06 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e13cf31e5a96 8013712: Add Objects.nonNull and Objects.isNull Reviewed-by: mchung, darcy ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjec

Re: RFR: JDK-8013736: [launcher] cleanup code for correctness

This looks good. There's one check I found confusing. 175 if (alen <= 0 || alen > INT_MAX / sizeof(char *)) { Not that it matters much, but I'm not sure exactly what you're trying to check here. If you're trying to check that argc+2 doesn't overflow INT_MAX, I would do that directly in the o

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Catching ThreadDeath is futile. If someone is invoking stop() then you can encounter the ThreadDeath anywhere and it is impossible to write completely robust code in the face of such an async exception. So please let's not even go there. stop() is long deprecated and should never be used. Back

Re: Review Request: BigInteger patch for efficient multiplication and division (#4837946)

Hi Tim, On May 6, 2013, at 5:16 PM, Tim Buktu wrote: >> If I am not mistaken, the patch >> for Step 1 less the pow() improvements is this >> one: https://gist.github.com/tbuktu/1576025. For the time being I will >> start to look at this patch. > > Note that it also includes Burnikel-Ziegler. I

Re: Review Request: BigInteger patch for efficient multiplication and division (#4837946)

On May 6, 2013, at 5:19 PM, Tim Buktu wrote: > Replying to myself: > >> I will run the latest version of BigIntegerTest (which tests the above >> mentioned numbers around powers of two) for a day or so and report back. > > The test ran successfully. Thanks for the update! Brian

Re: Review Request: BigInteger patch for efficient multiplication and division (#4837946)

Hi Brian, On 06.05.2013 22:47, Brian Burkhalter wrote: > > Also helpful to the process would be to have (four) staged patches > available. I could take on this task as well, i.e., derive patches > from the code provided thus far, but it might be safer if those more > intimately familiar with the c

Re: Review Request: BigInteger patch for efficient multiplication and division (#4837946)

Replying to myself: > I will run the latest version of BigIntegerTest (which tests the above > mentioned numbers around powers of two) for a day or so and report back. The test ran successfully. Tim

Re: Relicensing of the BigInteger patch

Hi, On 06.05.2013 06:08, Joe Darcy wrote: > Hello, > > With the standard disclaimers that IANAL and "this is not legal > advice," I suggest you review the "Do I lose any rights to my > contribution under the OCA?" question in the Oracle Contributor > Agreement FAQ: > > http://www.oracle.com/te

Re: reRFR: 4802647 : NullPointerException not thrown by AbstractCollection.retainAll/removeAll

I recall considering whether to fix this "bug" myself many years ago. I decided that the value was so low (throw the "required" NPE when this collection is empty and the argument collection is null) that users who where not ultra-pedantic (or tck testers) would prefer the legacy behavior. And I w

Re: RFR: JDK-8013736: [launcher] cleanup code for correctness

Here is the modified webrev: http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/ delta webrev to the last webrev: http://cr.openjdk.java.net/~ksrini/8013736/webrev.1/webrev.delta/index.html I added the do { . } while (0) pattern to all the launcher's macro defs, I also addressed Alan's comm

reRFR: 4802647 : NullPointerException not thrown by AbstractCollection.retainAll/removeAll

Hello all; Long, long ago, Brandon Passanisi proposed a fix to correct non-conformant implementation of retainAll/removeAll(). It was reviewed but was never committed to TL repo (it got lost amidst Christmas vacation and other matters). Rather than surprise everyone with a rogue changeset they

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 05/06/2013 09:42 PM, Peter Levart wrote: On 05/06/2013 05:03 PM, Alan Bateman wrote: On 06/05/2013 09:02, Thomas Schatzl wrote: : Alan also mentioned something about instrumentation that can add memory allocations basically anywhere. As the reference handler code is plain java code, it wi

hg: jdk8/tl/jdk: 8003992: File and other classes in java.io do not handle embedded nulls properly

Changeset: bd118033e44c Author:dxu Date: 2013-05-06 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd118033e44c 8003992: File and other classes in java.io do not handle embedded nulls properly Summary: Have every file operation done with File, FileInputStream, FileOutp

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 04/30/2013 04:57 PM, Thomas Schatzl wrote: I implemented a nice way to reproduce an OOME in the reference handler. This involves implementing a custom java.lang.ref.ReferenceQueue and overriding the enqueue() method, and doing some allocation that causes an OOME within that method. Hi Thoma

Re: Review Request: BigInteger patch for efficient multiplication and division (#4837946)

Hi Alan, Thank you for the detailed, thoughtful message. On May 4, 2013, at 5:13 AM, Alan Eliasen wrote: > If you're feeling overwhelmed by the magnitude of the changes to > BigInteger, I would very strongly suggest that you review it in stages. > This e-mail proposes stages for the review of

Re: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

On 05/06/2013 06:59 AM, Florian Weimer wrote: On 05/03/2013 01:08 AM, Dan Xu wrote: Hi All, Thanks for all your comments. Based on the previous feedback, I have moved to the other approach, i.e., to fail file operations if the invalid NUL characher is found in a file path. As you know, due to

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 05/06/2013 10:02 AM, Thomas Schatzl wrote: I mean, if we fix this issue as you suggested (I am not against that, it looks reasonable), I would not know what to do with the test program except file another bug against the very same component with the same problem, with the same fix suggestion.

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 05/06/2013 05:03 PM, Alan Bateman wrote: On 06/05/2013 09:02, Thomas Schatzl wrote: : Alan also mentioned something about instrumentation that can add memory allocations basically anywhere. As the reference handler code is plain java code, it will be affected as other java code. I mentioned

Re: RFR 8013541: Revise javadoc for Executable.getAnnotatedReturnType()

Hi Joel, Looks fine; cheers, -Joe On 05/03/2013 05:35 AM, Joel Borggrén-Franck wrote: Hello all, Also a small update to the javadoc of Executable to make it more consistent for type annotations. http://cr.openjdk.java.net/~jfranck/8013541/webrev.00/ For oracle reviewers, CCC is filed. ch

Re: RFR: 8005051: optimized defaults for Iterator.forEachRemaining

Looks good to me. I will run it through final integration tests and push to TL. Mike On May 1 2013, at 15:55 , Akhil Arora wrote: > On 04/26/2013 04:52 AM, Paul Sandoz wrote: >> >> On Apr 24, 2013, at 7:57 PM, Remi Forax wrote: >> >>> On 04/24/2013 07:24 PM, Akhil Arora wrote: On 04/24/2

Re: JDK-8011653: Upgrade to JAXP 1.5

On 5/4/2013 12:12 AM, Alan Bateman wrote: On 03/05/2013 19:02, huizhe wang wrote: : Removed the repetitive "value" definition from the setAttribute/setProperty methods. The open statements already have references to the properties in XMLConstants. Updated to: "The default value is implemen

RFR: JDK-8006884(2nd round): (fs) Add Files.list, lines and find

Hi, Updated based on feedback, http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/webrev/ http://cr.openjdk.java.net/~henryjen/ccc/8006884.1/specdiff/ Changed from previous request, 1. DirectoryStream.entries() is renamed to DirectoryStream.stream(). 2. Clarify operating closed stream returned

Re: RFR [8005953] Speedup construction of CopyOnWriteArraySet in special cases

On 04/30/13 07:41, Ivan Gerasimov wrote: Hello everybody! Would you please review my proposal to change constructor of CopyOnWriteArraySet? I included something with similar effect in CopyOnWriteArray{List,Set} update in jsr166 repo: It bypasses copy in CopyOnWriteArrayList constructor (and,

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 06/05/2013 09:02, Thomas Schatzl wrote: : Alan also mentioned something about instrumentation that can add memory allocations basically anywhere. As the reference handler code is plain java code, it will be affected as other java code. I mentioned instrumentation on the off-chance that there

Re: Review Request for JDK-8003992: File and other classes in java.io do not handle embedded nulls properly

On 05/03/2013 01:08 AM, Dan Xu wrote: Hi All, Thanks for all your comments. Based on the previous feedback, I have moved to the other approach, i.e., to fail file operations if the invalid NUL characher is found in a file path. As you know, due to the compatibility issue, we cannot throw an exce

Re: RFR: JDK-8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently

On 02/05/2013 17:24, Daniel Fuchs wrote: Hi, Please find an updated webrev below: Changes are: catch IAE are removed - as suggested by Alan. I didn't find traces of IAE being thrown by OutputStreamWriter constructor in recent JDK - so

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

On 05/06/2013 10:02 AM, Thomas Schatzl wrote: Hi, On Sat, 2013-05-04 at 21:23 +0200, Peter Levart wrote: On 05/04/2013 07:38 PM, Vitaly Davidovich wrote: Oops, that was my mistake - I thought the lock here was a j.u.c.Lock which of course doesn't even make sense given we're talking about Obje

Re: RFR 8013334: Spliterator behavior for LinkedList contradicts Spliterator.trySplit

On May 3, 2013, at 9:42 PM, Peter Levart wrote: > > On 05/03/2013 09:10 PM, Paul Sandoz wrote: >> Hi Peter, >> >> On May 3, 2013, at 12:07 PM, Peter Levart wrote: >> >>> Hi Paul, >>> >>> Maybe the JavaDoc could also suggest that the trySplit producing N+0 result >>> should converge so that

Re: (Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Hi, On Sat, 2013-05-04 at 21:23 +0200, Peter Levart wrote: > > On 05/04/2013 07:38 PM, Vitaly Davidovich wrote: > > > Oops, that was my mistake - I thought the lock here was a j.u.c.Lock > > which of course doesn't even make sense given we're talking about > > ObjectMonitor. So disregard that b