Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject::<clinit>

Mandy Chung mandy.chung at
Fri Jul 19 16:20:37 UTC 2019

This was a follow up to the observation during the code review
of JDK-82193798.


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

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. 
is initialized during initPhase1 (which has been initialized during 
SharedSecrets is initialized in initPhase2 and this patch moves it to be
initialized followed AccessibleObject.


More information about the core-libs-dev mailing list