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

[Bernd Eckenfels]

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