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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Oct 4 16:06:54 PDT 2012



Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8000263
> 8000263: JSR 292: signature types may appear to be unloaded
> Reviewed-by:
> 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++.
> src/share/vm/classfile/systemDictionary.cpp
> src/share/vm/classfile/systemDictionary.hpp
> src/share/vm/opto/library_call.cpp
> src/share/vm/runtime/globals.hpp

More information about the hotspot-compiler-dev mailing list