Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject::<clinit>
David Holmes
david.holmes at oracle.com
Mon Jul 22 06:19:00 UTC 2019
Hi Mandy,
This approach looks much cleaner and safer to me, and the slight
shuffling in the init order should not cause any startup issues.
Thanks,
David
-----
On 20/07/2019 2:20 am, Mandy Chung wrote:
> This was a follow up to the observation during the code review
> of JDK-82193798.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.01/
>
> In the current implementation, Modifier::<clinit> provides a hook
> to initialize the static ReflectionFactory::langReflectAccess field
> lazily. This was introduced prior to the common shared secrets
> mechanism.
>
> Another observation is that when ReflectionFactory methods are called,
> there is a Method, Field or Constructor object in hand. In addition,
> Method class is initialized very early during startup by the VM and
> so does AccessibleObject class. The ReflectionFactory::newField and
> newMethod taking the Field/Method parameter are used but not the
> one without (dead code).
>
> This patch cleans up the initialization of LangReflectAccess to
> AccessibleObject::<clinit> during early startup initPhase1.
> I also move LangReflectAccess to jdk.internal.access to be consistent
> with other *Access classes (LangReflectAccess was added before the common
> SharedSecrets class was introduced).
>
> This also addresses JDK-8227831 the overhead of langReflectAcces being
> a volatile field on the platform with weak memory model (Thanks to
> Ogata confirming that this patch is 4% better than the proposed patch
> for JDK-8227831 [1]).
>
> The impact to the class initialization order is minimal.
> JavaLangReflectAccess
> is initialized during initPhase1 (which has been initialized during
> initPhase2).
> SharedSecrets is initialized in initPhase2 and this patch moves it to be
> initialized followed AccessibleObject.
>
> Mandy
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061352.html
More information about the core-libs-dev
mailing list