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

> On Jun 29, 2016, at 6:42 PM, David Holmes wrote: > > The earlier you initialize Throwable the earlier you can try to create an > exception that has a backtrace. But there will always be a region of code > where we can't throw an OOME with a backtrace because of the

Semantics of VarHandle CAS methods

VarHandle.compareAndSet is strong in two ways - non-spurious and sequentially consistent. VarHandle.weakCompareAndSet is weak in both these ways. (That seems like a mistake to me. The fact that j.u.c. Atomic classes are a precedent for this seems unfortunate.)

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

> On Jun 28, 2016, at 10:19 PM, David Holmes wrote: > > So here is what I see has happened. > > Looking back at 9-b01, before we forced the initialization of > InterruptedException and thus Throwable we find: > > 58 Initializing 'java/lang/Throwable'

Re: RFR: jsr166 jdk9 integration wave 7

On 06/29/2016 01:28 PM, Peter Levart wrote: I see it was intentional as it is described in the docs... Is new behavior better? In tests so far, I see smaller variances, and approximately same average, so yes, a little better. Other usages of onSpinWait probably have more effect than this one

Re: RFR: jsr166 jdk9 integration wave 7

Responding to ForkJoinPool reviews (thanks for these!)... On 06/29/2016 06:41 PM, Martin Buchholz wrote: It may be better if the common pool and other pools are configured the same way, by having a maxSpares parameter instead of a maximumPoolSize parameter. The choice was between being

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

> On Jun 29, 2016, at 12:36 PM, Brent Christian > wrote: > > Hi, > > Please review the following change for JDK 9: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8160370 > Webrev: > http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ > > The fix for

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

Approved. Brian On Jun 29, 2016, at 4:33 PM, Brent Christian wrote: > Thank you, Dave and Gerard. > I believe I still need to hear from a JDK9 Reviewer.

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

Thank you, Dave and Gerard. I believe I still need to hear from a JDK9 Reviewer. Thanks, -Brent On 06/29/2016 01:08 PM, David DeHaven wrote: Fix looks good to me too. -DrD- On Jun 29, 2016, at 12:54 PM, Gerard Ziemski wrote: hi Brent, Thank you for fixing the

Re: RFR: jsr166 jdk9 integration wave 7

I agree the ForkJoinPool docs are difficult to understand. It's not immediately obvious that the maximumPoolSize of a user-constructed pool is effectively unlimited, but the maximumPoolSize of the common pool is availableProcessors + maxSpares. It may be better if the common pool and other pools

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

On 30/06/2016 5:12 AM, Kim Barrett wrote: On Jun 29, 2016, at 2:54 PM, Kim Barrett wrote: I think the problem may have existed long before modules, but simply wasn't noticed. That is, I suspect trying the test case mentioned below with a pre-June-2014 fastdebug build

Re: RFR 8158023: SocketExceptions contain too little information sometimes

Hi Christph, fine, push when ready. On 6/29/2016 5:18 PM, Langer, Christoph wrote: Hi Roger, thanks for reviewing. As for: jni_util.c: line 216: There I don't create an extra String but the Exception Object to throw, similar to the old function JNU_ThrowByNameWithLastError. I misread

RE: RFR 8158023: SocketExceptions contain too little information sometimes

Hi Roger, thanks for reviewing. As for: > jni_util.c: line 216: There I don't create an extra String but the Exception Object to throw, similar to the old function JNU_ThrowByNameWithLastError. > jni_util.h: > >line 117-119, The original comment was just as informative as the I think you

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

Fix looks good to me too. -DrD- > On Jun 29, 2016, at 12:54 PM, Gerard Ziemski > wrote: > > hi Brent, > > Thank you for fixing the original issue and for putting in this follow-up fix! > > Looks good! (for full disclosure I proposed the workaround) > > > cheers

Re: RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

hi Brent, Thank you for fixing the original issue and for putting in this follow-up fix! Looks good! (for full disclosure I proposed the workaround) cheers > On Jun 29, 2016, at 2:36 PM, Brent Christian > wrote: > > Hi, > > Please review the following change

RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac

