----- Mail original ----- > De: "Vitaly Davidovich" <vita...@gmail.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Paul Sandoz" <paul.san...@oracle.com>, "core-libs-dev Libs" > <core-libs-dev@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 < fo...@univ-mlv.fr > wrote: > > ----- Mail original ----- > > > > De: "Paul Sandoz" < paul.san...@oracle.com > > > > > Cc: "core-libs-dev Libs" < core-libs-dev@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 < fo...@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
