duke@435: /* trims@2708: * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. duke@435: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. duke@435: * duke@435: * This code is free software; you can redistribute it and/or modify it duke@435: * under the terms of the GNU General Public License version 2 only, as duke@435: * published by the Free Software Foundation. duke@435: * duke@435: * This code is distributed in the hope that it will be useful, but WITHOUT duke@435: * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or duke@435: * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License duke@435: * version 2 for more details (a copy is included in the LICENSE file that duke@435: * accompanied this code). duke@435: * duke@435: * You should have received a copy of the GNU General Public License version duke@435: * 2 along with this work; if not, write to the Free Software Foundation, duke@435: * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. duke@435: * trims@1907: * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA trims@1907: * or visit www.oracle.com if you need additional information or have any trims@1907: * questions. duke@435: * duke@435: */ duke@435: stefank@2314: #ifndef SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP stefank@2314: #define SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP stefank@2314: stefank@2314: #include "jvmtifiles/jvmtiEnv.hpp" stefank@2314: #include "memory/oopFactory.hpp" stefank@2314: #include "memory/resourceArea.hpp" stefank@2314: #include "oops/objArrayKlass.hpp" stefank@2314: #include "oops/objArrayOop.hpp" stefank@2314: #include "prims/jvmtiRedefineClassesTrace.hpp" stefank@2314: #include "runtime/vm_operations.hpp" stefank@2314: duke@435: // Introduction: duke@435: // duke@435: // The RedefineClasses() API is used to change the definition of one or duke@435: // more classes. While the API supports redefining more than one class duke@435: // in a single call, in general, the API is discussed in the context of duke@435: // changing the definition of a single current class to a single new duke@435: // class. For clarity, the current class is will always be called duke@435: // "the_class" and the new class will always be called "scratch_class". duke@435: // duke@435: // The name "the_class" is used because there is only one structure duke@435: // that represents a specific class; redefinition does not replace the duke@435: // structure, but instead replaces parts of the structure. The name duke@435: // "scratch_class" is used because the structure that represents the duke@435: // new definition of a specific class is simply used to carry around duke@435: // the parts of the new definition until they are used to replace the duke@435: // appropriate parts in the_class. Once redefinition of a class is duke@435: // complete, scratch_class is thrown away. duke@435: // duke@435: // duke@435: // Implementation Overview: duke@435: // duke@435: // The RedefineClasses() API is mostly a wrapper around the VM op that duke@435: // does the real work. The work is split in varying degrees between duke@435: // doit_prologue(), doit() and doit_epilogue(). duke@435: // duke@435: // 1) doit_prologue() is called by the JavaThread on the way to a duke@435: // safepoint. It does parameter verification and loads scratch_class duke@435: // which involves: duke@435: // - parsing the incoming class definition using the_class' class duke@435: // loader and security context duke@435: // - linking scratch_class duke@435: // - merging constant pools and rewriting bytecodes as needed duke@435: // for the merged constant pool duke@435: // - verifying the bytecodes in scratch_class duke@435: // - setting up the constant pool cache and rewriting bytecodes duke@435: // as needed to use the cache duke@435: // - finally, scratch_class is compared to the_class to verify duke@435: // that it is a valid replacement class duke@435: // - if everything is good, then scratch_class is saved in an duke@435: // instance field in the VM operation for the doit() call duke@435: // duke@435: // Note: A JavaThread must do the above work. duke@435: // duke@435: // 2) doit() is called by the VMThread during a safepoint. It installs duke@435: // the new class definition(s) which involves: duke@435: // - retrieving the scratch_class from the instance field in the duke@435: // VM operation duke@435: // - house keeping (flushing breakpoints and caches, deoptimizing duke@435: // dependent compiled code) duke@435: // - replacing parts in the_class with parts from scratch_class duke@435: // - adding weak reference(s) to track the obsolete but interesting duke@435: // parts of the_class duke@435: // - adjusting constant pool caches and vtables in other classes duke@435: // that refer to methods in the_class. These adjustments use the duke@435: // SystemDictionary::classes_do() facility which only allows duke@435: // a helper method to be specified. The interesting parameters duke@435: // that we would like to pass to the helper method are saved in duke@435: // static global fields in the VM operation. duke@435: // - telling the SystemDictionary to notice our changes duke@435: // duke@435: // Note: the above work must be done by the VMThread to be safe. duke@435: // duke@435: // 3) doit_epilogue() is called by the JavaThread after the VM op duke@435: // is finished and the safepoint is done. It simply cleans up duke@435: // memory allocated in doit_prologue() and used in doit(). duke@435: // duke@435: // duke@435: // Constant Pool Details: duke@435: // duke@435: // When the_class is redefined, we cannot just replace the constant duke@435: // pool in the_class with the constant pool from scratch_class because duke@435: // that could confuse obsolete methods that may still be running. duke@435: // Instead, the constant pool from the_class, old_cp, is merged with duke@435: // the constant pool from scratch_class, scratch_cp. The resulting duke@435: // constant pool, merge_cp, replaces old_cp in the_class. duke@435: // duke@435: // The key part of any merging algorithm is the entry comparison duke@435: // function so we have to know the types of entries in a constant pool duke@435: // in order to merge two of them together. Constant pools can contain duke@435: // up to 12 different kinds of entries; the JVM_CONSTANT_Unicode entry duke@435: // is not presently used so we only have to worry about the other 11 duke@435: // entry types. For the purposes of constant pool merging, it is duke@435: // helpful to know that the 11 entry types fall into 3 different duke@435: // subtypes: "direct", "indirect" and "double-indirect". duke@435: // duke@435: // Direct CP entries contain data and do not contain references to duke@435: // other CP entries. The following are direct CP entries: duke@435: // JVM_CONSTANT_{Double,Float,Integer,Long,Utf8} duke@435: // duke@435: // Indirect CP entries contain 1 or 2 references to a direct CP entry duke@435: // and no other data. The following are indirect CP entries: duke@435: // JVM_CONSTANT_{Class,NameAndType,String} duke@435: // duke@435: // Double-indirect CP entries contain two references to indirect CP duke@435: // entries and no other data. The following are double-indirect CP duke@435: // entries: duke@435: // JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref} duke@435: // duke@435: // When comparing entries between two constant pools, the entry types duke@435: // are compared first and if they match, then further comparisons are duke@435: // made depending on the entry subtype. Comparing direct CP entries is duke@435: // simply a matter of comparing the data associated with each entry. duke@435: // Comparing both indirect and double-indirect CP entries requires duke@435: // recursion. duke@435: // duke@435: // Fortunately, the recursive combinations are limited because indirect duke@435: // CP entries can only refer to direct CP entries and double-indirect duke@435: // CP entries can only refer to indirect CP entries. The following is duke@435: // an example illustration of the deepest set of indirections needed to duke@435: // access the data associated with a JVM_CONSTANT_Fieldref entry: duke@435: // duke@435: // JVM_CONSTANT_Fieldref { duke@435: // class_index => JVM_CONSTANT_Class { duke@435: // name_index => JVM_CONSTANT_Utf8 { duke@435: // duke@435: // } duke@435: // } duke@435: // name_and_type_index => JVM_CONSTANT_NameAndType { duke@435: // name_index => JVM_CONSTANT_Utf8 { duke@435: // duke@435: // } duke@435: // descriptor_index => JVM_CONSTANT_Utf8 { duke@435: // duke@435: // } duke@435: // } duke@435: // } duke@435: // duke@435: // The above illustration is not a data structure definition for any duke@435: // computer language. The curly braces ('{' and '}') are meant to duke@435: // delimit the context of the "fields" in the CP entry types shown. duke@435: // Each indirection from the JVM_CONSTANT_Fieldref entry is shown via duke@435: // "=>", e.g., the class_index is used to indirectly reference a duke@435: // JVM_CONSTANT_Class entry where the name_index is used to indirectly duke@435: // reference a JVM_CONSTANT_Utf8 entry which contains the interesting duke@435: // . In order to understand a JVM_CONSTANT_Fieldref entry, we duke@435: // have to do a total of 5 indirections just to get to the CP entries duke@435: // that contain the interesting pieces of data and then we have to duke@435: // fetch the three pieces of data. This means we have to do a total of duke@435: // (5 + 3) * 2 == 16 dereferences to compare two JVM_CONSTANT_Fieldref duke@435: // entries. duke@435: // duke@435: // Here is the indirection, data and dereference count for each entry duke@435: // type: duke@435: // duke@435: // JVM_CONSTANT_Class 1 indir, 1 data, 2 derefs duke@435: // JVM_CONSTANT_Double 0 indir, 1 data, 1 deref duke@435: // JVM_CONSTANT_Fieldref 2 indir, 3 data, 8 derefs duke@435: // JVM_CONSTANT_Float 0 indir, 1 data, 1 deref duke@435: // JVM_CONSTANT_Integer 0 indir, 1 data, 1 deref duke@435: // JVM_CONSTANT_InterfaceMethodref 2 indir, 3 data, 8 derefs duke@435: // JVM_CONSTANT_Long 0 indir, 1 data, 1 deref duke@435: // JVM_CONSTANT_Methodref 2 indir, 3 data, 8 derefs duke@435: // JVM_CONSTANT_NameAndType 1 indir, 2 data, 4 derefs duke@435: // JVM_CONSTANT_String 1 indir, 1 data, 2 derefs duke@435: // JVM_CONSTANT_Utf8 0 indir, 1 data, 1 deref duke@435: // duke@435: // So different subtypes of CP entries require different amounts of duke@435: // work for a proper comparison. duke@435: // duke@435: // Now that we've talked about the different entry types and how to duke@435: // compare them we need to get back to merging. This is not a merge in duke@435: // the "sort -u" sense or even in the "sort" sense. When we merge two duke@435: // constant pools, we copy all the entries from old_cp to merge_cp, duke@435: // preserving entry order. Next we append all the unique entries from duke@435: // scratch_cp to merge_cp and we track the index changes from the duke@435: // location in scratch_cp to the possibly new location in merge_cp. duke@435: // When we are done, any obsolete code that is still running that duke@435: // uses old_cp should not be able to observe any difference if it duke@435: // were to use merge_cp. As for the new code in scratch_class, it is duke@435: // modified to use the appropriate index values in merge_cp before it duke@435: // is used to replace the code in the_class. duke@435: // duke@435: // There is one small complication in copying the entries from old_cp duke@435: // to merge_cp. Two of the CP entry types are special in that they are duke@435: // lazily resolved. Before explaining the copying complication, we need duke@435: // to digress into CP entry resolution. duke@435: // duke@435: // JVM_CONSTANT_Class and JVM_CONSTANT_String entries are present in duke@435: // the class file, but are not stored in memory as such until they are duke@435: // resolved. The entries are not resolved unless they are used because duke@435: // resolution is expensive. During class file parsing the entries are duke@435: // initially stored in memory as JVM_CONSTANT_ClassIndex and duke@435: // JVM_CONSTANT_StringIndex entries. These special CP entry types duke@435: // indicate that the JVM_CONSTANT_Class and JVM_CONSTANT_String entries duke@435: // have been parsed, but the index values in the entries have not been duke@435: // validated. After the entire constant pool has been parsed, the index duke@435: // values can be validated and then the entries are converted into duke@435: // JVM_CONSTANT_UnresolvedClass and JVM_CONSTANT_UnresolvedString duke@435: // entries. During this conversion process, the UTF8 values that are duke@435: // indirectly referenced by the JVM_CONSTANT_ClassIndex and coleenp@2497: // JVM_CONSTANT_StringIndex entries are changed into Symbol*s and the coleenp@2497: // entries are modified to refer to the Symbol*s. This optimization duke@435: // eliminates one level of indirection for those two CP entry types and duke@435: // gets the entries ready for verification. During class file parsing duke@435: // it is also possible for JVM_CONSTANT_UnresolvedString entries to be duke@435: // resolved into JVM_CONSTANT_String entries. Verification expects to duke@435: // find JVM_CONSTANT_UnresolvedClass and either JVM_CONSTANT_String or duke@435: // JVM_CONSTANT_UnresolvedString entries and not JVM_CONSTANT_Class duke@435: // entries. duke@435: // duke@435: // Now we can get back to the copying complication. When we copy duke@435: // entries from old_cp to merge_cp, we have to revert any duke@435: // JVM_CONSTANT_Class entries to JVM_CONSTANT_UnresolvedClass entries duke@435: // or verification will fail. duke@435: // duke@435: // It is important to explicitly state that the merging algorithm duke@435: // effectively unresolves JVM_CONSTANT_Class entries that were in the duke@435: // old_cp when they are changed into JVM_CONSTANT_UnresolvedClass duke@435: // entries in the merge_cp. This is done both to make verification duke@435: // happy and to avoid adding more brittleness between RedefineClasses duke@435: // and the constant pool cache. By allowing the constant pool cache duke@435: // implementation to (re)resolve JVM_CONSTANT_UnresolvedClass entries duke@435: // into JVM_CONSTANT_Class entries, we avoid having to embed knowledge duke@435: // about those algorithms in RedefineClasses. duke@435: // duke@435: // Appending unique entries from scratch_cp to merge_cp is straight duke@435: // forward for direct CP entries and most indirect CP entries. For the duke@435: // indirect CP entry type JVM_CONSTANT_NameAndType and for the double- duke@435: // indirect CP entry types, the presence of more than one piece of duke@435: // interesting data makes appending the entries more complicated. duke@435: // duke@435: // For the JVM_CONSTANT_{Double,Float,Integer,Long,Utf8} entry types, duke@435: // the entry is simply copied from scratch_cp to the end of merge_cp. duke@435: // If the index in scratch_cp is different than the destination index duke@435: // in merge_cp, then the change in index value is tracked. duke@435: // duke@435: // Note: the above discussion for the direct CP entries also applies duke@435: // to the JVM_CONSTANT_Unresolved{Class,String} entry types. duke@435: // duke@435: // For the JVM_CONSTANT_{Class,String} entry types, since there is only duke@435: // one data element at the end of the recursion, we know that we have duke@435: // either one or two unique entries. If the JVM_CONSTANT_Utf8 entry is duke@435: // unique then it is appended to merge_cp before the current entry. duke@435: // If the JVM_CONSTANT_Utf8 entry is not unique, then the current entry duke@435: // is updated to refer to the duplicate entry in merge_cp before it is duke@435: // appended to merge_cp. Again, any changes in index values are tracked duke@435: // as needed. duke@435: // duke@435: // Note: the above discussion for JVM_CONSTANT_{Class,String} entry duke@435: // types is theoretical. Since those entry types have already been duke@435: // optimized into JVM_CONSTANT_Unresolved{Class,String} entry types, duke@435: // they are handled as direct CP entries. duke@435: // duke@435: // For the JVM_CONSTANT_NameAndType entry type, since there are two duke@435: // data elements at the end of the recursions, we know that we have duke@435: // between one and three unique entries. Any unique JVM_CONSTANT_Utf8 duke@435: // entries are appended to merge_cp before the current entry. For any duke@435: // JVM_CONSTANT_Utf8 entries that are not unique, the current entry is duke@435: // updated to refer to the duplicate entry in merge_cp before it is duke@435: // appended to merge_cp. Again, any changes in index values are tracked duke@435: // as needed. duke@435: // duke@435: // For the JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref} entry duke@435: // types, since there are two indirect CP entries and three data duke@435: // elements at the end of the recursions, we know that we have between duke@435: // one and six unique entries. See the JVM_CONSTANT_Fieldref diagram duke@435: // above for an example of all six entries. The uniqueness algorithm duke@435: // for the JVM_CONSTANT_Class and JVM_CONSTANT_NameAndType entries is duke@435: // covered above. Any unique entries are appended to merge_cp before duke@435: // the current entry. For any entries that are not unique, the current duke@435: // entry is updated to refer to the duplicate entry in merge_cp before duke@435: // it is appended to merge_cp. Again, any changes in index values are duke@435: // tracked as needed. duke@435: // duke@435: // duke@435: // Other Details: duke@435: // duke@435: // Details for other parts of RedefineClasses need to be written. duke@435: // This is a placeholder section. duke@435: // duke@435: // duke@435: // Open Issues (in no particular order): duke@435: // duke@435: // - How do we serialize the RedefineClasses() API without deadlocking? duke@435: // duke@435: // - SystemDictionary::parse_stream() was called with a NULL protection duke@435: // domain since the initial version. This has been changed to pass duke@435: // the_class->protection_domain(). This change has been tested with duke@435: // all NSK tests and nothing broke, but what will adding it now break duke@435: // in ways that we don't test? duke@435: // duke@435: // - GenerateOopMap::rewrite_load_or_store() has a comment in its duke@435: // (indirect) use of the Relocator class that the max instruction duke@435: // size is 4 bytes. goto_w and jsr_w are 5 bytes and wide/iinc is duke@435: // 6 bytes. Perhaps Relocator only needs a 4 byte buffer to do duke@435: // what it does to the bytecodes. More investigation is needed. duke@435: // duke@435: // - java.lang.Object methods can be called on arrays. This is duke@435: // implemented via the arrayKlassOop vtable which we don't duke@435: // update. For example, if we redefine java.lang.Object.toString(), duke@435: // then the new version of the method will not be called for array duke@435: // objects. duke@435: // duke@435: // - How do we know if redefine_single_class() and the guts of duke@435: // instanceKlass are out of sync? I don't think this can be duke@435: // automated, but we should probably order the work in duke@435: // redefine_single_class() to match the order of field duke@435: // definitions in instanceKlass. We also need to add some duke@435: // comments about keeping things in sync. duke@435: // duke@435: // - set_new_constant_pool() is huge and we should consider refactoring duke@435: // it into smaller chunks of work. duke@435: // duke@435: // - The exception table update code in set_new_constant_pool() defines duke@435: // const values that are also defined in a local context elsewhere. duke@435: // The same literal values are also used in elsewhere. We need to duke@435: // coordinate a cleanup of these constants with Runtime. duke@435: // duke@435: duke@435: class VM_RedefineClasses: public VM_Operation { duke@435: private: duke@435: // These static fields are needed by SystemDictionary::classes_do() duke@435: // facility and the adjust_cpool_cache_and_vtable() helper: duke@435: static objArrayOop _old_methods; duke@435: static objArrayOop _new_methods; duke@435: static methodOop* _matching_old_methods; duke@435: static methodOop* _matching_new_methods; duke@435: static methodOop* _deleted_methods; duke@435: static methodOop* _added_methods; duke@435: static int _matching_methods_length; duke@435: static int _deleted_methods_length; duke@435: static int _added_methods_length; duke@435: static klassOop _the_class_oop; duke@435: duke@435: // The instance fields are used to pass information from duke@435: // doit_prologue() to doit() and doit_epilogue(). duke@435: jint _class_count; duke@435: const jvmtiClassDefinition *_class_defs; // ptr to _class_count defs duke@435: duke@435: // This operation is used by both RedefineClasses and duke@435: // RetransformClasses. Indicate which. duke@435: JvmtiClassLoadKind _class_load_kind; duke@435: duke@435: // _index_map_count is just an optimization for knowing if duke@435: // _index_map_p contains any entries. duke@435: int _index_map_count; duke@435: intArray * _index_map_p; duke@435: // ptr to _class_count scratch_classes duke@435: instanceKlassHandle * _scratch_classes; duke@435: jvmtiError _res; duke@435: duke@435: // Performance measurement support. These timers do not cover all duke@435: // the work done for JVM/TI RedefineClasses() but they do cover duke@435: // the heavy lifting. duke@435: elapsedTimer _timer_rsc_phase1; duke@435: elapsedTimer _timer_rsc_phase2; duke@435: elapsedTimer _timer_vm_op_prologue; duke@435: duke@435: // These routines are roughly in call order unless otherwise noted. duke@435: duke@435: // Load the caller's new class definition(s) into _scratch_classes. duke@435: // Constant pool merging work is done here as needed. Also calls duke@435: // compare_and_normalize_class_versions() to verify the class duke@435: // definition(s). duke@435: jvmtiError load_new_class_versions(TRAPS); duke@435: duke@435: // Verify that the caller provided class definition(s) that meet duke@435: // the restrictions of RedefineClasses. Normalize the order of duke@435: // overloaded methods as needed. duke@435: jvmtiError compare_and_normalize_class_versions( duke@435: instanceKlassHandle the_class, instanceKlassHandle scratch_class); duke@435: duke@435: // Swap annotations[i] with annotations[j] duke@435: // Used by compare_and_normalize_class_versions() when normalizing duke@435: // overloaded methods or changing idnum as when adding or deleting methods. duke@435: void swap_all_method_annotations(int i, int j, instanceKlassHandle scratch_class); duke@435: duke@435: // Figure out which new methods match old methods in name and signature, duke@435: // which methods have been added, and which are no longer present duke@435: void compute_added_deleted_matching_methods(); duke@435: duke@435: // Change jmethodIDs to point to the new methods duke@435: void update_jmethod_ids(); duke@435: duke@435: // In addition to marking methods as obsolete, this routine duke@435: // records which methods are EMCP (Equivalent Module Constant duke@435: // Pool) in the emcp_methods BitMap and returns the number of duke@435: // EMCP methods via emcp_method_count_p. This information is duke@435: // used when information about the previous version of the_class duke@435: // is squirreled away. duke@435: void check_methods_and_mark_as_obsolete(BitMap *emcp_methods, duke@435: int * emcp_method_count_p); duke@435: void transfer_old_native_function_registrations(instanceKlassHandle the_class); duke@435: duke@435: // Unevolving classes may point to methods of the_class directly duke@435: // from their constant pool caches, itables, and/or vtables. We duke@435: // use the SystemDictionary::classes_do() facility and this helper duke@435: // to fix up these pointers. duke@435: static void adjust_cpool_cache_and_vtable(klassOop k_oop, oop loader, TRAPS); duke@435: duke@435: // Install the redefinition of a class duke@435: void redefine_single_class(jclass the_jclass, duke@435: instanceKlassHandle scratch_class, TRAPS); duke@435: duke@435: // Increment the classRedefinedCount field in the specific instanceKlass duke@435: // and in all direct and indirect subclasses. duke@435: void increment_class_counter(instanceKlass *ik, TRAPS); duke@435: duke@435: // Support for constant pool merging (these routines are in alpha duke@435: // order): duke@435: void append_entry(constantPoolHandle scratch_cp, int scratch_i, duke@435: constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); duke@435: int find_new_index(int old_index); duke@435: bool is_unresolved_class_mismatch(constantPoolHandle cp1, int index1, duke@435: constantPoolHandle cp2, int index2); duke@435: bool is_unresolved_string_mismatch(constantPoolHandle cp1, int index1, duke@435: constantPoolHandle cp2, int index2); duke@435: void map_index(constantPoolHandle scratch_cp, int old_index, int new_index); duke@435: bool merge_constant_pools(constantPoolHandle old_cp, duke@435: constantPoolHandle scratch_cp, constantPoolHandle *merge_cp_p, duke@435: int *merge_cp_length_p, TRAPS); duke@435: jvmtiError merge_cp_and_rewrite(instanceKlassHandle the_class, duke@435: instanceKlassHandle scratch_class, TRAPS); duke@435: u2 rewrite_cp_ref_in_annotation_data( duke@435: typeArrayHandle annotations_typeArray, int &byte_i_ref, duke@435: const char * trace_mesg, TRAPS); duke@435: bool rewrite_cp_refs(instanceKlassHandle scratch_class, TRAPS); duke@435: bool rewrite_cp_refs_in_annotation_struct( duke@435: typeArrayHandle class_annotations, int &byte_i_ref, TRAPS); duke@435: bool rewrite_cp_refs_in_annotations_typeArray( duke@435: typeArrayHandle annotations_typeArray, int &byte_i_ref, TRAPS); duke@435: bool rewrite_cp_refs_in_class_annotations( duke@435: instanceKlassHandle scratch_class, TRAPS); duke@435: bool rewrite_cp_refs_in_element_value( duke@435: typeArrayHandle class_annotations, int &byte_i_ref, TRAPS); duke@435: bool rewrite_cp_refs_in_fields_annotations( duke@435: instanceKlassHandle scratch_class, TRAPS); duke@435: void rewrite_cp_refs_in_method(methodHandle method, duke@435: methodHandle * new_method_p, TRAPS); duke@435: bool rewrite_cp_refs_in_methods(instanceKlassHandle scratch_class, TRAPS); duke@435: bool rewrite_cp_refs_in_methods_annotations( duke@435: instanceKlassHandle scratch_class, TRAPS); duke@435: bool rewrite_cp_refs_in_methods_default_annotations( duke@435: instanceKlassHandle scratch_class, TRAPS); duke@435: bool rewrite_cp_refs_in_methods_parameter_annotations( duke@435: instanceKlassHandle scratch_class, TRAPS); duke@435: void rewrite_cp_refs_in_stack_map_table(methodHandle method, TRAPS); duke@435: void rewrite_cp_refs_in_verification_type_info( duke@435: address& stackmap_addr_ref, address stackmap_end, u2 frame_i, duke@435: u1 frame_size, TRAPS); duke@435: void set_new_constant_pool(instanceKlassHandle scratch_class, duke@435: constantPoolHandle scratch_cp, int scratch_cp_length, bool shrink, TRAPS); duke@435: duke@435: void flush_dependent_code(instanceKlassHandle k_h, TRAPS); duke@435: duke@435: static void check_class(klassOop k_oop, oop initiating_loader, TRAPS) PRODUCT_RETURN; duke@435: duke@435: static void dump_methods() PRODUCT_RETURN; duke@435: duke@435: public: duke@435: VM_RedefineClasses(jint class_count, duke@435: const jvmtiClassDefinition *class_defs, duke@435: JvmtiClassLoadKind class_load_kind); duke@435: VMOp_Type type() const { return VMOp_RedefineClasses; } duke@435: bool doit_prologue(); duke@435: void doit(); duke@435: void doit_epilogue(); duke@435: duke@435: bool allow_nested_vm_operations() const { return true; } duke@435: jvmtiError check_error() { return _res; } duke@435: duke@435: // Modifiable test must be shared between IsModifiableClass query duke@435: // and redefine implementation duke@435: static bool is_modifiable_class(oop klass_mirror); duke@435: }; stefank@2314: stefank@2314: #endif // SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP