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
Good.
Thanks,
Vladimir
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