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
