RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged

Mandy Chung mandy.chung at oracle.com
Fri Nov 2 20:55:29 UTC 2018

Hi Dean,

I reviewed webrev.4 version.  It looks good.  Happy to see moving the 
doPrivileged support to Java and the performance improvement.

On 10/31/18 3:23 PM, dean.long at oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8212605
> http://cr.openjdk.java.net/~dlong/8212605/webrev.1
> This change implements AccessController.doPrivileged in Java. This 
> gives a performance improvement while also being useful to Project 
> Loom by removing the Java --> native --> Java transition.  One reason 
> doPrivileged has historically been in native is because of the need to 
> guarantee the cleanup of the privileged context when doPrivileged 
> returns.  To do that in Java, the information that 
> AccessController.getContext needs is pushed onto the Java stack as 
> arguments to a method that getContext will recognize during its stack 
> walk.  This allows us to remove the native privileged stack while 
> guaranteeing that the privileged context goes away when the method 
> returns.
> Tested with tier1-tier3 hotspot and jdk tests and JCK 
> api/java_security tests.  For the first few rounds of testing, I kept 
> the old native privileged stack and compared the results of the old 
> and new implementations for each getContext call, which did catch some 
> early bugs.  The changes were also examined by internal security 
> experts and run through additional internal security tests.
> The improvement on this [1] doPrivileged microbenchmark is approximate 
> 50x.
> There is no attempt to optimize getContext() or security permission 
> checks in this change, however, this is intended to be a first step 
> towards other possible improvements, for example those proposed here [2].

FYI.  Sean and I also did some experiment to replace 
JVM_GetStackAccessControlContext with StackWalker some time ago. Another 
potential area to move the code from VM to Java for the future as David 
explored and probably involves  performance work in the stack walker.


More information about the core-libs-dev mailing list