Question about Reflection details

Thomas Stüfe thomas.stuefe at
Tue May 15 10:06:33 UTC 2018

Hi all,

I have two questions about the non-native reflection mechanism in the VM:

1) For each method invocation we generate a new child class of
internal.reflect.MagicAccessorImpl, which is loaded by its own
instance of DelegatingClassLoader.

The comment in jdk.internal.reflect.ClassDefiner states the reasons for this:

There are two primary reasons for creating a new loader
instead of defining these bytecodes directly into the defining
loader of the target class: first, it avoids any possible
security risk of having these bytecodes in the same loader.
Second, it allows the generated bytecodes to be unloaded earlier
than would otherwise be possible, decreasing run-time

Do I understand this correctly:

the lifetime of the MagicAccessorImpl instance, its class and its
loading DelegatingClassLoader are defined by the lifetime of the
java.lang.reflect.Method/Constructor object which keeps the
MagicAccessorImpl instance in its methodAccessor/constructorAccessor

So, if that Method/Constructor object is collected, its
MagicAccessorImpl instance is collected, and since it is the only
instance its class too, and since it is the only class in that
DelegatingClassLoader that gets collected as well?

2) I see in my traces that for each Method.invoke( we generate
  - one GeneratedMethodAccessorImplXXX class living in its own
DelegatingClassLoader instance, which invokes
  - and then one additional GeneratedConstructorAccessorXXX, again
living in its very own DelegatingClassLoader instance, which invokes
the constructor for the just generated GeneratedMethodAccessorImplXXX.

The latter I see only if I switch off inflation. The very first (and
only) time GeneratedMethodAccessorImplXXX is instantiated it will
cause GeneratedConstructorAccessorXXX to be created for that one
newInstance() call.

But surely, in that case we could save one class loader and let the
GeneratedConstructorAccessorXXX get loaded by the
DelegatingClassLoader which also loaded the associated
GeneratedMethodAccessorImplXXX? Or is it too much bother, since we are
in an artificial scenario (noInflation=true)?


In general, I have the following question:

Will the 1:1 relationship between MagicAccessorImpl class and
DelegatingClassLoader instance always hold true?

Or is there work in progress somewhere which would maybe bundle
MagicAccessorImpl classes in one loader (e.g. (2) would be a candidate
for this), or maybe do it without loaders?



More information about the hotspot-runtime-dev mailing list