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

[Vladimir Ivanov]

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

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