1/*
2 * Copyright (c) 2003, 2019, 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/vmOperations.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// - SystemDictionary::parse_stream() was called with a NULL protection
306// domain since the initial version. This has been changed to pass
307// the_class->protection_domain(). This change has been tested with
308// all NSK tests and nothing broke, but what will adding it now break
309// in ways that we don't test?
310//
311// - GenerateOopMap::rewrite_load_or_store() has a comment in its
312// (indirect) use of the Relocator class that the max instruction
313// size is 4 bytes. goto_w and jsr_w are 5 bytes and wide/iinc is
314// 6 bytes. Perhaps Relocator only needs a 4 byte buffer to do
315// what it does to the bytecodes. More investigation is needed.
316//
317// - How do we know if redefine_single_class() and the guts of
318// InstanceKlass are out of sync? I don't think this can be
319// automated, but we should probably order the work in
320// redefine_single_class() to match the order of field
321// definitions in InstanceKlass. We also need to add some
322// comments about keeping things in sync.
323//
324// - set_new_constant_pool() is huge and we should consider refactoring
325// it into smaller chunks of work.
326//
327// - The exception table update code in set_new_constant_pool() defines
328// const values that are also defined in a local context elsewhere.
329// The same literal values are also used in elsewhere. We need to
330// coordinate a cleanup of these constants with Runtime.
331//
332
333struct JvmtiCachedClassFileData {
334 jint length;
335 unsigned char data[1];
336};
337
338class VM_RedefineClasses: public VM_Operation {
339 private:
340 // These static fields are needed by ClassLoaderDataGraph::classes_do()
341 // facility and the CheckClass and AdjustAndCleanMetadata helpers.
342 static Array<Method*>* _old_methods;
343 static Array<Method*>* _new_methods;
344 static Method** _matching_old_methods;
345 static Method** _matching_new_methods;
346 static Method** _deleted_methods;
347 static Method** _added_methods;
348 static int _matching_methods_length;
349 static int _deleted_methods_length;
350 static int _added_methods_length;
351 static bool _has_redefined_Object;
352 static bool _has_null_class_loader;
353
354 // The instance fields are used to pass information from
355 // doit_prologue() to doit() and doit_epilogue().
356 Klass* _the_class;
357 jint _class_count;
358 const jvmtiClassDefinition *_class_defs; // ptr to _class_count defs
359
360 // This operation is used by both RedefineClasses and
361 // RetransformClasses. Indicate which.
362 JvmtiClassLoadKind _class_load_kind;
363
364 // _index_map_count is just an optimization for knowing if
365 // _index_map_p contains any entries.
366 int _index_map_count;
367 intArray * _index_map_p;
368
369 // _operands_index_map_count is just an optimization for knowing if
370 // _operands_index_map_p contains any entries.
371 int _operands_cur_length;
372 int _operands_index_map_count;
373 intArray * _operands_index_map_p;
374
375 // ptr to _class_count scratch_classes
376 InstanceKlass** _scratch_classes;
377 jvmtiError _res;
378
379 // Set if any of the InstanceKlasses have entries in the ResolvedMethodTable
380 // to avoid walking after redefinition if the redefined classes do not
381 // have any entries.
382 bool _any_class_has_resolved_methods;
383
384 // Performance measurement support. These timers do not cover all
385 // the work done for JVM/TI RedefineClasses() but they do cover
386 // the heavy lifting.
387 elapsedTimer _timer_rsc_phase1;
388 elapsedTimer _timer_rsc_phase2;
389 elapsedTimer _timer_vm_op_prologue;
390
391 // These routines are roughly in call order unless otherwise noted.
392
393 // Load the caller's new class definition(s) into _scratch_classes.
394 // Constant pool merging work is done here as needed. Also calls
395 // compare_and_normalize_class_versions() to verify the class
396 // definition(s).
397 jvmtiError load_new_class_versions(TRAPS);
398
399 // Verify that the caller provided class definition(s) that meet
400 // the restrictions of RedefineClasses. Normalize the order of
401 // overloaded methods as needed.
402 jvmtiError compare_and_normalize_class_versions(
403 InstanceKlass* the_class, InstanceKlass* scratch_class);
404
405 // Figure out which new methods match old methods in name and signature,
406 // which methods have been added, and which are no longer present
407 void compute_added_deleted_matching_methods();
408
409 // Change jmethodIDs to point to the new methods
410 void update_jmethod_ids();
411
412 // In addition to marking methods as old and/or obsolete, this routine
413 // counts the number of methods that are EMCP (Equivalent Module Constant Pool).
414 int check_methods_and_mark_as_obsolete();
415 void transfer_old_native_function_registrations(InstanceKlass* the_class);
416
417 // Install the redefinition of a class
418 void redefine_single_class(jclass the_jclass,
419 InstanceKlass* scratch_class_oop, TRAPS);
420
421 void swap_annotations(InstanceKlass* new_class,
422 InstanceKlass* scratch_class);
423
424 // Increment the classRedefinedCount field in the specific InstanceKlass
425 // and in all direct and indirect subclasses.
426 void increment_class_counter(InstanceKlass *ik, TRAPS);
427
428 // Support for constant pool merging (these routines are in alpha order):
429 void append_entry(const constantPoolHandle& scratch_cp, int scratch_i,
430 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
431 void append_operand(const constantPoolHandle& scratch_cp, int scratch_bootstrap_spec_index,
432 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
433 void finalize_operands_merge(const constantPoolHandle& merge_cp, TRAPS);
434 int find_or_append_indirect_entry(const constantPoolHandle& scratch_cp, int scratch_i,
435 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
436 int find_or_append_operand(const constantPoolHandle& scratch_cp, int scratch_bootstrap_spec_index,
437 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS);
438 int find_new_index(int old_index);
439 int find_new_operand_index(int old_bootstrap_spec_index);
440 bool is_unresolved_class_mismatch(const constantPoolHandle& cp1, int index1,
441 const constantPoolHandle& cp2, int index2);
442 void map_index(const constantPoolHandle& scratch_cp, int old_index, int new_index);
443 void map_operand_index(int old_bootstrap_spec_index, int new_bootstrap_spec_index);
444 bool merge_constant_pools(const constantPoolHandle& old_cp,
445 const constantPoolHandle& scratch_cp, constantPoolHandle *merge_cp_p,
446 int *merge_cp_length_p, TRAPS);
447 jvmtiError merge_cp_and_rewrite(InstanceKlass* the_class,
448 InstanceKlass* scratch_class, TRAPS);
449 u2 rewrite_cp_ref_in_annotation_data(
450 AnnotationArray* annotations_typeArray, int &byte_i_ref,
451 const char * trace_mesg, TRAPS);
452 bool rewrite_cp_refs(InstanceKlass* scratch_class, TRAPS);
453 bool rewrite_cp_refs_in_annotation_struct(
454 AnnotationArray* class_annotations, int &byte_i_ref, TRAPS);
455 bool rewrite_cp_refs_in_annotations_typeArray(
456 AnnotationArray* annotations_typeArray, int &byte_i_ref, TRAPS);
457 bool rewrite_cp_refs_in_class_annotations(
458 InstanceKlass* scratch_class, TRAPS);
459 bool rewrite_cp_refs_in_element_value(
460 AnnotationArray* class_annotations, int &byte_i_ref, TRAPS);
461 bool rewrite_cp_refs_in_type_annotations_typeArray(
462 AnnotationArray* type_annotations_typeArray, int &byte_i_ref,
463 const char * location_mesg, TRAPS);
464 bool rewrite_cp_refs_in_type_annotation_struct(
465 AnnotationArray* type_annotations_typeArray, int &byte_i_ref,
466 const char * location_mesg, TRAPS);
467 bool skip_type_annotation_target(
468 AnnotationArray* type_annotations_typeArray, int &byte_i_ref,
469 const char * location_mesg, TRAPS);
470 bool skip_type_annotation_type_path(
471 AnnotationArray* type_annotations_typeArray, int &byte_i_ref, TRAPS);
472 bool rewrite_cp_refs_in_fields_annotations(
473 InstanceKlass* scratch_class, TRAPS);
474 bool rewrite_cp_refs_in_nest_attributes(InstanceKlass* scratch_class);
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, TRAPS);
478 bool rewrite_cp_refs_in_methods_annotations(
479 InstanceKlass* scratch_class, TRAPS);
480 bool rewrite_cp_refs_in_methods_default_annotations(
481 InstanceKlass* scratch_class, TRAPS);
482 bool rewrite_cp_refs_in_methods_parameter_annotations(
483 InstanceKlass* scratch_class, TRAPS);
484 bool rewrite_cp_refs_in_class_type_annotations(
485 InstanceKlass* scratch_class, TRAPS);
486 bool rewrite_cp_refs_in_fields_type_annotations(
487 InstanceKlass* scratch_class, TRAPS);
488 bool rewrite_cp_refs_in_methods_type_annotations(
489 InstanceKlass* scratch_class, TRAPS);
490 void rewrite_cp_refs_in_stack_map_table(const methodHandle& method, TRAPS);
491 void rewrite_cp_refs_in_verification_type_info(
492 address& stackmap_addr_ref, address stackmap_end, u2 frame_i,
493 u1 frame_size, TRAPS);
494 void set_new_constant_pool(ClassLoaderData* loader_data,
495 InstanceKlass* scratch_class,
496 constantPoolHandle scratch_cp, int scratch_cp_length, TRAPS);
497
498 void flush_dependent_code();
499 void mark_dependent_code(InstanceKlass* ik);
500
501 // lock classes to redefine since constant pool merging isn't thread safe.
502 void lock_classes();
503 void unlock_classes();
504
505 static void dump_methods();
506
507 // Check that there are no old or obsolete methods
508 class CheckClass : public KlassClosure {
509 Thread* _thread;
510 public:
511 CheckClass(Thread* t) : _thread(t) {}
512 void do_klass(Klass* k);
513 };
514
515 // Unevolving classes may point to methods of the_class directly
516 // from their constant pool caches, itables, and/or vtables. We
517 // use the ClassLoaderDataGraph::classes_do() facility and this helper
518 // to fix up these pointers and clean MethodData out.
519 class AdjustAndCleanMetadata : public KlassClosure {
520 Thread* _thread;
521 public:
522 AdjustAndCleanMetadata(Thread* t) : _thread(t) {}
523 void do_klass(Klass* k);
524 };
525
526 public:
527 VM_RedefineClasses(jint class_count,
528 const jvmtiClassDefinition *class_defs,
529 JvmtiClassLoadKind class_load_kind);
530 VMOp_Type type() const { return VMOp_RedefineClasses; }
531 bool doit_prologue();
532 void doit();
533 void doit_epilogue();
534
535 bool allow_nested_vm_operations() const { return true; }
536 jvmtiError check_error() { return _res; }
537
538 // Modifiable test must be shared between IsModifiableClass query
539 // and redefine implementation
540 static bool is_modifiable_class(oop klass_mirror);
541
542 static jint get_cached_class_file_len(JvmtiCachedClassFileData *cache) {
543 return cache == NULL ? 0 : cache->length;
544 }
545 static unsigned char * get_cached_class_file_bytes(JvmtiCachedClassFileData *cache) {
546 return cache == NULL ? NULL : cache->data;
547 }
548
549 // Error printing
550 void print_on_error(outputStream* st) const;
551};
552#endif // SHARE_PRIMS_JVMTIREDEFINECLASSES_HPP
553