RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

Paul Sandoz paul.sandoz at oracle.com
Wed Apr 6 14:09:14 UTC 2016


> On 6 Apr 2016, at 15:28, 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.
> 
I still remain unconvinced in this case that such changes warrant an increase in unsafe usage (temporary or otherwise).

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

VHs are now in jdk9/dev. I dunno when it will rise up to the master and the next EA build.

Paul.



More information about the core-libs-dev mailing list