> On 6 Apr 2016, at 12:10, 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 09:37:00 >> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of >> AtomicReferenceFieldUpdater with Unsafe >> >> >>> On 5 Apr 2016, at 17:15, Claes Redestad <claes.redes...@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. > 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. >> >>>>> >>>>> -Aleksey >>>> It is surprising to see new uses of Unsafe when we have an ongoing >>>> initiative within openjdk (especially from Paul Sandoz) to remove most >>>> uses. Varhandles are coming and are expected to replace uses of >>>> Unsafe in the JDK. >>> >>> This is just a very minor win on hello world/-version style tests, so I'm >>> happy to withdraw this if other early usages, such as CHM, is moving to >>> VarHandles anyhow. >>> >>> OTOH using dangerous, internal APIs like this rather than nice, public APIs >>> early in the VM bootstrap has other merits, such as not unintentionally >>> causing bootstrap issues. Say, I don't know if VarHandles have any >>> dependencies on java.lang.invoke currently… >> >> It does, but was designed to be minimize bootstrap issues and class spinning >> so there are less dependencies than MHs. >> >> CHM is a tricky class because MethodType uses CHM and VHs uses MethodType. >> There is probably a way of switching from a less concurrent concurrent map >> to CHM at “safe-point” when the VM transitions to booted. To be >> investigated... > > another solution is perhaps to not use a concurrent hashmap in MethodType, > method types need to be interned only the first time a method handle is > invoked with an invokeExact/invoke (but not by invokedynamic) so instead of > interning all method types which artificially put pressure on the interning > map to be lock free, interning only the method type when need it may allow to > not use a CHM in MethodType. > I need to re-familiarise myself with the code to see what is possible here. MethodType also comes with a shared erased form which also caches LambdaForms for various kinds. It’s not clear to me if this can be easily be teased apart. Paul.
