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