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

dean.long at oracle.com dean.long at oracle.com
Thu Nov 1 21:34:33 UTC 2018


On 11/1/18 1:45 PM, Mandy Chung wrote:
>
>
> On 11/1/18 1:18 AM, Vladimir Ivanov wrote:
>>
>>> I think it's a good idea, but I believe it would require a CSR 
>>> request. Do you mind if I file a separate issue for 
>>> jdk.internal.vm.annotation.Hidden?
>>
>> Sure.
>>
>> Most of the annotations in jdk.internal.vm.annotation were originally 
>> located in java.lang.invoke. Not sure CSR will be required in this 
>> particular case.
>>
>
> @Hidden is internal and no CSR is needed.
>
> FYI.  JDK-8212620 is the RFE to consider providing a standard 
> mechanism to hide frames from stack trace.
>

OK, I already filed JDK-8213234 but I think I should just close it as a 
duplicate of JDK-8212620.

dl

> Mandy
>
>> Best regards,
>> Vladimir Ivanov
>>
>>> On 10/31/18 6:11 PM, Vladimir Ivanov wrote:
>>>> Dean,
>>>>
>>>> src/java.base/share/classes/java/security/AccessController.java:
>>>> +    /**
>>>> +     * Internal marker for hidden implementation frames.
>>>> +     */
>>>> +    /*non-public*/
>>>> +    @Target(ElementType.METHOD)
>>>> +    @Retention(RetentionPolicy.RUNTIME)
>>>> +    @interface Hidden {
>>>> +    }
>>>>
>>>> You declare @Hidden, but then map it to _method_Hidden along with 
>>>> @Hidden from java.lang.invoke.LambdaForm.
>>>>
>>>> What do you think about moving LambdaForm.Hidden to 
>>>> jdk.internal.vm.annotation instead and share among all usages?
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 31/10/2018 15:23, 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 
>>>>>
>>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181101/fe68e240/attachment.htm>


More information about the security-dev mailing list