Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 2016/8/24 12:53, David Holmes wrote: On 24/08/2016 1:39 PM, Hamlin Li wrote: On 2016/8/24 11:02, Martin Buchholz wrote: On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz mailto:marti...@google.com>> wrote: I didn't see this thread before updating the bug. I think this is Not a Bu

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 24/08/2016 1:39 PM, Hamlin Li wrote: On 2016/8/24 11:02, Martin Buchholz wrote: On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz mailto:marti...@google.com>> wrote: I didn't see this thread before updating the bug. I think this is Not a Bug, because """The current atomic addAll i

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 2016/8/24 11:02, Martin Buchholz wrote: On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz > wrote: I didn't see this thread before updating the bug. I think this is Not a Bug, because """The current atomic addAll is a tradeoff; it's efficient, but a

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On Tue, Aug 23, 2016 at 9:17 AM, Martin Buchholz wrote: > I didn't see this thread before updating the bug. > > I think this is Not a Bug, because """The current atomic addAll is a > tradeoff; it's efficient, but at the cost of potential loss of concurrency > if the other collection is slow. It's

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 2016/8/24 9:22, David Holmes wrote: Hi Hamlin, On 23/08/2016 10:53 PM, Hamlin Li wrote: On 2016/8/23 17:10, David Holmes wrote: Hi Hamlin, On 23/08/2016 6:55 PM, Hamlin Li wrote: Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic op

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

Hi Hamlin, On 23/08/2016 10:53 PM, Hamlin Li wrote: On 2016/8/23 17:10, David Holmes wrote: Hi Hamlin, On 23/08/2016 6:55 PM, Hamlin Li wrote: Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic operation. No it is not! There is no bug

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

Hi Martin, Thank you for clarifying and taking the bug. -Hamlin On 2016/8/24 0:17, Martin Buchholz wrote: I didn't see this thread before updating the bug. I think this is Not a Bug, because """The current atomic addAll is a tradeoff; it's efficient, but at the cost of potential loss of con

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> On Aug 23, 2016, at 5:31 PM, Mandy Chung wrote: > > >> On Aug 23, 2016, at 2:09 PM, Kim Barrett wrote: >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ >> >> Unchanged hotspot webrevs: >> full:

Re: RFR 8160971 Re-enable VarHandle tests quarantined by JDK-8160690

Looks good. I'm fine with pushing it directly to jdk9/dev. Best regards, Vladimir Ivanov On 8/24/16 1:10 AM, Paul Sandoz wrote: Hi, Please review an update to test/ProblemList.txt remove some VarHandle tests now that JDK-8160690 has been fixed. I will push to jdk9/dev unless HotSpot team mem

Re: Exceptional behavior of parallel stream

An enhancement issue is nice, but what can you really do? The reason the framework cannot handle exceptions in related threads is because the framework doesn’t have a central thread management facility. It spits out threads like the Executor Service it inherits without regard for controlling those

RFR 8160971 Re-enable VarHandle tests quarantined by JDK-8160690

Hi, Please review an update to test/ProblemList.txt remove some VarHandle tests now that JDK-8160690 has been fixed. I will push to jdk9/dev unless HotSpot team members have a preference for me to push to hs-comp where the fix for JDK-8160690 was pushed. Paul. diff -r 5612c35465f3 test/Proble

Re: Exceptional behavior of parallel stream

Hi Tagir, After some discussion with Doug i logged an issue: https://bugs.openjdk.java.net/browse/JDK-8164690 but as of yet undecided whether we should do anything about it at the level of ForkJoinTask or specific to Stream (or even Concurre

Re: RFR: 8164669: Lazier initialization of java.time

Really, we should add a TemporalAmountFormatter to the JDK, but its a bigger piece of work and quite tricky. Stephen On 23 August 2016 at 22:52, Claes Redestad wrote: > > > On 2016-08-23 22:52, Stephen Colebourne wrote: >> >> This looks fine to me. > > > Thanks for the review! > >> I suspect that

Re: RFR: 8164669: Lazier initialization of java.time

On 2016-08-23 22:52, Stephen Colebourne wrote: This looks fine to me. Thanks for the review! I suspect that we could hand write a parser to avoid the regex, but this probably suffices. Stephen Right, this is admittedly a bit of a hack. Maybe it would be possible to carefully use/extend Da

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

> On Aug 23, 2016, at 2:09 PM, Kim Barrett wrote: > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.05.inc/ > > Unchanged hotspot webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/ > incr

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

Mandy asked for some additional comments to make life easier for future readers. I've also stopped pretending the description for waitForReferenceProcessing is javadoc, since this function is private and only accessible via SharedSecrets or reflection that avoids access control. Changes only in t

Re: RFR: 8164669: Lazier initialization of java.time

