RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Vitaly Davidovich]

On Wednesday, April 6, 2016, Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Mail original -----
> > De: "Paul Sandoz" <paul.sandoz at oracle.com <javascript:;>>
> > Cc: "core-libs-dev Libs" <core-libs-dev at openjdk.java.net <javascript:;>>
> > 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 <javascript:;>>
> wrote:
> > >
> > > ----- Mail original -----
> > >> De: "Paul Sandoz" <paul.sandoz at oracle.com <javascript:;>>
> > >> Cc: "core-libs-dev Libs" <core-libs-dev at openjdk.java.net
> <javascript:;>>
> > >> 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
> <javascript:;>>
> > >>> 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),

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

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
>


-- 
Sent from my phone