RFR [10]: 8185362: Replace use of AtomicReferenceFieldUpdater from BufferedInputStream with Unsafe

[Claes Redestad]

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-bounces at openjdk.java.net> on behalf of Claes Redestad <claes.redestad at 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