RFR (S): 8000263: JSR 292: signature types may appear to be unloaded
vladimir.kozlov at oracle.com
Thu Oct 4 16:06:54 PDT 2012
Christian Thalinger wrote:
> 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