RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged
Mandy Chung
mandy.chung at oracle.com
Thu Nov 1 20:45:37 UTC 2018
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
>>>>
>>>>
>>
More information about the hotspot-dev
mailing list