Hi all, Redirecting my question to core-libs as suggested by David.
Thanks, Thomas ---------- Forwarded message ---------- From: Thomas Stüfe <thomas.stu...@gmail.com> Date: Tue, May 15, 2018 at 12:06 PM Subject: Question about Reflection details To: Hotspot dev runtime <hotspot-runtime-...@openjdk.java.net> 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: <quote> 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 footprint. </quote> 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 field? 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(obj.foo()) we generate - one GeneratedMethodAccessorImplXXX class living in its own DelegatingClassLoader instance, which invokes obj.foo - 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? Thanks! Thomas
