RFR: 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup

[Paul Sandoz]

> On 25 Oct 2016, at 05:49, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> 
> On 2016-10-25 13:09, Aleksey Shipilev wrote:
>> On 10/25/2016 12:51 PM, Claes Redestad wrote:
>>> Avoiding AtomicBoolean improves startup and footprint for a sample of
>>> small applications:
>>> 
>>> Webrev: http://cr.openjdk.java.net/~redestad/8168640/webrev.01/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168640
>> I would generally disagree to avoid Atomics to improve startup. In this
>> case, we always lock on close(), even for a short time. I wonder if
>> using plain Unsafe.compareAndSwap instead of Atomic would be cleaner,
>> instead of introducing performance bugs with synchronized-s.
> 
> I see your point, but in this specific case - for close() in particular -
> this patch more or less reverts to current 8u behavior, so risk of
> any performance impact versus baseline release is slim.
> 
> Besides - apart from being quite a bit trickier to get right and
> maintain - using Unsafe requires us to reflect over fields to get
> the offset, which might eats into the startup gain.
> 

Out of curiosity how much startup improvement are you observing, given that other VarHandle initialisation will occur at startup before execution of main?

Paul.

> (Maybe an Unsafe.objectFieldOffset that takes Class + field name
> rather than Field could yield a small startup improvement?)
> 
> Thanks!
> 
> /Claes
> 
>> 
>> Thanks,
>> -Aleksey
>> 
>> 
>