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
