1/* 2 * Copyright (c) 2003, 2017, 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 "runtime/vm_operations.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 AdjustCpoolCacheAndVtable helper: 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 Klass* _the_class; 352 353 // The instance fields are used to pass information from 354 // doit_prologue() to doit() and doit_epilogue(). 355 jint _class_count; 356 const jvmtiClassDefinition *_class_defs; // ptr to _class_count defs 357 358 // This operation is used by both RedefineClasses and 359 // RetransformClasses. Indicate which. 360 JvmtiClassLoadKind _class_load_kind; 361 362 // _index_map_count is just an optimization for knowing if 363 // _index_map_p contains any entries. 364 int _index_map_count; 365 intArray * _index_map_p; 366 367 // _operands_index_map_count is just an optimization for knowing if 368 // _operands_index_map_p contains any entries. 369 int _operands_cur_length; 370 int _operands_index_map_count; 371 intArray * _operands_index_map_p; 372 373 // ptr to _class_count scratch_classes 374 InstanceKlass** _scratch_classes; 375 jvmtiError _res; 376 377 // Set if any of the InstanceKlasses have entries in the ResolvedMethodTable 378 // to avoid walking after redefinition if the redefined classes do not 379 // have any entries. 380 bool _any_class_has_resolved_methods; 381 382 // Performance measurement support. These timers do not cover all 383 // the work done for JVM/TI RedefineClasses() but they do cover 384 // the heavy lifting. 385 elapsedTimer _timer_rsc_phase1; 386 elapsedTimer _timer_rsc_phase2; 387 elapsedTimer _timer_vm_op_prologue; 388 389 // These routines are roughly in call order unless otherwise noted. 390 391 // Load the caller's new class definition(s) into _scratch_classes. 392 // Constant pool merging work is done here as needed. Also calls 393 // compare_and_normalize_class_versions() to verify the class 394 // definition(s). 395 jvmtiError load_new_class_versions(TRAPS); 396 397 // Verify that the caller provided class definition(s) that meet 398 // the restrictions of RedefineClasses. Normalize the order of 399 // overloaded methods as needed. 400 jvmtiError compare_and_normalize_class_versions( 401 InstanceKlass* the_class, InstanceKlass* scratch_class); 402 403 // Figure out which new methods match old methods in name and signature, 404 // which methods have been added, and which are no longer present 405 void compute_added_deleted_matching_methods(); 406 407 // Change jmethodIDs to point to the new methods 408 void update_jmethod_ids(); 409 410 // In addition to marking methods as old and/or obsolete, this routine 411 // counts the number of methods that are EMCP (Equivalent Module Constant Pool). 412 int check_methods_and_mark_as_obsolete(); 413 void transfer_old_native_function_registrations(InstanceKlass* the_class); 414 415 // Install the redefinition of a class 416 void redefine_single_class(jclass the_jclass, 417 InstanceKlass* scratch_class_oop, TRAPS); 418 419 void swap_annotations(InstanceKlass* new_class, 420 InstanceKlass* scratch_class); 421 422 // Increment the classRedefinedCount field in the specific InstanceKlass 423 // and in all direct and indirect subclasses. 424 void increment_class_counter(InstanceKlass *ik, TRAPS); 425 426 // Support for constant pool merging (these routines are in alpha order): 427 void append_entry(const constantPoolHandle& scratch_cp, int scratch_i, 428 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 429 void append_operand(const constantPoolHandle& scratch_cp, int scratch_bootstrap_spec_index, 430 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 431 void finalize_operands_merge(const constantPoolHandle& merge_cp, TRAPS); 432 int find_or_append_indirect_entry(const constantPoolHandle& scratch_cp, int scratch_i, 433 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 434 int find_or_append_operand(const constantPoolHandle& scratch_cp, int scratch_bootstrap_spec_index, 435 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 436 int find_new_index(int old_index); 437 int find_new_operand_index(int old_bootstrap_spec_index); 438 bool is_unresolved_class_mismatch(const constantPoolHandle& cp1, int index1, 439 const constantPoolHandle& cp2, int index2); 440 void map_index(const constantPoolHandle& scratch_cp, int old_index, int new_index); 441 void map_operand_index(int old_bootstrap_spec_index, int new_bootstrap_spec_index); 442 bool merge_constant_pools(const constantPoolHandle& old_cp, 443 const constantPoolHandle& scratch_cp, constantPoolHandle *merge_cp_p, 444 int *merge_cp_length_p, TRAPS); 445 jvmtiError merge_cp_and_rewrite(InstanceKlass* the_class, 446 InstanceKlass* scratch_class, TRAPS); 447 u2 rewrite_cp_ref_in_annotation_data( 448 AnnotationArray* annotations_typeArray, int &byte_i_ref, 449 const char * trace_mesg, TRAPS); 450 bool rewrite_cp_refs(InstanceKlass* scratch_class, TRAPS); 451 bool rewrite_cp_refs_in_annotation_struct( 452 AnnotationArray* class_annotations, int &byte_i_ref, TRAPS); 453 bool rewrite_cp_refs_in_annotations_typeArray( 454 AnnotationArray* annotations_typeArray, int &byte_i_ref, TRAPS); 455 bool rewrite_cp_refs_in_class_annotations( 456 InstanceKlass* scratch_class, TRAPS); 457 bool rewrite_cp_refs_in_element_value( 458 AnnotationArray* class_annotations, int &byte_i_ref, TRAPS); 459 bool rewrite_cp_refs_in_type_annotations_typeArray( 460 AnnotationArray* type_annotations_typeArray, int &byte_i_ref, 461 const char * location_mesg, TRAPS); 462 bool rewrite_cp_refs_in_type_annotation_struct( 463 AnnotationArray* type_annotations_typeArray, int &byte_i_ref, 464 const char * location_mesg, TRAPS); 465 bool skip_type_annotation_target( 466 AnnotationArray* type_annotations_typeArray, int &byte_i_ref, 467 const char * location_mesg, TRAPS); 468 bool skip_type_annotation_type_path( 469 AnnotationArray* type_annotations_typeArray, int &byte_i_ref, TRAPS); 470 bool rewrite_cp_refs_in_fields_annotations( 471 InstanceKlass* scratch_class, TRAPS); 472 void rewrite_cp_refs_in_method(methodHandle method, 473 methodHandle * new_method_p, TRAPS); 474 bool rewrite_cp_refs_in_methods(InstanceKlass* scratch_class, TRAPS); 475 bool rewrite_cp_refs_in_methods_annotations( 476 InstanceKlass* scratch_class, TRAPS); 477 bool rewrite_cp_refs_in_methods_default_annotations( 478 InstanceKlass* scratch_class, TRAPS); 479 bool rewrite_cp_refs_in_methods_parameter_annotations( 480 InstanceKlass* scratch_class, TRAPS); 481 bool rewrite_cp_refs_in_class_type_annotations( 482 InstanceKlass* scratch_class, TRAPS); 483 bool rewrite_cp_refs_in_fields_type_annotations( 484 InstanceKlass* scratch_class, TRAPS); 485 bool rewrite_cp_refs_in_methods_type_annotations( 486 InstanceKlass* scratch_class, TRAPS); 487 void rewrite_cp_refs_in_stack_map_table(const methodHandle& method, TRAPS); 488 void rewrite_cp_refs_in_verification_type_info( 489 address& stackmap_addr_ref, address stackmap_end, u2 frame_i, 490 u1 frame_size, TRAPS); 491 void set_new_constant_pool(ClassLoaderData* loader_data, 492 InstanceKlass* scratch_class, 493 constantPoolHandle scratch_cp, int scratch_cp_length, TRAPS); 494 495 void flush_dependent_code(InstanceKlass* ik, TRAPS); 496 497 // lock classes to redefine since constant pool merging isn't thread safe. 498 void lock_classes(); 499 void unlock_classes(); 500 501 static void dump_methods(); 502 503 // Check that there are no old or obsolete methods 504 class CheckClass : public KlassClosure { 505 Thread* _thread; 506 public: 507 CheckClass(Thread* t) : _thread(t) {} 508 void do_klass(Klass* k); 509 }; 510 511 // Unevolving classes may point to methods of the_class directly 512 // from their constant pool caches, itables, and/or vtables. We 513 // use the ClassLoaderDataGraph::classes_do() facility and this helper 514 // to fix up these pointers. 515 class AdjustCpoolCacheAndVtable : public KlassClosure { 516 Thread* _thread; 517 public: 518 AdjustCpoolCacheAndVtable(Thread* t) : _thread(t) {} 519 void do_klass(Klass* k); 520 }; 521 522 // Clean MethodData out 523 class MethodDataCleaner : public KlassClosure { 524 public: 525 MethodDataCleaner() {} 526 void do_klass(Klass* k); 527 }; 528 public: 529 VM_RedefineClasses(jint class_count, 530 const jvmtiClassDefinition *class_defs, 531 JvmtiClassLoadKind class_load_kind); 532 VMOp_Type type() const { return VMOp_RedefineClasses; } 533 bool doit_prologue(); 534 void doit(); 535 void doit_epilogue(); 536 537 bool allow_nested_vm_operations() const { return true; } 538 jvmtiError check_error() { return _res; } 539 540 // Modifiable test must be shared between IsModifiableClass query 541 // and redefine implementation 542 static bool is_modifiable_class(oop klass_mirror); 543 544 static jint get_cached_class_file_len(JvmtiCachedClassFileData *cache) { 545 return cache == NULL ? 0 : cache->length; 546 } 547 static unsigned char * get_cached_class_file_bytes(JvmtiCachedClassFileData *cache) { 548 return cache == NULL ? NULL : cache->data; 549 } 550 551 // Error printing 552 void print_on_error(outputStream* st) const; 553}; 554#endif // SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP 555