RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Paul Sandoz]

> On 5 Apr 2016, at 17:15, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> On 04/04/2016 05:45 PM, Martin Buchholz wrote:
>>> I think this one is going too far.
>>> 
>>> A*FU/VarHandles should are supposed to act like a go-to replacement for
>>> Unsafe throughout the class library, and we want to shrink the Unsafe
>>> exposure. Also, I don't think removing A*FU in favor of Unsafe here wins
>>> us anything: there should be no throughput hit, and we *will* load A*FU
>>> down the road anyway, negating the startup wins.

+1 i would leave this one as is.

In general same goes for the @Stable/ForceInline annotations etc. We should use this stuff carefully within java.base and also sparingly to qualifying JDK modules.

>>> 
>>> -Aleksey
>> It is surprising to see new uses of Unsafe when we have an ongoing
>> initiative within openjdk (especially from Paul Sandoz) to remove most
>> uses.  Varhandles are coming and are expected to replace uses of
>> Unsafe in the JDK.
> 
> This is just a very minor win on hello world/-version style tests, so I'm happy to withdraw this if other early usages, such as CHM, is moving to VarHandles anyhow.
> 
> OTOH using dangerous, internal APIs like this rather than nice, public APIs early in the VM bootstrap has other merits, such as not unintentionally causing bootstrap issues. Say, I don't know if VarHandles have any dependencies on java.lang.invoke currently…

It does, but was designed to be minimize bootstrap issues and class spinning so there are less dependencies than MHs.

CHM is a tricky class because MethodType uses CHM and VHs uses MethodType. There is probably a way of switching from a less concurrent concurrent map to CHM at “safe-point” when the VM transitions to booted. To be investigated...

Paul.