RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Remi Forax]

----- 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 12:37:50
> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of	AtomicReferenceFieldUpdater with Unsafe
> 
> 
> > 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.

small streams become big rivers (i don't know the idiomatic sentence in English, so it's a rough translation from a French idiom),
currently the main problem is that the loading of modules adds so much overhead to the startup time that you see nothing :(

Also, startup time is one aspect, size of the VM data structures at runtime, size of the CDS archive* are also impacted.

> 
> 
> > 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.

but there is also a good chance to miss that change later because you will look for usages of Unsafe and not usages of ARFU.
Replacing ARFU by Unsafe in BufferedInputStream makes the code more similar to the other usages of Unsafe in the JDK.

[...]

> 
> Paul.
> 

Rémi

* removing classes from a CDS archive is important for 32 bits windows VM

Rémi