Re: VarHandles on non-int-sized fields and atomic operations

On May 23, 2016, at 4:20 PM, Martin Buchholz wrote: > > As I said in a previous message, you can implement subword CAS using > fullword CAS in a loop. > > cas8bit(expect, update) { > for (;;) { >fullword = atomicRead32() >if ((fullword &0xff) != expect) return

Re: VarHandles on non-int-sized fields and atomic operations

Another way to look at it: We have an existing field boolean closed; which should be updated using CAS for correctness, but currently is not. I should not have to change the type of the field to int just so that I can get something that is CASable.

Re: VarHandles on non-int-sized fields and atomic operations

On Mon, May 23, 2016 at 3:48 PM, Aleksey Shipilev wrote: > By the way, what exactly are you winning with 1-byte field in AtomicBoolean? I'm not trying to replace the int field inside the AtomicBoolean with a boolean - that's an implementation detail. (Although I

Re: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05

On Mon, May 23, 2016 at 3:29 PM, Aleksey Shipilev wrote: > On 05/23/2016 11:32 PM, Martin Buchholz wrote: >> JSR166 CVS has some unfinished work in progress, but enough minor >> changes have accumulated that we should integrate into openjdk9: >> >>

Re: VarHandles on non-int-sized fields and atomic operations

On 05/24/2016 01:32 AM, Martin Buchholz wrote: > On Mon, May 23, 2016 at 3:15 PM, Aleksey Shipilev > wrote: >>> Since atomic fields need different field layout from regular fields, >>> it seems to make sense to require that fields which will be accessed >>> via a

Re: VarHandles on non-int-sized fields and atomic operations

On Mon, May 23, 2016 at 3:15 PM, Aleksey Shipilev wrote: >> Since atomic fields need different field layout from regular fields, >> it seems to make sense to require that fields which will be accessed >> via a VarHandle are clearly marked as being "atomic" in some

Re: RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05

On 05/23/2016 11:32 PM, Martin Buchholz wrote: > JSR166 CVS has some unfinished work in progress, but enough minor > changes have accumulated that we should integrate into openjdk9: > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ *) Removing

Re: VarHandles on non-int-sized fields and atomic operations

On Mon, May 23, 2016 at 1:16 PM, Martin Buchholz wrote: > So it is likely that > atomic > will be stored in a 32-bit field, since the cpu is likely to have a > 32-bit cas, but not 16-bit cas. So apparently you can still store your atomic in 16 bits, by implementing strong

Re: VarHandles on non-int-sized fields and atomic operations

On 05/23/2016 11:16 PM, Martin Buchholz wrote: > With VarHandles, the declared fields are Ordinary Java Fields, so they > are likely to be layed out as with normal fields. > As a result, it looks like you can't do a cas with a VarHandle to a > short field. > If that's true, then the hardware is

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

Hi Sherman, Martin, On 05/23/2016 08:28 PM, Xueming Shen wrote: My apology. I meant to say "to have Inflater to be aware of the ObjectPool...". The proposed change switches from the finalizer to the ObjectPool to clean up the native resource for Inflater. It appears to be a bigger change.

Re: [9] RFR: Static build of libzip is missing JNI_OnLoad_zip entry point

looks fine. On 05/20/2016 04:16 PM, Naoto Sato wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8150179 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8150179/webrev.00/ The fix is to simply bring the JNI OnLoad entry

RFR: JDK-8153768 Miscellaneous changes imported from jsr166 CVS 2016-05

JSR166 CVS has some unfinished work in progress, but enough minor changes have accumulated that we should integrate into openjdk9: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/ https://bugs.openjdk.java.net/browse/JDK-8153768

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

On Mon, May 23, 2016 at 12:55 PM, Xueming Shen wrote: > looks fine. i just pushed in a change. so you may need a sync :-) Thanks - pushed.

VarHandles on non-int-sized fields and atomic operations

I believe C++ allows anything to be atomic using their atomic<> template. Having the atomic annotation at the declaration site: - makes it obvious to the human and the compiler that the data must be accessed atomically. - allows the compiler to lay out the data so that native cpu instructions can

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

looks fine. i just pushed in a change. so you may need a sync :-) On 5/23/16, 12:49 PM, Martin Buchholz wrote: The utterly boring parts of my changes are in http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-tidy/ Can we get these in now?

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

The utterly boring parts of my changes are in http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-tidy/ Can we get these in now?

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

On Mon, May 23, 2016 at 11:28 AM, Xueming Shen wrote: > The proposed change switches from the finalizer to the ObjectPool to clean > up > the native resource for Inflater. It appears to be a bigger change. Which > has > a default 32/maxCacheSize and 1 secod keepAliveTime

Fwd: Files.walk() is unusable because of AccessDeniedException

