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

Claes Redestad claes.redestad at oracle.com
Tue Oct 25 12:49:38 UTC 2016


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.

(Maybe an Unsafe.objectFieldOffset that takes Class + field name
rather than Field could yield a small startup improvement?)

Thanks!

/Claes

>
> Thanks,
> -Aleksey
>
>



More information about the core-libs-dev mailing list