RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[forax at univ-mlv.fr]

----- Mail original -----

> De: "Vitaly Davidovich" <vitalyd at gmail.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev Libs"
> <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 6 Avril 2016 15:04:39
> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of
> AtomicReferenceFieldUpdater with Unsafe

> On Wednesday, April 6, 2016, 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 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:
> 
[...] 

> > > > 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),
> 
> "Death by a thousand cuts" is one of my favorites :). A "flat profile" is
> another description of a similar thing.

> In general, I agree that easy/cheap/maintainable/etc wins should be done even
> if individually they don't matter much (if that were the requirement, there
> would be no progress whatsoever).

> In this case, using Unsafe for now seems trivial; when VH is ready, someone
> is going to sweep the code anyway and this will be just one more place to
> mechanically update. Is VH definitely going to be part of Java 9? If so,
> then perhaps no point in making this change unless it's going to be
> backported to Java 8.
Also don't forget that releasing VarHandle API as a public API for 9 is vastly different from replacing all usages of Unsafe by some VarHandle methods inside the JDK, see Paul's answser about the bootstrap issues. 

Rémi