RFR (S): 8000263: JSR 292: signature types may appear to be unloaded

Christian Thalinger christian.thalinger at oracle.com
Thu Oct 4 15:51:09 PDT 2012


8000263: JSR 292: signature types may appear to be unloaded

The problem is in the intrinsification code for Unsafe.getObject.
Usually field accesses with get/putfield resolve the field when
parsing the bytecode.  ciBytecodeStream::get_field calls
ciField::will_link which puts class loader constraints for the
signature types in place.  In LibraryCallKit::inline_unsafe_access we
create a ciField object for the field we are accessing but with the
ciField's type left uninitialized. When calling ciField::type we try
to look up the field type lazily which fails because we never resolved
the field and put class loader constraints in place.

There are two ways to fix it.  The first one is two return
java/lang/Object as field type if the computed type is unloaded.  The
second fix is to turn on LinkWellKnowClasses by default.
LinkWellKnownClasses only works if the field type is java/lang/Object,
for user types we need to other fix.

The change also renames the WK_KLASSES_DO macro argument template with
do_klass because template is a reserved keyword in C++.


More information about the hotspot-compiler-dev mailing list