Hi, Please review the following change for JDK 9: Bug: https://bugs.openjdk.java.net/browse/JDK-8160370 Webrev: http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ The fix for 7131356 fills in the "os.version" system property on Mac using [NSProcessInfo operatingSystemVersion], available

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

> On Jun 29, 2016, at 2:54 PM, Kim Barrett wrote: > > I think the problem may have existed long before modules, but simply > wasn't noticed. That is, I suspect trying the test case mentioned > below with a pre-June-2014 fastdebug build (when Reference started >

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

> On Jun 28, 2016, at 7:23 PM, David Holmes wrote: > > On 29/06/2016 8:43 AM, Kim Barrett wrote: >> Updated webrevs: >> >> Full: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ >> >> Incremental: >>

Re: RFR: jsr166 jdk9 integration wave 7

Hi, Several constructors of ForkJoinPool are modified with comments like " using defaults for all other parameters". However, there there are no other parameters in each constructor in question. It seems to imply a reference to the new full function constructor, that reference should be

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

> On Jun 28, 2016, at 3:43 PM, Kim Barrett wrote: > > Updated webrevs: > > Full: > http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ > The VM change does simplify the implementation a lot. Does/should the

Re: RFR: jsr166 jdk9 integration wave 7

I see it was intentional as it is described in the docs... Is new behavior better? Regards, Peter On 06/29/2016 07:19 PM, Peter Levart wrote: Hi Martin, I'm looking at changes in StampedLock. I noticed that you have consistently (in 4 places) replaced usages of the following idiom: 1044

Re: RFR: jsr166 jdk9 integration wave 7

Hi Martin, I'm looking at changes in StampedLock. I noticed that you have consistently (in 4 places) replaced usages of the following idiom: 1044 if (LockSupport.nextSecondarySeed() >= 0) 1045 --spins; with the following: 1056 --spins;

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

thank you, Claes, Vladimir, and Paul, for your reviews. See http://cr.openjdk.java.net/~mhaupt/8143211/webrev.01/ for the next round. The difference to the previous version is, roughly, as follows. Rev 01 ... ... honours the possibility of there being more than one loop in a LambdaForm;

Re: RFR: jsr166 jdk9 integration wave 7

Hi Martin, I was looking at the new constructor's API documentation in ForkJoinPool - and somehow got confused by the sentence: 2235 * @param maximumPoolSize [... 2241 * ...] To 2240 * arrange the same value as is used by default for the common 2241 * pool, use {@code 256}

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

Hi again, On 06/29/2016 03:30 PM, Peter Levart wrote: Just to show what I mean, here's a simple optimization that doesn't use a private pendingList of references shared among callers of tryHandlePanding(true/false), but instead uses course-grained synchronization and waiting for

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

Hi Kim, On 06/29/2016 01:22 PM, Peter Levart wrote: Transfering the whole list in one JNI invocation has the potential for further optimizations on the Java side (like handling the whole popped list privately without additional synchronization - if we ever find a way for java.nio.Bits to

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

Hi Kim, Let me chime-in although it's a bit late... I think this is a good change to finally get rid of OOME problems in this area. On 06/28/2016 07:45 PM, Kim Barrett wrote: On Jun 28, 2016, at 5:33 AM, Per Liden wrote: Patch looks good. The only thing I don't feel

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

... small correction: the FC extension for this RFE has been *requested*. Best, Michael > Am 29.06.2016 um 11:49 schrieb Michael Haupt : > > Hi again, > > as there have been no comments on the .01 version, I have updated it in place > with a new revision. This was

Re: RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors

Hi again, as there have been no comments on the .01 version, I have updated it in place with a new revision. This was necessary because there was a bug in InvokerBytecodeGenerator that led to the benchmarks crashing. The current revision, which is still available from

Re: RFR 8160439: Replace asserts in VarHandle.AccessMode with tests

> On 28 Jun 2016, at 21:37, Martin Buchholz wrote: > > Looks good. > Thanks. > I'm still nervous about using assert in performance critical code due to > hotspot bytecode count inlining heuristics. > The assert i left in place (because it is asserting on internal