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

> On Aug 24, 2016, at 9:26 PM, David Holmes wrote: > > Hi Kim, > > Sorry this fell off the radar … That’s okay. There was a long gap while I was working on other things. > On 24/08/2016 7:09 AM, Kim Barrett wrote: >> Mandy asked for some additional comments to make

RFR 8164705: Remove pathname canonicalization from FilePermission

Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8164705/webrev.00 From the beginning of JDK, FilePermission canonicalizes the input path and use the result in implies() and equals(). This has been a big performance hurt and leads to confusing results when symlinks are

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect

John, This is useful, thanks. Probably more questions will follow after doing more homework. Mandy > On Aug 24, 2016, at 10:07 AM, John Rose wrote: > > On Aug 22, 2016, at 9:30 PM, Mandy Chung wrote: >> >> We need to follow up this issue to

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

Hi Kim, Sorry this fell off the radar ... On 24/08/2016 7:09 AM, Kim Barrett wrote: 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

Re: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet

> On 24 Aug 2016, at 15:48, Martin Buchholz wrote: > > Below it seems like weakCompareAndSetVolatile is susceptible to spurious > failure as much as other weak cas variants and so should have the same kind > of retry loop. > > { >

j.l.invoke and the wrapping of exceptions

Hi, Recent discussion on the wrapping of exceptions (any Throwable) in LinkageError be it for invokedynamic and BootstrapMethodError (a spec issue) or for signature polymorphic linkage (an implementation detail AFAICT) resulted in a more detailed look at the exception handling in the

Re: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet

Below it seems like weakCompareAndSetVolatile is susceptible to spurious failure as much as other weak cas variants and so should have the same kind of retry loop. { boolean success = false; for (int c = 0; c < WEAK_ATTEMPTS && !success;

Re: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet

> On 24 Aug 2016, at 14:17, Martin Buchholz wrote: > > Hi Paul, > > Thanks for doing this. > > Probably your IDE is fixing import statements. We'd prefer having that not > happen for j.u.c. but we can live with it. > Ah, i will update so as not to perturb that. > Of

Re: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet

On Wed, Aug 10, 2016 at 5:03 PM, Paul Sandoz wrote: > > This touches 166 classes that use or refer to the weak plain/volatile > methods. > Feel free to commit these. They will eventually break jsr166 CVS but we'll deal with it.

Re: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet

Hi Paul, Thanks for doing this. Probably your IDE is fixing import statements. We'd prefer having that not happen for j.u.c. but we can live with it. Of course, keeping all the variants in sync is errorprone. Below is one case where what you're testing and what your assertions say are out of

Re: RFR: 8163353: NPE in ConcurrentHashMap.removeAll()

Thanks all! Pushed. On Wed, Aug 24, 2016 at 1:06 PM, Paul Sandoz wrote: > > > On 24 Aug 2016, at 12:37, Martin Buchholz wrote: > > > > Let's get in the fix for regression 8163353 quickly: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ >

Re: RFR: 8163353: NPE in ConcurrentHashMap.removeAll()

> On 24 Aug 2016, at 12:37, Martin Buchholz wrote: > > Let's get in the fix for regression 8163353 quickly: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ > https://bugs.openjdk.java.net/browse/JDK-8163353

Re: RFR: 8163353: NPE in ConcurrentHashMap.removeAll()

On 24/08/2016 20:37, Martin Buchholz wrote: Let's get in the fix for regression 8163353 quickly: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ https://bugs.openjdk.java.net/browse/JDK-8163353 Looks good, I think a couple of

Re: RFR: 8163353: NPE in ConcurrentHashMap.removeAll()

+1 /Claes On 2016-08-24 21:37, Martin Buchholz wrote: Let's get in the fix for regression 8163353 quickly: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ https://bugs.openjdk.java.net/browse/JDK-8163353

RFR: 8163353: NPE in ConcurrentHashMap.removeAll()

Let's get in the fix for regression 8163353 quickly: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ConcurrentHashMap-keySet-removeAll/ https://bugs.openjdk.java.net/browse/JDK-8163353

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect

On Aug 22, 2016, at 9:30 PM, Mandy Chung wrote: > > We need to follow up this issue to understand what the interpreter and > compiler do for this unused slot and whether it’s always zero out. These slot pairs are a curse, in the same league as endian-ness. Suppose a

RFR: 8164739: Remove computation of predefined interpreter forms

Hi, LambdaForm predefines a number of forms for the benefit of the LF and NF interpreters, which doesn't appear useful at all at this point. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164739 Webrev: http://cr.openjdk.java.net/~redestad/8164739/webrev.01/ Testing: all java/lang/invoke

Re: RFR 8162108 Rename weakCompareAndSetVolatile to weakCompareAndSet

Hi, Gentle reminder. Paul. > On 10 Aug 2016, at 17:03, Paul Sandoz wrote: > > Hi > > Please review: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162108-rename-weakCompareAndSetVolatile/webrev/ > >

Re: RFR:8163793: jlink has typo in copy-files plugin help text example

+1 On 2016-08-24 16:28, Srinivas Dama wrote: Hi, This patch fixes very small typo error. Please review http://cr.openjdk.java.net/~sdama/8163793/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163793 Regards, Srinivas

Re: RFR:8163793: jlink has typo in copy-files plugin help text example

+1 On 8/24/2016 7:58 PM, Srinivas Dama wrote: > Hi, > > This patch fixes very small typo error. > > Please review http://cr.openjdk.java.net/~sdama/8163793/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163793 > > > Regards, > Srinivas

RFR:8163793: jlink has typo in copy-files plugin help text example

Hi, This patch fixes very small typo error. Please review http://cr.openjdk.java.net/~sdama/8163793/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163793 Regards, Srinivas

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

> On Aug 24, 2016, at 3:50 AM, Per Liden wrote: > > Still looks good. > > cheers, > Per Thanks. > > On 2016-08-23 23:09, Kim Barrett wrote: >> Mandy asked for some additional comments to make life easier for >> future readers. I've also stopped pretending the

Re: RFR: 8164483: Generate field lambda forms at link time

http://cr.openjdk.java.net/~redestad/8164483/webrev.02/ Looks good. Best regards, Vladimir Ivanov Regarding LambdaForm.Kind, IMO field accessors push enum approach to the limit. Let's think about better ways to represent LF shape in a structured manner, but I'm fine with keeping it for

Re: RFR: 8164483: Generate field lambda forms at link time

On 2016-08-24 13:02, Vladimir Ivanov wrote: src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java +@ForceInline +/*non-public*/ static Unsafe unsafe() { +return UNSAFE; +} + +NF_unsafe = new NamedFunction(DirectMethodHandle.class +

Re: RFR: 8164483: Generate field lambda forms at link time

src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java +@ForceInline +/*non-public*/ static Unsafe unsafe() { +return UNSAFE; +} + +NF_unsafe = new NamedFunction(DirectMethodHandle.class +

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

Looks good. Best regards, Vladimir Ivanov On 8/23/16 11:57 AM, Claes Redestad wrote: 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

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

On 24/08/2016 10:59, Claes Redestad wrote: Agreed, seems like something to consider for a future release. Thanks! /Claes PS. I still need a OpenJDK Reviewer before I can push this one Looks okay, I guess I would name it Holder or something like that rather than "Lazy" but that is a minor

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

+1. -Chris. On 23/08/16 21:52, Stephen Colebourne wrote: 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

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

Agreed, seems like something to consider for a future release. Thanks! /Claes PS. I still need a OpenJDK Reviewer before I can push this one On 2016-08-23 23:54, Stephen Colebourne wrote: Really, we should add a TemporalAmountFormatter to the JDK, but its a bigger piece of work and quite

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

Still looks good. cheers, Per On 2016-08-23 23:09, Kim Barrett wrote: 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

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 > wrote: I didn't see this thread before updating the bug. I