RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile

Bernd Eckenfels ecki at zusammenkunft.net
Mon Oct 8 19:35:09 UTC 2018


just noticed it is probably intended to not be synchronized for the reads (since it is volatile)?.

In that case using `this` monitor would also allow to remove the volatile. However not sure if that is good or bad for the Performance (close does not do DCL then anymore, but ist probably not called that often anyway)


Von: Bernd Eckenfels
Gesendet: Montag, 8. Oktober 2018 21:28
An: core-libs-dev
Betreff: AW: RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile

getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does I guess work since the important part is make sure only one thread does the close work, however Publishing the close change to getChannel is a secondary effect of the AtomicBoolean which the new Version does not have(?).

I guess the most efficient method would be to only use this as a monitor. While this is not the cleanest usage it is already used, so it does not make it worse…


Von: Alan Bateman
Gesendet: Montag, 8. Oktober 2018 21:21
An: Claes Redestad; core-libs-dev
Betreff: Re: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile

On 08/10/2018 16:32, Claes Redestad wrote:
> Hi,
> aligning the closing of RandomAccessFiles with the implementation in 
> FileInput-/OutputStream improves startup in a few tests.
> Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211859
This looks okay to me.


More information about the core-libs-dev mailing list