This looks fine to me. I suspect that we could hand write a parser to avoid the regex, but this probably suffices. Stephen On 23 August 2016 at 19:49, Claes Redestad wrote: > Hi, > > this tiny cleanup reduces number of loaded classes from a minimal test > touching java.time.ZoneId.systemDefault()

Re: RFR 8157797: SAX Parser throws incorrect error on invalid xml

Thanks Lance! Joe On 8/23/16, 12:34 PM, Lance Andersen wrote: Looks fine Joe. On Aug 23, 2016, at 12:53 PM, Joe Wang > wrote: Hi, Please review a quick fix for an incorrect error that should never have been thrown. JBS: https://bugs.openjdk.java.net/browse/

Re: RFR 8157797: SAX Parser throws incorrect error on invalid xml

Looks fine Joe. > On Aug 23, 2016, at 12:53 PM, Joe Wang wrote: > > Hi, > > Please review a quick fix for an incorrect error that should never have been > thrown. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8157797 > > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8157797/webrev/ > >

RFR: 8164669: Lazier initialization of java.time

Hi, this tiny cleanup reduces number of loaded classes from a minimal test touching java.time.ZoneId.systemDefault() by ~40, by virtue of avoiding pulling in regex and some internal Calendar-related classes. Bug: https://bugs.openjdk.java.net/browse/JDK-8164669 Webrev: http://cr.openjdk.java.

Re: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration

On 19.08.2016 00:17, Paul Sandoz wrote: > > Onward to the implementation! > > Paul. I did not manage it to get the OpenJDK to compile stressfully under my Fedora Linux as in the past now. Anyhow here a sample implementation, that I will integrate into the existing ClassLoader and the according T

Re: RFR: 8148859 Fix module dependences for java/time tests

> On Aug 23, 2016, at 7:35 AM, Alan Bateman wrote: > > On 23/08/2016 01:32, Alexandre (Shura) Iline wrote: > >> Hi. >> >> Please review a quick fix for the java/time test module dependencies. >> http://cr.openjdk.java.net/~shurailine/8148859/webrev.00/ >> >> It is using new syntax added in JT

Re: 8164585: JarFile::isMultiRelease does not return true in all cases where it should return true

> On 22 Aug 2016, at 16:18, Steve Drach wrote: > > Hi, > > Please review this simple change to JarFile > > issue: https://bugs.openjdk.java.net/browse/JDK-8164585 > > webrev: http://cr.openjdk.java.net/~sdrach/8164585/webrev.00/ >

RFR 8157797: SAX Parser throws incorrect error on invalid xml

Hi, Please review a quick fix for an incorrect error that should never have been thrown. JBS: https://bugs.openjdk.java.net/browse/JDK-8157797 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8157797/webrev/ Thanks, Joe

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

I didn't see this thread before updating the bug. I think this is Not a Bug, because """The current atomic addAll is a tradeoff; it's efficient, but at the cost of potential loss of concurrency if the other collection is slow. It's reasonable for a subclass to override addAll to add elements eager

Re: RFR: 8148859 Fix module dependences for java/time tests

On 23/08/2016 01:32, Alexandre (Shura) Iline wrote: Hi. Please review a quick fix for the java/time test module dependencies. http://cr.openjdk.java.net/~shurailine/8148859/webrev.00/ It is using new syntax added in JTReg, which allows to only build certain classes from a test library for Tes

Re: 8164585: JarFile::isMultiRelease does not return true in all cases where it should return true

On 23/08/2016 00:18, Steve Drach wrote: Hi, Please review this simple change to JarFile issue: https://bugs.openjdk.java.net/browse/JDK-8164585 webrev: http://cr.openjdk.java.net/~sdrach/8164585/webrev.00/

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

On 2016/8/23 17:10, David Holmes wrote: Hi Hamlin, On 23/08/2016 6:55 PM, Hamlin Li wrote: Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic operation. No it is not! There is no bug here. Are you perhaps confusing thread-safe with ato

Re: RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

Hi Hamlin, On 23/08/2016 6:55 PM, Hamlin Li wrote: Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic operation. No it is not! There is no bug here. Are you perhaps confusing thread-safe with atomic? David - "Additionally, the bu

RFR: 8164569: Generate non-customized invoker forms at link time

Hi, this patch adds configurable link-time generation of the invoker forms. Some such forms is commonly used early on in even the simplest startup tests, and an unbounded number of invoker forms can be generated in more complex cases. Bug: https://bugs.openjdk.java.net/browse/JDK-8164569 Web

RFR: 8164483: Generate field lambda forms at link time

Hi, this patch adds link-time generation of the simplest field lambda forms. This avoid generating these forms during bootstrapping, which is commonly done early on in even the simplest startup tests. To make this work, injecting Unsafe as a constant replacement had to be replaced with a get

RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java

Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic operation. "Additionally, the bulk operations addAll, removeAll, retainAll, containsAll, equals, and toArray are not guaranteed to be performed atomically. For example, an iterator operati