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