RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged
dean.long at oracle.com
dean.long at oracle.com
Fri Nov 2 21:09:45 UTC 2018
Thanks Mandy. I also appreciate you noticing (off-list) that I can
remove the extra space in "Class <?>" in several places. I have updated
webrev.4 in place.
dl
On 11/2/18 1:55 PM, Mandy Chung wrote:
> 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.
>
> Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181102/7ebc0aae/attachment.htm>
More information about the security-dev
mailing list