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

dean.long at oracle.com dean.long at oracle.com
Thu Nov 1 19:11:02 UTC 2018


On 11/1/18 10:01 AM, Sean Mullan wrote:
> Some of the copyrights need to be updated to 2018.
>

Fixed.

> All else looks good to me as I had reviewed an earlier version of this 
> before. We have talked about doing this for a while now, so I am 
> finally glad we and are able to pretty much eliminate one of the more 
> common SecurityManager related hot-spots and give a performance boost 
> to applications that don't use the SM as well.
>

Thanks Sean.

dl

> --Sean
>
> On 10/31/18 6: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].
>>
>> dl
>>
>> [1] 
>> http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java 
>>
>> [2] 
>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html 
>>
>>




More information about the security-dev mailing list