1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/src/share/vm/prims/jvmtiRedefineClasses.hpp Sat Dec 01 00:00:00 2007 +0000
1.3 @@ -0,0 +1,489 @@
1.4 +/*
1.5 + * Copyright 2003-2006 Sun Microsystems, Inc. All Rights Reserved.
1.6 + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
1.7 + *
1.8 + * This code is free software; you can redistribute it and/or modify it
1.9 + * under the terms of the GNU General Public License version 2 only, as
1.10 + * published by the Free Software Foundation.
1.11 + *
1.12 + * This code is distributed in the hope that it will be useful, but WITHOUT
1.13 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
1.14 + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
1.15 + * version 2 for more details (a copy is included in the LICENSE file that
1.16 + * accompanied this code).
1.17 + *
1.18 + * You should have received a copy of the GNU General Public License version
1.19 + * 2 along with this work; if not, write to the Free Software Foundation,
1.20 + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
1.21 + *
1.22 + * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
1.23 + * CA 95054 USA or visit www.sun.com if you need additional information or
1.24 + * have any questions.
1.25 + *
1.26 + */
1.27 +
1.28 +// Introduction:
1.29 +//
1.30 +// The RedefineClasses() API is used to change the definition of one or
1.31 +// more classes. While the API supports redefining more than one class
1.32 +// in a single call, in general, the API is discussed in the context of
1.33 +// changing the definition of a single current class to a single new
1.34 +// class. For clarity, the current class is will always be called
1.35 +// "the_class" and the new class will always be called "scratch_class".
1.36 +//
1.37 +// The name "the_class" is used because there is only one structure
1.38 +// that represents a specific class; redefinition does not replace the
1.39 +// structure, but instead replaces parts of the structure. The name
1.40 +// "scratch_class" is used because the structure that represents the
1.41 +// new definition of a specific class is simply used to carry around
1.42 +// the parts of the new definition until they are used to replace the
1.43 +// appropriate parts in the_class. Once redefinition of a class is
1.44 +// complete, scratch_class is thrown away.
1.45 +//
1.46 +//
1.47 +// Implementation Overview:
1.48 +//
1.49 +// The RedefineClasses() API is mostly a wrapper around the VM op that
1.50 +// does the real work. The work is split in varying degrees between
1.51 +// doit_prologue(), doit() and doit_epilogue().
1.52 +//
1.53 +// 1) doit_prologue() is called by the JavaThread on the way to a
1.54 +// safepoint. It does parameter verification and loads scratch_class
1.55 +// which involves:
1.56 +// - parsing the incoming class definition using the_class' class
1.57 +// loader and security context
1.58 +// - linking scratch_class
1.59 +// - merging constant pools and rewriting bytecodes as needed
1.60 +// for the merged constant pool
1.61 +// - verifying the bytecodes in scratch_class
1.62 +// - setting up the constant pool cache and rewriting bytecodes
1.63 +// as needed to use the cache
1.64 +// - finally, scratch_class is compared to the_class to verify
1.65 +// that it is a valid replacement class
1.66 +// - if everything is good, then scratch_class is saved in an
1.67 +// instance field in the VM operation for the doit() call
1.68 +//
1.69 +// Note: A JavaThread must do the above work.
1.70 +//
1.71 +// 2) doit() is called by the VMThread during a safepoint. It installs
1.72 +// the new class definition(s) which involves:
1.73 +// - retrieving the scratch_class from the instance field in the
1.74 +// VM operation
1.75 +// - house keeping (flushing breakpoints and caches, deoptimizing
1.76 +// dependent compiled code)
1.77 +// - replacing parts in the_class with parts from scratch_class
1.78 +// - adding weak reference(s) to track the obsolete but interesting
1.79 +// parts of the_class
1.80 +// - adjusting constant pool caches and vtables in other classes
1.81 +// that refer to methods in the_class. These adjustments use the
1.82 +// SystemDictionary::classes_do() facility which only allows
1.83 +// a helper method to be specified. The interesting parameters
1.84 +// that we would like to pass to the helper method are saved in
1.85 +// static global fields in the VM operation.
1.86 +// - telling the SystemDictionary to notice our changes
1.87 +//
1.88 +// Note: the above work must be done by the VMThread to be safe.
1.89 +//
1.90 +// 3) doit_epilogue() is called by the JavaThread after the VM op
1.91 +// is finished and the safepoint is done. It simply cleans up
1.92 +// memory allocated in doit_prologue() and used in doit().
1.93 +//
1.94 +//
1.95 +// Constant Pool Details:
1.96 +//
1.97 +// When the_class is redefined, we cannot just replace the constant
1.98 +// pool in the_class with the constant pool from scratch_class because
1.99 +// that could confuse obsolete methods that may still be running.
1.100 +// Instead, the constant pool from the_class, old_cp, is merged with
1.101 +// the constant pool from scratch_class, scratch_cp. The resulting
1.102 +// constant pool, merge_cp, replaces old_cp in the_class.
1.103 +//
1.104 +// The key part of any merging algorithm is the entry comparison
1.105 +// function so we have to know the types of entries in a constant pool
1.106 +// in order to merge two of them together. Constant pools can contain
1.107 +// up to 12 different kinds of entries; the JVM_CONSTANT_Unicode entry
1.108 +// is not presently used so we only have to worry about the other 11
1.109 +// entry types. For the purposes of constant pool merging, it is
1.110 +// helpful to know that the 11 entry types fall into 3 different
1.111 +// subtypes: "direct", "indirect" and "double-indirect".
1.112 +//
1.113 +// Direct CP entries contain data and do not contain references to
1.114 +// other CP entries. The following are direct CP entries:
1.115 +// JVM_CONSTANT_{Double,Float,Integer,Long,Utf8}
1.116 +//
1.117 +// Indirect CP entries contain 1 or 2 references to a direct CP entry
1.118 +// and no other data. The following are indirect CP entries:
1.119 +// JVM_CONSTANT_{Class,NameAndType,String}
1.120 +//
1.121 +// Double-indirect CP entries contain two references to indirect CP
1.122 +// entries and no other data. The following are double-indirect CP
1.123 +// entries:
1.124 +// JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref}
1.125 +//
1.126 +// When comparing entries between two constant pools, the entry types
1.127 +// are compared first and if they match, then further comparisons are
1.128 +// made depending on the entry subtype. Comparing direct CP entries is
1.129 +// simply a matter of comparing the data associated with each entry.
1.130 +// Comparing both indirect and double-indirect CP entries requires
1.131 +// recursion.
1.132 +//
1.133 +// Fortunately, the recursive combinations are limited because indirect
1.134 +// CP entries can only refer to direct CP entries and double-indirect
1.135 +// CP entries can only refer to indirect CP entries. The following is
1.136 +// an example illustration of the deepest set of indirections needed to
1.137 +// access the data associated with a JVM_CONSTANT_Fieldref entry:
1.138 +//
1.139 +// JVM_CONSTANT_Fieldref {
1.140 +// class_index => JVM_CONSTANT_Class {
1.141 +// name_index => JVM_CONSTANT_Utf8 {
1.142 +// <data-1>
1.143 +// }
1.144 +// }
1.145 +// name_and_type_index => JVM_CONSTANT_NameAndType {
1.146 +// name_index => JVM_CONSTANT_Utf8 {
1.147 +// <data-2>
1.148 +// }
1.149 +// descriptor_index => JVM_CONSTANT_Utf8 {
1.150 +// <data-3>
1.151 +// }
1.152 +// }
1.153 +// }
1.154 +//
1.155 +// The above illustration is not a data structure definition for any
1.156 +// computer language. The curly braces ('{' and '}') are meant to
1.157 +// delimit the context of the "fields" in the CP entry types shown.
1.158 +// Each indirection from the JVM_CONSTANT_Fieldref entry is shown via
1.159 +// "=>", e.g., the class_index is used to indirectly reference a
1.160 +// JVM_CONSTANT_Class entry where the name_index is used to indirectly
1.161 +// reference a JVM_CONSTANT_Utf8 entry which contains the interesting
1.162 +// <data-1>. In order to understand a JVM_CONSTANT_Fieldref entry, we
1.163 +// have to do a total of 5 indirections just to get to the CP entries
1.164 +// that contain the interesting pieces of data and then we have to
1.165 +// fetch the three pieces of data. This means we have to do a total of
1.166 +// (5 + 3) * 2 == 16 dereferences to compare two JVM_CONSTANT_Fieldref
1.167 +// entries.
1.168 +//
1.169 +// Here is the indirection, data and dereference count for each entry
1.170 +// type:
1.171 +//
1.172 +// JVM_CONSTANT_Class 1 indir, 1 data, 2 derefs
1.173 +// JVM_CONSTANT_Double 0 indir, 1 data, 1 deref
1.174 +// JVM_CONSTANT_Fieldref 2 indir, 3 data, 8 derefs
1.175 +// JVM_CONSTANT_Float 0 indir, 1 data, 1 deref
1.176 +// JVM_CONSTANT_Integer 0 indir, 1 data, 1 deref
1.177 +// JVM_CONSTANT_InterfaceMethodref 2 indir, 3 data, 8 derefs
1.178 +// JVM_CONSTANT_Long 0 indir, 1 data, 1 deref
1.179 +// JVM_CONSTANT_Methodref 2 indir, 3 data, 8 derefs
1.180 +// JVM_CONSTANT_NameAndType 1 indir, 2 data, 4 derefs
1.181 +// JVM_CONSTANT_String 1 indir, 1 data, 2 derefs
1.182 +// JVM_CONSTANT_Utf8 0 indir, 1 data, 1 deref
1.183 +//
1.184 +// So different subtypes of CP entries require different amounts of
1.185 +// work for a proper comparison.
1.186 +//
1.187 +// Now that we've talked about the different entry types and how to
1.188 +// compare them we need to get back to merging. This is not a merge in
1.189 +// the "sort -u" sense or even in the "sort" sense. When we merge two
1.190 +// constant pools, we copy all the entries from old_cp to merge_cp,
1.191 +// preserving entry order. Next we append all the unique entries from
1.192 +// scratch_cp to merge_cp and we track the index changes from the
1.193 +// location in scratch_cp to the possibly new location in merge_cp.
1.194 +// When we are done, any obsolete code that is still running that
1.195 +// uses old_cp should not be able to observe any difference if it
1.196 +// were to use merge_cp. As for the new code in scratch_class, it is
1.197 +// modified to use the appropriate index values in merge_cp before it
1.198 +// is used to replace the code in the_class.
1.199 +//
1.200 +// There is one small complication in copying the entries from old_cp
1.201 +// to merge_cp. Two of the CP entry types are special in that they are
1.202 +// lazily resolved. Before explaining the copying complication, we need
1.203 +// to digress into CP entry resolution.
1.204 +//
1.205 +// JVM_CONSTANT_Class and JVM_CONSTANT_String entries are present in
1.206 +// the class file, but are not stored in memory as such until they are
1.207 +// resolved. The entries are not resolved unless they are used because
1.208 +// resolution is expensive. During class file parsing the entries are
1.209 +// initially stored in memory as JVM_CONSTANT_ClassIndex and
1.210 +// JVM_CONSTANT_StringIndex entries. These special CP entry types
1.211 +// indicate that the JVM_CONSTANT_Class and JVM_CONSTANT_String entries
1.212 +// have been parsed, but the index values in the entries have not been
1.213 +// validated. After the entire constant pool has been parsed, the index
1.214 +// values can be validated and then the entries are converted into
1.215 +// JVM_CONSTANT_UnresolvedClass and JVM_CONSTANT_UnresolvedString
1.216 +// entries. During this conversion process, the UTF8 values that are
1.217 +// indirectly referenced by the JVM_CONSTANT_ClassIndex and
1.218 +// JVM_CONSTANT_StringIndex entries are changed into symbolOops and the
1.219 +// entries are modified to refer to the symbolOops. This optimization
1.220 +// eliminates one level of indirection for those two CP entry types and
1.221 +// gets the entries ready for verification. During class file parsing
1.222 +// it is also possible for JVM_CONSTANT_UnresolvedString entries to be
1.223 +// resolved into JVM_CONSTANT_String entries. Verification expects to
1.224 +// find JVM_CONSTANT_UnresolvedClass and either JVM_CONSTANT_String or
1.225 +// JVM_CONSTANT_UnresolvedString entries and not JVM_CONSTANT_Class
1.226 +// entries.
1.227 +//
1.228 +// Now we can get back to the copying complication. When we copy
1.229 +// entries from old_cp to merge_cp, we have to revert any
1.230 +// JVM_CONSTANT_Class entries to JVM_CONSTANT_UnresolvedClass entries
1.231 +// or verification will fail.
1.232 +//
1.233 +// It is important to explicitly state that the merging algorithm
1.234 +// effectively unresolves JVM_CONSTANT_Class entries that were in the
1.235 +// old_cp when they are changed into JVM_CONSTANT_UnresolvedClass
1.236 +// entries in the merge_cp. This is done both to make verification
1.237 +// happy and to avoid adding more brittleness between RedefineClasses
1.238 +// and the constant pool cache. By allowing the constant pool cache
1.239 +// implementation to (re)resolve JVM_CONSTANT_UnresolvedClass entries
1.240 +// into JVM_CONSTANT_Class entries, we avoid having to embed knowledge
1.241 +// about those algorithms in RedefineClasses.
1.242 +//
1.243 +// Appending unique entries from scratch_cp to merge_cp is straight
1.244 +// forward for direct CP entries and most indirect CP entries. For the
1.245 +// indirect CP entry type JVM_CONSTANT_NameAndType and for the double-
1.246 +// indirect CP entry types, the presence of more than one piece of
1.247 +// interesting data makes appending the entries more complicated.
1.248 +//
1.249 +// For the JVM_CONSTANT_{Double,Float,Integer,Long,Utf8} entry types,
1.250 +// the entry is simply copied from scratch_cp to the end of merge_cp.
1.251 +// If the index in scratch_cp is different than the destination index
1.252 +// in merge_cp, then the change in index value is tracked.
1.253 +//
1.254 +// Note: the above discussion for the direct CP entries also applies
1.255 +// to the JVM_CONSTANT_Unresolved{Class,String} entry types.
1.256 +//
1.257 +// For the JVM_CONSTANT_{Class,String} entry types, since there is only
1.258 +// one data element at the end of the recursion, we know that we have
1.259 +// either one or two unique entries. If the JVM_CONSTANT_Utf8 entry is
1.260 +// unique then it is appended to merge_cp before the current entry.
1.261 +// If the JVM_CONSTANT_Utf8 entry is not unique, then the current entry
1.262 +// is updated to refer to the duplicate entry in merge_cp before it is
1.263 +// appended to merge_cp. Again, any changes in index values are tracked
1.264 +// as needed.
1.265 +//
1.266 +// Note: the above discussion for JVM_CONSTANT_{Class,String} entry
1.267 +// types is theoretical. Since those entry types have already been
1.268 +// optimized into JVM_CONSTANT_Unresolved{Class,String} entry types,
1.269 +// they are handled as direct CP entries.
1.270 +//
1.271 +// For the JVM_CONSTANT_NameAndType entry type, since there are two
1.272 +// data elements at the end of the recursions, we know that we have
1.273 +// between one and three unique entries. Any unique JVM_CONSTANT_Utf8
1.274 +// entries are appended to merge_cp before the current entry. For any
1.275 +// JVM_CONSTANT_Utf8 entries that are not unique, the current entry is
1.276 +// updated to refer to the duplicate entry in merge_cp before it is
1.277 +// appended to merge_cp. Again, any changes in index values are tracked
1.278 +// as needed.
1.279 +//
1.280 +// For the JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref} entry
1.281 +// types, since there are two indirect CP entries and three data
1.282 +// elements at the end of the recursions, we know that we have between
1.283 +// one and six unique entries. See the JVM_CONSTANT_Fieldref diagram
1.284 +// above for an example of all six entries. The uniqueness algorithm
1.285 +// for the JVM_CONSTANT_Class and JVM_CONSTANT_NameAndType entries is
1.286 +// covered above. Any unique entries are appended to merge_cp before
1.287 +// the current entry. For any entries that are not unique, the current
1.288 +// entry is updated to refer to the duplicate entry in merge_cp before
1.289 +// it is appended to merge_cp. Again, any changes in index values are
1.290 +// tracked as needed.
1.291 +//
1.292 +//
1.293 +// Other Details:
1.294 +//
1.295 +// Details for other parts of RedefineClasses need to be written.
1.296 +// This is a placeholder section.
1.297 +//
1.298 +//
1.299 +// Open Issues (in no particular order):
1.300 +//
1.301 +// - How do we serialize the RedefineClasses() API without deadlocking?
1.302 +//
1.303 +// - SystemDictionary::parse_stream() was called with a NULL protection
1.304 +// domain since the initial version. This has been changed to pass
1.305 +// the_class->protection_domain(). This change has been tested with
1.306 +// all NSK tests and nothing broke, but what will adding it now break
1.307 +// in ways that we don't test?
1.308 +//
1.309 +// - GenerateOopMap::rewrite_load_or_store() has a comment in its
1.310 +// (indirect) use of the Relocator class that the max instruction
1.311 +// size is 4 bytes. goto_w and jsr_w are 5 bytes and wide/iinc is
1.312 +// 6 bytes. Perhaps Relocator only needs a 4 byte buffer to do
1.313 +// what it does to the bytecodes. More investigation is needed.
1.314 +//
1.315 +// - java.lang.Object methods can be called on arrays. This is
1.316 +// implemented via the arrayKlassOop vtable which we don't
1.317 +// update. For example, if we redefine java.lang.Object.toString(),
1.318 +// then the new version of the method will not be called for array
1.319 +// objects.
1.320 +//
1.321 +// - How do we know if redefine_single_class() and the guts of
1.322 +// instanceKlass are out of sync? I don't think this can be
1.323 +// automated, but we should probably order the work in
1.324 +// redefine_single_class() to match the order of field
1.325 +// definitions in instanceKlass. We also need to add some
1.326 +// comments about keeping things in sync.
1.327 +//
1.328 +// - set_new_constant_pool() is huge and we should consider refactoring
1.329 +// it into smaller chunks of work.
1.330 +//
1.331 +// - The exception table update code in set_new_constant_pool() defines
1.332 +// const values that are also defined in a local context elsewhere.
1.333 +// The same literal values are also used in elsewhere. We need to
1.334 +// coordinate a cleanup of these constants with Runtime.
1.335 +//
1.336 +
1.337 +class VM_RedefineClasses: public VM_Operation {
1.338 + private:
1.339 + // These static fields are needed by SystemDictionary::classes_do()
1.340 + // facility and the adjust_cpool_cache_and_vtable() helper:
1.341 + static objArrayOop _old_methods;
1.342 + static objArrayOop _new_methods;
1.343 + static methodOop* _matching_old_methods;
1.344 + static methodOop* _matching_new_methods;
1.345 + static methodOop* _deleted_methods;
1.346 + static methodOop* _added_methods;
1.347 + static int _matching_methods_length;
1.348 + static int _deleted_methods_length;
1.349 + static int _added_methods_length;
1.350 + static klassOop _the_class_oop;
1.351 +
1.352 + // The instance fields are used to pass information from
1.353 + // doit_prologue() to doit() and doit_epilogue().
1.354 + jint _class_count;
1.355 + const jvmtiClassDefinition *_class_defs; // ptr to _class_count defs
1.356 +
1.357 + // This operation is used by both RedefineClasses and
1.358 + // RetransformClasses. Indicate which.
1.359 + JvmtiClassLoadKind _class_load_kind;
1.360 +
1.361 + // _index_map_count is just an optimization for knowing if
1.362 + // _index_map_p contains any entries.
1.363 + int _index_map_count;
1.364 + intArray * _index_map_p;
1.365 + // ptr to _class_count scratch_classes
1.366 + instanceKlassHandle * _scratch_classes;
1.367 + jvmtiError _res;
1.368 +
1.369 + // Performance measurement support. These timers do not cover all
1.370 + // the work done for JVM/TI RedefineClasses() but they do cover
1.371 + // the heavy lifting.
1.372 + elapsedTimer _timer_rsc_phase1;
1.373 + elapsedTimer _timer_rsc_phase2;
1.374 + elapsedTimer _timer_vm_op_prologue;
1.375 +
1.376 + // These routines are roughly in call order unless otherwise noted.
1.377 +
1.378 + // Load the caller's new class definition(s) into _scratch_classes.
1.379 + // Constant pool merging work is done here as needed. Also calls
1.380 + // compare_and_normalize_class_versions() to verify the class
1.381 + // definition(s).
1.382 + jvmtiError load_new_class_versions(TRAPS);
1.383 +
1.384 + // Verify that the caller provided class definition(s) that meet
1.385 + // the restrictions of RedefineClasses. Normalize the order of
1.386 + // overloaded methods as needed.
1.387 + jvmtiError compare_and_normalize_class_versions(
1.388 + instanceKlassHandle the_class, instanceKlassHandle scratch_class);
1.389 +
1.390 + // Swap annotations[i] with annotations[j]
1.391 + // Used by compare_and_normalize_class_versions() when normalizing
1.392 + // overloaded methods or changing idnum as when adding or deleting methods.
1.393 + void swap_all_method_annotations(int i, int j, instanceKlassHandle scratch_class);
1.394 +
1.395 + // Figure out which new methods match old methods in name and signature,
1.396 + // which methods have been added, and which are no longer present
1.397 + void compute_added_deleted_matching_methods();
1.398 +
1.399 + // Change jmethodIDs to point to the new methods
1.400 + void update_jmethod_ids();
1.401 +
1.402 + // In addition to marking methods as obsolete, this routine
1.403 + // records which methods are EMCP (Equivalent Module Constant
1.404 + // Pool) in the emcp_methods BitMap and returns the number of
1.405 + // EMCP methods via emcp_method_count_p. This information is
1.406 + // used when information about the previous version of the_class
1.407 + // is squirreled away.
1.408 + void check_methods_and_mark_as_obsolete(BitMap *emcp_methods,
1.409 + int * emcp_method_count_p);
1.410 + void transfer_old_native_function_registrations(instanceKlassHandle the_class);
1.411 +
1.412 + // Unevolving classes may point to methods of the_class directly
1.413 + // from their constant pool caches, itables, and/or vtables. We
1.414 + // use the SystemDictionary::classes_do() facility and this helper
1.415 + // to fix up these pointers.
1.416 + static void adjust_cpool_cache_and_vtable(klassOop k_oop, oop loader, TRAPS);
1.417 +
1.418 + // Install the redefinition of a class
1.419 + void redefine_single_class(jclass the_jclass,
1.420 + instanceKlassHandle scratch_class, TRAPS);
1.421 +
1.422 + // Increment the classRedefinedCount field in the specific instanceKlass
1.423 + // and in all direct and indirect subclasses.
1.424 + void increment_class_counter(instanceKlass *ik, TRAPS);
1.425 +
1.426 + // Support for constant pool merging (these routines are in alpha
1.427 + // order):
1.428 + void append_entry(constantPoolHandle scratch_cp, int scratch_i,
1.429 + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
1.430 + int find_new_index(int old_index);
1.431 + bool is_unresolved_class_mismatch(constantPoolHandle cp1, int index1,
1.432 + constantPoolHandle cp2, int index2);
1.433 + bool is_unresolved_string_mismatch(constantPoolHandle cp1, int index1,
1.434 + constantPoolHandle cp2, int index2);
1.435 + void map_index(constantPoolHandle scratch_cp, int old_index, int new_index);
1.436 + bool merge_constant_pools(constantPoolHandle old_cp,
1.437 + constantPoolHandle scratch_cp, constantPoolHandle *merge_cp_p,
1.438 + int *merge_cp_length_p, TRAPS);
1.439 + jvmtiError merge_cp_and_rewrite(instanceKlassHandle the_class,
1.440 + instanceKlassHandle scratch_class, TRAPS);
1.441 + u2 rewrite_cp_ref_in_annotation_data(
1.442 + typeArrayHandle annotations_typeArray, int &byte_i_ref,
1.443 + const char * trace_mesg, TRAPS);
1.444 + bool rewrite_cp_refs(instanceKlassHandle scratch_class, TRAPS);
1.445 + bool rewrite_cp_refs_in_annotation_struct(
1.446 + typeArrayHandle class_annotations, int &byte_i_ref, TRAPS);
1.447 + bool rewrite_cp_refs_in_annotations_typeArray(
1.448 + typeArrayHandle annotations_typeArray, int &byte_i_ref, TRAPS);
1.449 + bool rewrite_cp_refs_in_class_annotations(
1.450 + instanceKlassHandle scratch_class, TRAPS);
1.451 + bool rewrite_cp_refs_in_element_value(
1.452 + typeArrayHandle class_annotations, int &byte_i_ref, TRAPS);
1.453 + bool rewrite_cp_refs_in_fields_annotations(
1.454 + instanceKlassHandle scratch_class, TRAPS);
1.455 + void rewrite_cp_refs_in_method(methodHandle method,
1.456 + methodHandle * new_method_p, TRAPS);
1.457 + bool rewrite_cp_refs_in_methods(instanceKlassHandle scratch_class, TRAPS);
1.458 + bool rewrite_cp_refs_in_methods_annotations(
1.459 + instanceKlassHandle scratch_class, TRAPS);
1.460 + bool rewrite_cp_refs_in_methods_default_annotations(
1.461 + instanceKlassHandle scratch_class, TRAPS);
1.462 + bool rewrite_cp_refs_in_methods_parameter_annotations(
1.463 + instanceKlassHandle scratch_class, TRAPS);
1.464 + void rewrite_cp_refs_in_stack_map_table(methodHandle method, TRAPS);
1.465 + void rewrite_cp_refs_in_verification_type_info(
1.466 + address& stackmap_addr_ref, address stackmap_end, u2 frame_i,
1.467 + u1 frame_size, TRAPS);
1.468 + void set_new_constant_pool(instanceKlassHandle scratch_class,
1.469 + constantPoolHandle scratch_cp, int scratch_cp_length, bool shrink, TRAPS);
1.470 +
1.471 + void flush_dependent_code(instanceKlassHandle k_h, TRAPS);
1.472 +
1.473 + static void check_class(klassOop k_oop, oop initiating_loader, TRAPS) PRODUCT_RETURN;
1.474 +
1.475 + static void dump_methods() PRODUCT_RETURN;
1.476 +
1.477 + public:
1.478 + VM_RedefineClasses(jint class_count,
1.479 + const jvmtiClassDefinition *class_defs,
1.480 + JvmtiClassLoadKind class_load_kind);
1.481 + VMOp_Type type() const { return VMOp_RedefineClasses; }
1.482 + bool doit_prologue();
1.483 + void doit();
1.484 + void doit_epilogue();
1.485 +
1.486 + bool allow_nested_vm_operations() const { return true; }
1.487 + jvmtiError check_error() { return _res; }
1.488 +
1.489 + // Modifiable test must be shared between IsModifiableClass query
1.490 + // and redefine implementation
1.491 + static bool is_modifiable_class(oop klass_mirror);
1.492 +};
