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