Hello, why is my message still waiting for approval after a month ? Thank you. Best regards, Gilles -- Forwarded message -- From: Gilles Habran Date: 16 April 2016 at 07:33 Subject: Files.walk() is unusable because of AccessDeniedException To:

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

On 05/23/2016 11:00 AM, Peter Levart wrote: Hi Sherman, On 05/23/2016 05:44 PM, Xueming Shen wrote: It appears the scope of the change is bigger than the problem we are trying to solve here. The ClassLoader(s)/Resource changes are there just to measure the impact if input streams opened

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

Hi Sherman, On 05/23/2016 05:44 PM, Xueming Shen wrote: It appears the scope of the change is bigger than the problem we are trying to solve here. The ClassLoader(s)/Resource changes are there just to measure the impact if input streams opened from a jar file are closed explicitly as soon as

Re: RFR: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch

Looks good, Daniel. -Joe On 5/23/2016 8:39 AM, Daniel Fuchs wrote: Hi, Please find below a patch for: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch http://cr.openjdk.java.net/~dfuchs/webrev_8146389/webrev.00/index.html

Re: RFR(XS): 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception

> On 23 May 2016, at 16:58, Michael Haupt wrote: > > Dear all, > > please review this fix. > Bug: https://bugs.openjdk.java.net/browse/JDK-8157590 > Webrev: http://cr.openjdk.java.net/~mhaupt/8157590/webrev.00/ > +1 Paul.

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

It appears the scope of the change is bigger than the problem we are trying to solve here. The problem we are having here is that in certain use scenario the vm keeps a huge number of zip/jar files open and in which makes even the minimal cache mechanism (keep even one deflater for one zip

RFR: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch

Hi, Please find below a patch for: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch http://cr.openjdk.java.net/~dfuchs/webrev_8146389/webrev.00/index.html https://bugs.openjdk.java.net/browse/JDK-8146389 When JDK-8072645 (java.util.logging should use java.time

Re: RFR[9]: 8156868 MethodHandles.zero(Class) doc issues

> On 23 May 2016, at 08:27, shilpi.rast...@oracle.com wrote: > > Hi All, > > Please review small doc changes- > > http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/ > > Fixed following doc issues in same patch > > https://bugs.openjdk.java.net/browse/JDK-8138599 >

Re: RFR(M): 8156915: introduce MethodHandle factory for array length

... thank you so much, Uwe - it's up for review now. Best, Michael > Am 20.05.2016 um 09:42 schrieb Uwe Schindler : > > Hi, > > I just noticed that there is the @since missing in javadocs: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd39cefc5c8f#l3.13 >

RFR(XS): 8157590: MethodHandles.arrayLength() lacks @since tag, implementation throws wrong exception

Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8157590 Webrev: http://cr.openjdk.java.net/~mhaupt/8157590/webrev.00/ Thanks, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331

Re: RFR: 8156484: ZipFile retains too much native memory from caching Inflaters

Hi Martin, On 05/20/2016 08:53 PM, Martin Buchholz wrote: Peter, You keep impressing me with your development speed! Looking at ObjectPool ... looking pretty good Thanks. keepalivetime should be > 0. Right. ScheduledThreadPoolExecutor.scheduleWithFixedDelay throws

Re: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST

Argh email address completion fail… that was meant for someone else… sorry for the noise, Paul. > On 23 May 2016, at 13:28, Paul Sandoz wrote: > > Hmm… apparently simple patches can be accepted without OCA as pointed out by > David: > >

Re: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST

Hmm… apparently simple patches can be accepted without OCA as pointed out by David: http://openjdk.java.net/bylaws#participant Paul. > On 23 May 2016, at 13:25, David Holmes wrote: > > On 23/05/2016 8:43 PM, Paul Sandoz

Re: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST

On 23/05/2016 8:43 PM, Paul Sandoz wrote: Hi Naufal, Thanks for looking at this. For us to accept your patch (no matter how small) you need to become a contributor, which requires that you agree to the Oracle Contributor Agreement (OCA), see: http://openjdk.java.net/contribute/ Simple

Re: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST

Hi Paul, I've already sent a signed copy of the OCA to oracle-ca...@oracle.com. Thanks, Naufal On 23 May 2016 at 16:13, Paul Sandoz wrote: > Hi Naufal, > > Thanks for looking at this. > > For us to accept your patch (no matter how small) you need to become a >

Re: [PATCH] Implement a noop clear() for Collections#EMPTY_LIST

Hi Naufal, Thanks for looking at this. For us to accept your patch (no matter how small) you need to become a contributor, which requires that you agree to the Oracle Contributor Agreement (OCA), see: http://openjdk.java.net/contribute/ Thanks, Paul. > On 22 May 2016, at 12:10, Mohamed

RFR[9]: 8156868 MethodHandles.zero(Class) doc issues

Hi All, Please review small doc changes- http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/ Fixed following doc issues in same patch https://bugs.openjdk.java.net/browse/JDK-8138599