1 /*
   2  * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
   3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   4  *
   5  * This code is free software; you can redistribute it and/or modify it
   6  * under the terms of the GNU General Public License version 2 only, as
   7  * published by the Free Software Foundation.
   8  *
   9  * This code is distributed in the hope that it will be useful, but WITHOUT
  10  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  11  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
  12  * version 2 for more details (a copy is included in the LICENSE file that
  13  * accompanied this code).
  14  *
  15  * You should have received a copy of the GNU General Public License version
  16  * 2 along with this work; if not, write to the Free Software Foundation,
  17  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
  18  *
  19  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
  20  * or visit www.oracle.com if you need additional information or have any
  21  * questions.
  22  *
  23  */
  24 
  25 #ifndef SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP
  26 #define SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP
  27 
  28 #include "jvmtifiles/jvmtiEnv.hpp"
  29 #include "memory/oopFactory.hpp"
  30 #include "memory/resourceArea.hpp"
  31 #include "oops/objArrayKlass.hpp"
  32 #include "oops/objArrayOop.hpp"
  33 #include "prims/jvmtiRedefineClassesTrace.hpp"
  34 #include "runtime/vm_operations.hpp"
  35 
  36 // Introduction:
  37 //
  38 // The RedefineClasses() API is used to change the definition of one or
  39 // more classes. While the API supports redefining more than one class
  40 // in a single call, in general, the API is discussed in the context of
  41 // changing the definition of a single current class to a single new
  42 // class. For clarity, the current class is will always be called
  43 // "the_class" and the new class will always be called "scratch_class".
  44 //
  45 // The name "the_class" is used because there is only one structure
  46 // that represents a specific class; redefinition does not replace the
  47 // structure, but instead replaces parts of the structure. The name
  48 // "scratch_class" is used because the structure that represents the
  49 // new definition of a specific class is simply used to carry around
  50 // the parts of the new definition until they are used to replace the
  51 // appropriate parts in the_class. Once redefinition of a class is
  52 // complete, scratch_class is thrown away.
  53 //
  54 //
  55 // Implementation Overview:
  56 //
  57 // The RedefineClasses() API is mostly a wrapper around the VM op that
  58 // does the real work. The work is split in varying degrees between
  59 // doit_prologue(), doit() and doit_epilogue().
  60 //
  61 // 1) doit_prologue() is called by the JavaThread on the way to a
  62 //    safepoint. It does parameter verification and loads scratch_class
  63 //    which involves:
  64 //    - parsing the incoming class definition using the_class' class
  65 //      loader and security context
  66 //    - linking scratch_class
  67 //    - merging constant pools and rewriting bytecodes as needed
  68 //      for the merged constant pool
  69 //    - verifying the bytecodes in scratch_class
  70 //    - setting up the constant pool cache and rewriting bytecodes
  71 //      as needed to use the cache
  72 //    - finally, scratch_class is compared to the_class to verify
  73 //      that it is a valid replacement class
  74 //    - if everything is good, then scratch_class is saved in an
  75 //      instance field in the VM operation for the doit() call
  76 //
  77 //    Note: A JavaThread must do the above work.
  78 //
  79 // 2) doit() is called by the VMThread during a safepoint. It installs
  80 //    the new class definition(s) which involves:
  81 //    - retrieving the scratch_class from the instance field in the
  82 //      VM operation
  83 //    - house keeping (flushing breakpoints and caches, deoptimizing
  84 //      dependent compiled code)
  85 //    - replacing parts in the_class with parts from scratch_class
  86 //    - adding weak reference(s) to track the obsolete but interesting
  87 //      parts of the_class
  88 //    - adjusting constant pool caches and vtables in other classes
  89 //      that refer to methods in the_class. These adjustments use the
  90 //      ClassLoaderDataGraph::classes_do() facility which only allows
  91 //      a helper method to be specified. The interesting parameters
  92 //      that we would like to pass to the helper method are saved in
  93 //      static global fields in the VM operation.
  94 //    - telling the SystemDictionary to notice our changes
  95 //
  96 //    Note: the above work must be done by the VMThread to be safe.
  97 //
  98 // 3) doit_epilogue() is called by the JavaThread after the VM op
  99 //    is finished and the safepoint is done. It simply cleans up
 100 //    memory allocated in doit_prologue() and used in doit().
 101 //
 102 //
 103 // Constant Pool Details:
 104 //
 105 // When the_class is redefined, we cannot just replace the constant
 106 // pool in the_class with the constant pool from scratch_class because
 107 // that could confuse obsolete methods that may still be running.
 108 // Instead, the constant pool from the_class, old_cp, is merged with
 109 // the constant pool from scratch_class, scratch_cp. The resulting
 110 // constant pool, merge_cp, replaces old_cp in the_class.
 111 //
 112 // The key part of any merging algorithm is the entry comparison
 113 // function so we have to know the types of entries in a constant pool
 114 // in order to merge two of them together. Constant pools can contain
 115 // up to 12 different kinds of entries; the JVM_CONSTANT_Unicode entry
 116 // is not presently used so we only have to worry about the other 11
 117 // entry types. For the purposes of constant pool merging, it is
 118 // helpful to know that the 11 entry types fall into 3 different
 119 // subtypes: "direct", "indirect" and "double-indirect".
 120 //
 121 // Direct CP entries contain data and do not contain references to
 122 // other CP entries. The following are direct CP entries:
 123 //     JVM_CONSTANT_{Double,Float,Integer,Long,Utf8}
 124 //
 125 // Indirect CP entries contain 1 or 2 references to a direct CP entry
 126 // and no other data. The following are indirect CP entries:
 127 //     JVM_CONSTANT_{Class,NameAndType,String}
 128 //
 129 // Double-indirect CP entries contain two references to indirect CP
 130 // entries and no other data. The following are double-indirect CP
 131 // entries:
 132 //     JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref}
 133 //
 134 // When comparing entries between two constant pools, the entry types
 135 // are compared first and if they match, then further comparisons are
 136 // made depending on the entry subtype. Comparing direct CP entries is
 137 // simply a matter of comparing the data associated with each entry.
 138 // Comparing both indirect and double-indirect CP entries requires
 139 // recursion.
 140 //
 141 // Fortunately, the recursive combinations are limited because indirect
 142 // CP entries can only refer to direct CP entries and double-indirect
 143 // CP entries can only refer to indirect CP entries. The following is
 144 // an example illustration of the deepest set of indirections needed to
 145 // access the data associated with a JVM_CONSTANT_Fieldref entry:
 146 //
 147 //     JVM_CONSTANT_Fieldref {
 148 //         class_index => JVM_CONSTANT_Class {
 149 //             name_index => JVM_CONSTANT_Utf8 {
 150 //                 <data-1>
 151 //             }
 152 //         }
 153 //         name_and_type_index => JVM_CONSTANT_NameAndType {
 154 //             name_index => JVM_CONSTANT_Utf8 {
 155 //                 <data-2>
 156 //             }
 157 //             descriptor_index => JVM_CONSTANT_Utf8 {
 158 //                 <data-3>
 159 //             }
 160 //         }
 161 //     }
 162 //
 163 // The above illustration is not a data structure definition for any
 164 // computer language. The curly braces ('{' and '}') are meant to
 165 // delimit the context of the "fields" in the CP entry types shown.
 166 // Each indirection from the JVM_CONSTANT_Fieldref entry is shown via
 167 // "=>", e.g., the class_index is used to indirectly reference a
 168 // JVM_CONSTANT_Class entry where the name_index is used to indirectly
 169 // reference a JVM_CONSTANT_Utf8 entry which contains the interesting
 170 // <data-1>. In order to understand a JVM_CONSTANT_Fieldref entry, we
 171 // have to do a total of 5 indirections just to get to the CP entries
 172 // that contain the interesting pieces of data and then we have to
 173 // fetch the three pieces of data. This means we have to do a total of
 174 // (5 + 3) * 2 == 16 dereferences to compare two JVM_CONSTANT_Fieldref
 175 // entries.
 176 //
 177 // Here is the indirection, data and dereference count for each entry
 178 // type:
 179 //
 180 //    JVM_CONSTANT_Class               1 indir, 1 data, 2 derefs
 181 //    JVM_CONSTANT_Double              0 indir, 1 data, 1 deref
 182 //    JVM_CONSTANT_Fieldref            2 indir, 3 data, 8 derefs
 183 //    JVM_CONSTANT_Float               0 indir, 1 data, 1 deref
 184 //    JVM_CONSTANT_Integer             0 indir, 1 data, 1 deref
 185 //    JVM_CONSTANT_InterfaceMethodref  2 indir, 3 data, 8 derefs
 186 //    JVM_CONSTANT_Long                0 indir, 1 data, 1 deref
 187 //    JVM_CONSTANT_Methodref           2 indir, 3 data, 8 derefs
 188 //    JVM_CONSTANT_NameAndType         1 indir, 2 data, 4 derefs
 189 //    JVM_CONSTANT_String              1 indir, 1 data, 2 derefs
 190 //    JVM_CONSTANT_Utf8                0 indir, 1 data, 1 deref
 191 //
 192 // So different subtypes of CP entries require different amounts of
 193 // work for a proper comparison.
 194 //
 195 // Now that we've talked about the different entry types and how to
 196 // compare them we need to get back to merging. This is not a merge in
 197 // the "sort -u" sense or even in the "sort" sense. When we merge two
 198 // constant pools, we copy all the entries from old_cp to merge_cp,
 199 // preserving entry order. Next we append all the unique entries from
 200 // scratch_cp to merge_cp and we track the index changes from the
 201 // location in scratch_cp to the possibly new location in merge_cp.
 202 // When we are done, any obsolete code that is still running that
 203 // uses old_cp should not be able to observe any difference if it
 204 // were to use merge_cp. As for the new code in scratch_class, it is
 205 // modified to use the appropriate index values in merge_cp before it
 206 // is used to replace the code in the_class.
 207 //
 208 // There is one small complication in copying the entries from old_cp
 209 // to merge_cp. Two of the CP entry types are special in that they are
 210 // lazily resolved. Before explaining the copying complication, we need
 211 // to digress into CP entry resolution.
 212 //
 213 // JVM_CONSTANT_Class entries are present in the class file, but are not
 214 // stored in memory as such until they are resolved. The entries are not
 215 // resolved unless they are used because resolution is expensive. During class
 216 // file parsing the entries are initially stored in memory as
 217 // JVM_CONSTANT_ClassIndex and JVM_CONSTANT_StringIndex entries. These special
 218 // CP entry types indicate that the JVM_CONSTANT_Class and JVM_CONSTANT_String
 219 // entries have been parsed, but the index values in the entries have not been
 220 // validated. After the entire constant pool has been parsed, the index
 221 // values can be validated and then the entries are converted into
 222 // JVM_CONSTANT_UnresolvedClass and JVM_CONSTANT_String
 223 // entries. During this conversion process, the UTF8 values that are
 224 // indirectly referenced by the JVM_CONSTANT_ClassIndex and
 225 // JVM_CONSTANT_StringIndex entries are changed into Symbol*s and the
 226 // entries are modified to refer to the Symbol*s. This optimization
 227 // eliminates one level of indirection for those two CP entry types and
 228 // gets the entries ready for verification.  Verification expects to
 229 // find JVM_CONSTANT_UnresolvedClass but not JVM_CONSTANT_Class entries.
 230 //
 231 // Now we can get back to the copying complication. When we copy
 232 // entries from old_cp to merge_cp, we have to revert any
 233 // JVM_CONSTANT_Class entries to JVM_CONSTANT_UnresolvedClass entries
 234 // or verification will fail.
 235 //
 236 // It is important to explicitly state that the merging algorithm
 237 // effectively unresolves JVM_CONSTANT_Class entries that were in the
 238 // old_cp when they are changed into JVM_CONSTANT_UnresolvedClass
 239 // entries in the merge_cp. This is done both to make verification
 240 // happy and to avoid adding more brittleness between RedefineClasses
 241 // and the constant pool cache. By allowing the constant pool cache
 242 // implementation to (re)resolve JVM_CONSTANT_UnresolvedClass entries
 243 // into JVM_CONSTANT_Class entries, we avoid having to embed knowledge
 244 // about those algorithms in RedefineClasses.
 245 //
 246 // Appending unique entries from scratch_cp to merge_cp is straight
 247 // forward for direct CP entries and most indirect CP entries. For the
 248 // indirect CP entry type JVM_CONSTANT_NameAndType and for the double-
 249 // indirect CP entry types, the presence of more than one piece of
 250 // interesting data makes appending the entries more complicated.
 251 //
 252 // For the JVM_CONSTANT_{Double,Float,Integer,Long,Utf8} entry types,
 253 // the entry is simply copied from scratch_cp to the end of merge_cp.
 254 // If the index in scratch_cp is different than the destination index
 255 // in merge_cp, then the change in index value is tracked.
 256 //
 257 // Note: the above discussion for the direct CP entries also applies
 258 // to the JVM_CONSTANT_UnresolvedClass entry types.
 259 //
 260 // For the JVM_CONSTANT_Class entry types, since there is only
 261 // one data element at the end of the recursion, we know that we have
 262 // either one or two unique entries. If the JVM_CONSTANT_Utf8 entry is
 263 // unique then it is appended to merge_cp before the current entry.
 264 // If the JVM_CONSTANT_Utf8 entry is not unique, then the current entry
 265 // is updated to refer to the duplicate entry in merge_cp before it is
 266 // appended to merge_cp. Again, any changes in index values are tracked
 267 // as needed.
 268 //
 269 // Note: the above discussion for JVM_CONSTANT_Class entry
 270 // types is theoretical. Since those entry types have already been
 271 // optimized into JVM_CONSTANT_UnresolvedClass entry types,
 272 // they are handled as direct CP entries.
 273 //
 274 // For the JVM_CONSTANT_NameAndType entry type, since there are two
 275 // data elements at the end of the recursions, we know that we have
 276 // between one and three unique entries. Any unique JVM_CONSTANT_Utf8
 277 // entries are appended to merge_cp before the current entry. For any
 278 // JVM_CONSTANT_Utf8 entries that are not unique, the current entry is
 279 // updated to refer to the duplicate entry in merge_cp before it is
 280 // appended to merge_cp. Again, any changes in index values are tracked
 281 // as needed.
 282 //
 283 // For the JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref} entry
 284 // types, since there are two indirect CP entries and three data
 285 // elements at the end of the recursions, we know that we have between
 286 // one and six unique entries. See the JVM_CONSTANT_Fieldref diagram
 287 // above for an example of all six entries. The uniqueness algorithm
 288 // for the JVM_CONSTANT_Class and JVM_CONSTANT_NameAndType entries is
 289 // covered above. Any unique entries are appended to merge_cp before
 290 // the current entry. For any entries that are not unique, the current
 291 // entry is updated to refer to the duplicate entry in merge_cp before
 292 // it is appended to merge_cp. Again, any changes in index values are
 293 // tracked as needed.
 294 //
 295 //
 296 // Other Details:
 297 //
 298 // Details for other parts of RedefineClasses need to be written.
 299 // This is a placeholder section.
 300 //
 301 //
 302 // Open Issues (in no particular order):
 303 //
 304 // - How do we serialize the RedefineClasses() API without deadlocking?
 305 //
 306 // - SystemDictionary::parse_stream() was called with a NULL protection
 307 //   domain since the initial version. This has been changed to pass
 308 //   the_class->protection_domain(). This change has been tested with
 309 //   all NSK tests and nothing broke, but what will adding it now break
 310 //   in ways that we don't test?
 311 //
 312 // - GenerateOopMap::rewrite_load_or_store() has a comment in its
 313 //   (indirect) use of the Relocator class that the max instruction
 314 //   size is 4 bytes. goto_w and jsr_w are 5 bytes and wide/iinc is
 315 //   6 bytes. Perhaps Relocator only needs a 4 byte buffer to do
 316 //   what it does to the bytecodes. More investigation is needed.
 317 //
 318 // - How do we know if redefine_single_class() and the guts of
 319 //   InstanceKlass are out of sync? I don't think this can be
 320 //   automated, but we should probably order the work in
 321 //   redefine_single_class() to match the order of field
 322 //   definitions in InstanceKlass. We also need to add some
 323 //   comments about keeping things in sync.
 324 //
 325 // - set_new_constant_pool() is huge and we should consider refactoring
 326 //   it into smaller chunks of work.
 327 //
 328 // - The exception table update code in set_new_constant_pool() defines
 329 //   const values that are also defined in a local context elsewhere.
 330 //   The same literal values are also used in elsewhere. We need to
 331 //   coordinate a cleanup of these constants with Runtime.
 332 //
 333 
 334 struct JvmtiCachedClassFileData {
 335   jint length;
 336   unsigned char data[1];
 337 };
 338 
 339 class VM_RedefineClasses: public VM_Operation {
 340  private:
 341   // These static fields are needed by ClassLoaderDataGraph::classes_do()
 342   // facility and the AdjustCpoolCacheAndVtable helper:
 343   static Array<Method*>* _old_methods;
 344   static Array<Method*>* _new_methods;
 345   static Method**      _matching_old_methods;
 346   static Method**      _matching_new_methods;
 347   static Method**      _deleted_methods;
 348   static Method**      _added_methods;
 349   static int             _matching_methods_length;
 350   static int             _deleted_methods_length;
 351   static int             _added_methods_length;
 352   static Klass*          _the_class_oop;
 353 
 354   // The instance fields are used to pass information from
 355   // doit_prologue() to doit() and doit_epilogue().
 356   jint                        _class_count;
 357   const jvmtiClassDefinition *_class_defs;  // ptr to _class_count defs
 358 
 359   // This operation is used by both RedefineClasses and
 360   // RetransformClasses.  Indicate which.
 361   JvmtiClassLoadKind          _class_load_kind;
 362 
 363   // _index_map_count is just an optimization for knowing if
 364   // _index_map_p contains any entries.
 365   int                         _index_map_count;
 366   intArray *                  _index_map_p;
 367 
 368   // _operands_index_map_count is just an optimization for knowing if
 369   // _operands_index_map_p contains any entries.
 370   int                         _operands_cur_length;
 371   int                         _operands_index_map_count;
 372   intArray *                  _operands_index_map_p;
 373 
 374   // ptr to _class_count scratch_classes
 375   Klass**                     _scratch_classes;
 376   jvmtiError                  _res;
 377 
 378   // Performance measurement support. These timers do not cover all
 379   // the work done for JVM/TI RedefineClasses() but they do cover
 380   // the heavy lifting.
 381   elapsedTimer  _timer_rsc_phase1;
 382   elapsedTimer  _timer_rsc_phase2;
 383   elapsedTimer  _timer_vm_op_prologue;
 384 
 385   // These routines are roughly in call order unless otherwise noted.
 386 
 387   // Load the caller's new class definition(s) into _scratch_classes.
 388   // Constant pool merging work is done here as needed. Also calls
 389   // compare_and_normalize_class_versions() to verify the class
 390   // definition(s).
 391   jvmtiError load_new_class_versions(TRAPS);
 392 
 393   // Verify that the caller provided class definition(s) that meet
 394   // the restrictions of RedefineClasses. Normalize the order of
 395   // overloaded methods as needed.
 396   jvmtiError compare_and_normalize_class_versions(
 397     instanceKlassHandle the_class, instanceKlassHandle scratch_class);
 398 
 399   // Figure out which new methods match old methods in name and signature,
 400   // which methods have been added, and which are no longer present
 401   void compute_added_deleted_matching_methods();
 402 
 403   // Change jmethodIDs to point to the new methods
 404   void update_jmethod_ids();
 405 
 406   // In addition to marking methods as obsolete, this routine
 407   // records which methods are EMCP (Equivalent Module Constant
 408   // Pool) in the emcp_methods BitMap and returns the number of
 409   // EMCP methods via emcp_method_count_p. This information is
 410   // used when information about the previous version of the_class
 411   // is squirreled away.
 412   void check_methods_and_mark_as_obsolete(BitMap *emcp_methods,
 413          int * emcp_method_count_p);
 414   void transfer_old_native_function_registrations(instanceKlassHandle the_class);
 415 
 416   // Install the redefinition of a class
 417   void redefine_single_class(jclass the_jclass,
 418     Klass* scratch_class_oop, TRAPS);
 419 
 420   void swap_annotations(instanceKlassHandle new_class,
 421                         instanceKlassHandle scratch_class);
 422 
 423   // Increment the classRedefinedCount field in the specific InstanceKlass
 424   // and in all direct and indirect subclasses.
 425   void increment_class_counter(InstanceKlass *ik, TRAPS);
 426 
 427   // Support for constant pool merging (these routines are in alpha order):
 428   void append_entry(constantPoolHandle scratch_cp, int scratch_i,
 429     constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
 430   void append_operand(constantPoolHandle scratch_cp, int scratch_bootstrap_spec_index,
 431     constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
 432   void finalize_operands_merge(constantPoolHandle merge_cp, TRAPS);
 433   int find_or_append_indirect_entry(constantPoolHandle scratch_cp, int scratch_i,
 434     constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
 435   int find_or_append_operand(constantPoolHandle scratch_cp, int scratch_bootstrap_spec_index,
 436     constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
 437   int find_new_index(int old_index);
 438   int find_new_operand_index(int old_bootstrap_spec_index);
 439   bool is_unresolved_class_mismatch(constantPoolHandle cp1, int index1,
 440     constantPoolHandle cp2, int index2);
 441   void map_index(constantPoolHandle scratch_cp, int old_index, int new_index);
 442   void map_operand_index(int old_bootstrap_spec_index, int new_bootstrap_spec_index);
 443   bool merge_constant_pools(constantPoolHandle old_cp,
 444     constantPoolHandle scratch_cp, constantPoolHandle *merge_cp_p,
 445     int *merge_cp_length_p, TRAPS);
 446   jvmtiError merge_cp_and_rewrite(instanceKlassHandle the_class,
 447     instanceKlassHandle scratch_class, TRAPS);
 448   u2 rewrite_cp_ref_in_annotation_data(
 449     AnnotationArray* annotations_typeArray, int &byte_i_ref,
 450     const char * trace_mesg, TRAPS);
 451   bool rewrite_cp_refs(instanceKlassHandle scratch_class, TRAPS);
 452   bool rewrite_cp_refs_in_annotation_struct(
 453     AnnotationArray* class_annotations, int &byte_i_ref, TRAPS);
 454   bool rewrite_cp_refs_in_annotations_typeArray(
 455     AnnotationArray* annotations_typeArray, int &byte_i_ref, TRAPS);
 456   bool rewrite_cp_refs_in_class_annotations(
 457     instanceKlassHandle scratch_class, TRAPS);
 458   bool rewrite_cp_refs_in_element_value(
 459     AnnotationArray* class_annotations, int &byte_i_ref, TRAPS);
 460   bool rewrite_cp_refs_in_type_annotations_typeArray(
 461     AnnotationArray* type_annotations_typeArray, int &byte_i_ref,
 462     const char * location_mesg, TRAPS);
 463   bool rewrite_cp_refs_in_type_annotation_struct(
 464     AnnotationArray* type_annotations_typeArray, int &byte_i_ref,
 465     const char * location_mesg, TRAPS);
 466   bool skip_type_annotation_target(
 467     AnnotationArray* type_annotations_typeArray, int &byte_i_ref,
 468     const char * location_mesg, TRAPS);
 469   bool skip_type_annotation_type_path(
 470     AnnotationArray* type_annotations_typeArray, int &byte_i_ref, TRAPS);
 471   bool rewrite_cp_refs_in_fields_annotations(
 472     instanceKlassHandle scratch_class, TRAPS);
 473   void rewrite_cp_refs_in_method(methodHandle method,
 474     methodHandle * new_method_p, TRAPS);
 475   bool rewrite_cp_refs_in_methods(instanceKlassHandle scratch_class, TRAPS);
 476   bool rewrite_cp_refs_in_methods_annotations(
 477     instanceKlassHandle scratch_class, TRAPS);
 478   bool rewrite_cp_refs_in_methods_default_annotations(
 479     instanceKlassHandle scratch_class, TRAPS);
 480   bool rewrite_cp_refs_in_methods_parameter_annotations(
 481     instanceKlassHandle scratch_class, TRAPS);
 482   bool rewrite_cp_refs_in_class_type_annotations(
 483     instanceKlassHandle scratch_class, TRAPS);
 484   bool rewrite_cp_refs_in_fields_type_annotations(
 485     instanceKlassHandle scratch_class, TRAPS);
 486   bool rewrite_cp_refs_in_methods_type_annotations(
 487     instanceKlassHandle scratch_class, TRAPS);
 488   void rewrite_cp_refs_in_stack_map_table(methodHandle method, TRAPS);
 489   void rewrite_cp_refs_in_verification_type_info(
 490          address& stackmap_addr_ref, address stackmap_end, u2 frame_i,
 491          u1 frame_size, TRAPS);
 492   void set_new_constant_pool(ClassLoaderData* loader_data,
 493          instanceKlassHandle scratch_class,
 494          constantPoolHandle scratch_cp, int scratch_cp_length, TRAPS);
 495 
 496   void flush_dependent_code(instanceKlassHandle k_h, TRAPS);
 497 
 498   static void dump_methods();
 499 
 500   // Check that there are no old or obsolete methods
 501   class CheckClass : public KlassClosure {
 502     Thread* _thread;
 503    public:
 504     CheckClass(Thread* t) : _thread(t) {}
 505     void do_klass(Klass* k);
 506   };
 507 
 508   // Unevolving classes may point to methods of the_class directly
 509   // from their constant pool caches, itables, and/or vtables. We
 510   // use the ClassLoaderDataGraph::classes_do() facility and this helper
 511   // to fix up these pointers.
 512   class AdjustCpoolCacheAndVtable : public KlassClosure {
 513     Thread* _thread;
 514    public:
 515     AdjustCpoolCacheAndVtable(Thread* t) : _thread(t) {}
 516     void do_klass(Klass* k);
 517   };
 518 
 519  public:
 520   VM_RedefineClasses(jint class_count,
 521                      const jvmtiClassDefinition *class_defs,
 522                      JvmtiClassLoadKind class_load_kind);
 523   VMOp_Type type() const { return VMOp_RedefineClasses; }
 524   bool doit_prologue();
 525   void doit();
 526   void doit_epilogue();
 527 
 528   bool allow_nested_vm_operations() const        { return true; }
 529   jvmtiError check_error()                       { return _res; }
 530 
 531   // Modifiable test must be shared between IsModifiableClass query
 532   // and redefine implementation
 533   static bool is_modifiable_class(oop klass_mirror);
 534 
 535   static jint get_cached_class_file_len(JvmtiCachedClassFileData *cache) {
 536     return cache == NULL ? 0 : cache->length;
 537   }
 538   static unsigned char * get_cached_class_file_bytes(JvmtiCachedClassFileData *cache) {
 539     return cache == NULL ? NULL : cache->data;
 540   }
 541 };
 542 #endif // SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP