RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8151179 Webrev: http://cr.openjdk.java.net/~mhaupt/8151179/webrev.00/ The change addresses concerns about the JEP 274 API that were raised by the JCK team. One consequence is that the convenience wrappers for the

Re: RFR: jsr166 jdk9 integration wave 9

On Thu, Aug 11, 2016 at 2:12 PM, Aleksey Shipilev < aleksey.shipi...@gmail.com> wrote: > On 08/11/2016 11:56 PM, Martin Buchholz wrote: > > I can imagine a machine that has a native cas instruction, but no native > > exchange instruction, but no one ever got fired for optimizing for x86. > >

Re: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke

@Stable works on non-final fields as well as array elements. – John > On Aug 11, 2016, at 2:48 PM, Aleksey Shipilev > wrote: > > Stable only works on finals, right?

Re: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke

On 08/11/2016 11:51 PM, Michael Haupt wrote: > thumbs up - I'd appreciate if Aleksey could take a glance at the changes in > the String concatenation logic though. > > Best, > Michael > >> Am 11.08.2016 um 10:55 schrieb Claes Redestad : >> >> while further untangling

Re: RFR: jsr166 jdk9 integration wave 9

On 08/11/2016 11:56 PM, Martin Buchholz wrote: > I can imagine a machine that has a native cas instruction, but no native > exchange instruction, but no one ever got fired for optimizing for x86. ...which would be less of an issue once we switch to proper-boolean VarHandles, not the

Re: RFR: jsr166 jdk9 integration wave 9

Thanks Aleksey, for the usual convincing benchmark result. You win! I can imagine a machine that has a native cas instruction, but no native exchange instruction, but no one ever got fired for optimizing for x86. public final boolean getAndSet(boolean newValue) { return

Re: RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke

Hi Claes, thumbs up - I'd appreciate if Aleksey could take a glance at the changes in the String concatenation logic though. Best, Michael > Am 11.08.2016 um 10:55 schrieb Claes Redestad : > > Hi, > > while further untangling the bootstrap of java.lang.invoke I

Re: RFR: jsr166 jdk9 integration wave 9

On 08/11/2016 09:59 PM, Martin Buchholz wrote: > On Thu, Aug 11, 2016 at 10:40 AM, Aleksey Shipilev >> Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is >> hopefully intrinsified completely? > > Good question. This optimization originated in a suggestion for jdk8, > where

Re: RFR (JAXP) 8163535: javax/xml/jaxp/unittest/catalog/CatalogSupport2.java failed due to SocketTimeoutException

+1 Joe Best Lance > On Aug 10, 2016, at 6:35 PM, Joe Wang wrote: > > Hi, > > These tests shall accept any IOException. Please review. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8163535 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8163535/webrev/ > > Thanks,

Re: RFR: 6543126: Level.known can leak memory

> On Aug 11, 2016, at 2:29 AM, Daniel Fuchs wrote: > > On 10/08/16 17:21, Mandy Chung wrote: >>> On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: >>> > >>> > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ >> This looks pretty

Re: RFR: jsr166 jdk9 integration wave 9

On Thu, Aug 11, 2016 at 10:40 AM, Aleksey Shipilev < aleksey.shipi...@gmail.com> wrote: > On 08/11/2016 04:34 AM, Martin Buchholz wrote: > > Again, no spec changes, but larger than expected. > > > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ > jsr166-jdk9-integration/ > > Why doesn't

RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke

Hi, while further untangling the bootstrap of java.lang.invoke I found a number of trivial/minor/small contrivances, including: - calling of private methods and constants in parent classes generates and heavily exercise synthetic bridge methods; carefully making more of these

Re: RFR: jsr166 jdk9 integration wave 9

On 08/11/2016 04:34 AM, Martin Buchholz wrote: > Again, no spec changes, but larger than expected. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Why doesn't AtomicBoolean.getAndSet use VarHandle.getAndSet, which is hopefully intrinsified completely? I like the

Re: RFR 8163877: Tests added in JDK-8163518 fail on some platforms

Hi Ivan, The change looks okay, but if the test turns out to take a long time to run, I think we should reconsider whether or not the test is worth running all the time. Cheers, -Joe On 8/11/2016 10:33 AM, Ivan Gerasimov wrote: Hello! The freshly added tests fail when 32-bit JVM is

RFR 8163877: Tests added in JDK-8163518 fail on some platforms

Hello! The freshly added tests fail when 32-bit JVM is tested on 64-bit OS. The fix is to use more appropriate condition under the @requires tag. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163877 WEBREV: http://cr.openjdk.java.net/~igerasim/8163877/00/webrev/ With kind regards, Ivan

Re: RFR: 8161016: Strange behavior of URLConnection with proxy

On 08/11/2016 05:17 PM, Ramanand Patil wrote: > Webrev: http://cr.openjdk.java.net/~rpatil/8161016/webrev.00/ > > Fix: Instead of falling back to direct connection when last proxy > fails to open connection, re-try once with the last proxy. An > alternate solution can also be- don't try to open

Re: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues

Looks fine; thanks, -Joe On 8/10/2016 11:30 PM, John Jiang wrote: Hi, Please review another updated webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.02/ com/sun/jdi/JdbMethodExitTest.sh 8031555 generic-all The above line shouldn't be removed, and 8031555 should be replaced by

RFR: 8161016: Strange behavior of URLConnection with proxy

Hi all, Please review the fix for Bug  - https://bugs.openjdk.java.net/browse/JDK-8161016 Bug Description: When ProxySelector is present, i.e. there is minimum one proxy set (by System Property or System Default or using Custom ProxySelector implementation) connection should be opened through

Re: RFR: 6543126: Level.known can leak memory

Hi Peter, On 10/08/16 22:06, Peter Levart wrote: static synchronized void add(Level l) { purge(); KnownLevel o = new KnownLevel(l); nameToLevels.computeIfAbsent(l.name, n -> new ArrayList<>()).add(o); intToLevels.computeIfAbsent(l.value, v -> new ArrayList<>()).add(o); } I

RE: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently

> -Original Message- > From: Joe Wang [mailto:huizhe.w...@oracle.com] > Subject: Re: RFR (JAXP) JDK-8163468: > javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently > > +1, good to identify the cause. Amy helped me to identify it, so thanks to Amy! Frank > >

Re: RFR: 6543126: Level.known can leak memory

On 10/08/16 17:21, Mandy Chung wrote: On Jul 29, 2016, at 4:54 AM, Daniel Fuchs wrote: > > http://cr.openjdk.java.net/~dfuchs/webrev_6543126/webrev.01/ This looks pretty good. Since KnownLevel is now a Reference, I suggest to change KnownLevel::findByName,

Re: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues

Hi, Please review another updated webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.02/ com/sun/jdi/JdbMethodExitTest.sh 8031555 generic-all The above line shouldn't be removed, and 8031555 should be replaced by 6902121. Because JDK-8031555 is closed as a duplicate of JDK-6902121, which