RFR: 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup
paul.sandoz at oracle.com
Tue Oct 25 20:39:40 UTC 2016
> 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?
> (Maybe an Unsafe.objectFieldOffset that takes Class + field name
> rather than Field could yield a small startup improvement?)
More information about the core-libs-dev