RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Paul Sandoz]

> On 6 Apr 2016, at 12:10, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ----- Mail original -----
>> De: "Paul Sandoz" <paul.sandoz at oracle.com>
>> Cc: "core-libs-dev Libs" <core-libs-dev at openjdk.java.net>
>> Envoyé: Mercredi 6 Avril 2016 09:37:00
>> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of	AtomicReferenceFieldUpdater with Unsafe
>> 
>> 
>>> 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.
> 
> While i fully agree in the general case, in disagree for this specific case,
> there are few uses of ARFU inside the JDK (or outside) but currently because BufferedInputStream uses an ARFU, each time someone starts a Java application, the VM loads ARFU and its implementation with a high probability to no need it at all after
> 

Does that really contribute sufficiently to slow down in start time? It really seems like a micro-optimisation.


> ARFU are not a replacement of Unsafe, VarHandles are. So adding a new usage of Unsafe for a good reason goes in the right direction here,
> when VarHandle will replace usages of Unsafe, the code of BufferedInputStream will be refactored again.
> 

My preference is not to change it if it’s gonna change later on.


>> 
>>>>> 
>>>>> -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...
> 
> another solution is perhaps to not use a concurrent hashmap in MethodType, method types need to be interned only the first time a method handle is invoked with an invokeExact/invoke (but not by invokedynamic) so instead of interning all method types which artificially put pressure on the interning map to be lock free, interning only the method type when need it may allow to not use a CHM in MethodType.
> 

I need to re-familiarise myself with the code to see what is possible here. MethodType also comes with a shared erased form which also caches LambdaForms for various kinds. It’s not clear to me if this can be easily be teased apart.

Paul.