Sure, I'll add the following comment:
/**
+ * As this class is used early during bootstrap, it's motivated to use
+ * Unsafe.compareAndSetObject instead of AtomicReferenceFieldUpdater
+ * (or VarHandles) to reduce dependencies and improve startup time.
+ */
+ private static final Unsafe U = Unsafe.getUnsafe();
/Claes
On 2017-08-21 22:57, Bernd Eckenfels wrote:
I would add a comment to Unsafe why it is used (instead of AtomicUpdater) maybe
pointing to the startup benchmark which shows the improved footprint? After all
adding Unsafe is might trigger somebody to clean it up in the next release...
// we use Unsafe instead of AtomicReferenceUpdater as it reduces startup
footprint
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Claes
Redestad <claes.redes...@oracle.com>
Sent: Monday, August 21, 2017 5:00:37 PM
To: Peter Levart; Aleksey Shipilev; core-libs-dev
Subject: Re: RFR [10]: 8185362: Replace use of AtomicReferenceFieldUpdater from
BufferedInputStream with Unsafe
On 08/21/2017 04:47 PM, Peter Levart wrote:
Is BufferedInputStream.close() intentionally not synchronized? All
other methods are. If close() was synchronized too, no CAS would be
needed and fields could be normal, not volatile. What is achieved by
close() not being synchronized? Fear of deadlocks?
I don't have the history here, but my gut-feeling is it's intentional to
allow calling close on streams that are blocked or waiting for data from
another thread in a non-blocking (or even deadlocking) fashion
/Claes
