> On 25 Oct 2016, at 05:49, Claes Redestad <claes.redes...@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 >> >> >
