1.1 --- a/src/share/vm/classfile/systemDictionary.cpp Thu Mar 19 09:13:24 2009 -0700
1.2 +++ b/src/share/vm/classfile/systemDictionary.cpp Fri Mar 20 23:19:36 2009 -0700
1.3 @@ -1964,6 +1964,13 @@
1.4 return T_OBJECT;
1.5 }
1.6
1.7 +KlassHandle SystemDictionaryHandles::box_klass(BasicType t) {
1.8 + if (t >= T_BOOLEAN && t <= T_VOID)
1.9 + return KlassHandle(&SystemDictionary::_box_klasses[t], true);
1.10 + else
1.11 + return KlassHandle();
1.12 +}
1.13 +
1.14 // Constraints on class loaders. The details of the algorithm can be
1.15 // found in the OOPSLA'98 paper "Dynamic Class Loading in the Java
1.16 // Virtual Machine" by Sheng Liang and Gilad Bracha. The basic idea is
1.17 @@ -2174,11 +2181,56 @@
1.18 }
1.19
1.20
1.21 +// Signature constraints ensure that callers and callees agree about
1.22 +// the meaning of type names in their signatures. This routine is the
1.23 +// intake for constraints. It collects them from several places:
1.24 +//
1.25 +// * LinkResolver::resolve_method (if check_access is true) requires
1.26 +// that the resolving class (the caller) and the defining class of
1.27 +// the resolved method (the callee) agree on each type in the
1.28 +// method's signature.
1.29 +//
1.30 +// * LinkResolver::resolve_interface_method performs exactly the same
1.31 +// checks.
1.32 +//
1.33 +// * LinkResolver::resolve_field requires that the constant pool
1.34 +// attempting to link to a field agree with the field's defining
1.35 +// class about the type of the field signature.
1.36 +//
1.37 +// * klassVtable::initialize_vtable requires that, when a class
1.38 +// overrides a vtable entry allocated by a superclass, that the
1.39 +// overriding method (i.e., the callee) agree with the superclass
1.40 +// on each type in the method's signature.
1.41 +//
1.42 +// * klassItable::initialize_itable requires that, when a class fills
1.43 +// in its itables, for each non-abstract method installed in an
1.44 +// itable, the method (i.e., the callee) agree with the interface
1.45 +// on each type in the method's signature.
1.46 +//
1.47 +// All those methods have a boolean (check_access, checkconstraints)
1.48 +// which turns off the checks. This is used from specialized contexts
1.49 +// such as bootstrapping, dumping, and debugging.
1.50 +//
1.51 +// No direct constraint is placed between the class and its
1.52 +// supertypes. Constraints are only placed along linked relations
1.53 +// between callers and callees. When a method overrides or implements
1.54 +// an abstract method in a supertype (superclass or interface), the
1.55 +// constraints are placed as if the supertype were the caller to the
1.56 +// overriding method. (This works well, since callers to the
1.57 +// supertype have already established agreement between themselves and
1.58 +// the supertype.) As a result of all this, a class can disagree with
1.59 +// its supertype about the meaning of a type name, as long as that
1.60 +// class neither calls a relevant method of the supertype, nor is
1.61 +// called (perhaps via an override) from the supertype.
1.62 +//
1.63 +//
1.64 +// SystemDictionary::check_signature_loaders(sig, l1, l2)
1.65 +//
1.66 // Make sure all class components (including arrays) in the given
1.67 // signature will be resolved to the same class in both loaders.
1.68 // Returns the name of the type that failed a loader constraint check, or
1.69 // NULL if no constraint failed. The returned C string needs cleaning up
1.70 -// with a ResourceMark in the caller
1.71 +// with a ResourceMark in the caller. No exception except OOME is thrown.
1.72 char* SystemDictionary::check_signature_loaders(symbolHandle signature,
1.73 Handle loader1, Handle loader2,
1.74 bool is_method, TRAPS) {
