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

[Mandy Chung]

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.

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