jvmtiRedefineClasses.hpp revision 2062:3582bf76420e
1/* 2 * Copyright (c) 2003, 2010, 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// SystemDictionary::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 and JVM_CONSTANT_String entries are present in 214// the class file, but are not stored in memory as such until they are 215// resolved. The entries are not resolved unless they are used because 216// resolution is expensive. During class file parsing the entries are 217// initially stored in memory as JVM_CONSTANT_ClassIndex and 218// JVM_CONSTANT_StringIndex entries. These special CP entry types 219// indicate that the JVM_CONSTANT_Class and JVM_CONSTANT_String entries 220// have been parsed, but the index values in the entries have not been 221// validated. After the entire constant pool has been parsed, the index 222// values can be validated and then the entries are converted into 223// JVM_CONSTANT_UnresolvedClass and JVM_CONSTANT_UnresolvedString 224// entries. During this conversion process, the UTF8 values that are 225// indirectly referenced by the JVM_CONSTANT_ClassIndex and 226// JVM_CONSTANT_StringIndex entries are changed into Symbol*s and the 227// entries are modified to refer to the Symbol*s. This optimization 228// eliminates one level of indirection for those two CP entry types and 229// gets the entries ready for verification. During class file parsing 230// it is also possible for JVM_CONSTANT_UnresolvedString entries to be 231// resolved into JVM_CONSTANT_String entries. Verification expects to 232// find JVM_CONSTANT_UnresolvedClass and either JVM_CONSTANT_String or 233// JVM_CONSTANT_UnresolvedString entries and not JVM_CONSTANT_Class 234// entries. 235// 236// Now we can get back to the copying complication. When we copy 237// entries from old_cp to merge_cp, we have to revert any 238// JVM_CONSTANT_Class entries to JVM_CONSTANT_UnresolvedClass entries 239// or verification will fail. 240// 241// It is important to explicitly state that the merging algorithm 242// effectively unresolves JVM_CONSTANT_Class entries that were in the 243// old_cp when they are changed into JVM_CONSTANT_UnresolvedClass 244// entries in the merge_cp. This is done both to make verification 245// happy and to avoid adding more brittleness between RedefineClasses 246// and the constant pool cache. By allowing the constant pool cache 247// implementation to (re)resolve JVM_CONSTANT_UnresolvedClass entries 248// into JVM_CONSTANT_Class entries, we avoid having to embed knowledge 249// about those algorithms in RedefineClasses. 250// 251// Appending unique entries from scratch_cp to merge_cp is straight 252// forward for direct CP entries and most indirect CP entries. For the 253// indirect CP entry type JVM_CONSTANT_NameAndType and for the double- 254// indirect CP entry types, the presence of more than one piece of 255// interesting data makes appending the entries more complicated. 256// 257// For the JVM_CONSTANT_{Double,Float,Integer,Long,Utf8} entry types, 258// the entry is simply copied from scratch_cp to the end of merge_cp. 259// If the index in scratch_cp is different than the destination index 260// in merge_cp, then the change in index value is tracked. 261// 262// Note: the above discussion for the direct CP entries also applies 263// to the JVM_CONSTANT_Unresolved{Class,String} entry types. 264// 265// For the JVM_CONSTANT_{Class,String} entry types, since there is only 266// one data element at the end of the recursion, we know that we have 267// either one or two unique entries. If the JVM_CONSTANT_Utf8 entry is 268// unique then it is appended to merge_cp before the current entry. 269// If the JVM_CONSTANT_Utf8 entry is not unique, then the current entry 270// is updated to refer to the duplicate entry in merge_cp before it is 271// appended to merge_cp. Again, any changes in index values are tracked 272// as needed. 273// 274// Note: the above discussion for JVM_CONSTANT_{Class,String} entry 275// types is theoretical. Since those entry types have already been 276// optimized into JVM_CONSTANT_Unresolved{Class,String} entry types, 277// they are handled as direct CP entries. 278// 279// For the JVM_CONSTANT_NameAndType entry type, since there are two 280// data elements at the end of the recursions, we know that we have 281// between one and three unique entries. Any unique JVM_CONSTANT_Utf8 282// entries are appended to merge_cp before the current entry. For any 283// JVM_CONSTANT_Utf8 entries that are not unique, the current entry is 284// updated to refer to the duplicate entry in merge_cp before it is 285// appended to merge_cp. Again, any changes in index values are tracked 286// as needed. 287// 288// For the JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref} entry 289// types, since there are two indirect CP entries and three data 290// elements at the end of the recursions, we know that we have between 291// one and six unique entries. See the JVM_CONSTANT_Fieldref diagram 292// above for an example of all six entries. The uniqueness algorithm 293// for the JVM_CONSTANT_Class and JVM_CONSTANT_NameAndType entries is 294// covered above. Any unique entries are appended to merge_cp before 295// the current entry. For any entries that are not unique, the current 296// entry is updated to refer to the duplicate entry in merge_cp before 297// it is appended to merge_cp. Again, any changes in index values are 298// tracked as needed. 299// 300// 301// Other Details: 302// 303// Details for other parts of RedefineClasses need to be written. 304// This is a placeholder section. 305// 306// 307// Open Issues (in no particular order): 308// 309// - How do we serialize the RedefineClasses() API without deadlocking? 310// 311// - SystemDictionary::parse_stream() was called with a NULL protection 312// domain since the initial version. This has been changed to pass 313// the_class->protection_domain(). This change has been tested with 314// all NSK tests and nothing broke, but what will adding it now break 315// in ways that we don't test? 316// 317// - GenerateOopMap::rewrite_load_or_store() has a comment in its 318// (indirect) use of the Relocator class that the max instruction 319// size is 4 bytes. goto_w and jsr_w are 5 bytes and wide/iinc is 320// 6 bytes. Perhaps Relocator only needs a 4 byte buffer to do 321// what it does to the bytecodes. More investigation is needed. 322// 323// - java.lang.Object methods can be called on arrays. This is 324// implemented via the arrayKlassOop vtable which we don't 325// update. For example, if we redefine java.lang.Object.toString(), 326// then the new version of the method will not be called for array 327// objects. 328// 329// - How do we know if redefine_single_class() and the guts of 330// instanceKlass are out of sync? I don't think this can be 331// automated, but we should probably order the work in 332// redefine_single_class() to match the order of field 333// definitions in instanceKlass. We also need to add some 334// comments about keeping things in sync. 335// 336// - set_new_constant_pool() is huge and we should consider refactoring 337// it into smaller chunks of work. 338// 339// - The exception table update code in set_new_constant_pool() defines 340// const values that are also defined in a local context elsewhere. 341// The same literal values are also used in elsewhere. We need to 342// coordinate a cleanup of these constants with Runtime. 343// 344 345class VM_RedefineClasses: public VM_Operation { 346 private: 347 // These static fields are needed by SystemDictionary::classes_do() 348 // facility and the adjust_cpool_cache_and_vtable() helper: 349 static objArrayOop _old_methods; 350 static objArrayOop _new_methods; 351 static methodOop* _matching_old_methods; 352 static methodOop* _matching_new_methods; 353 static methodOop* _deleted_methods; 354 static methodOop* _added_methods; 355 static int _matching_methods_length; 356 static int _deleted_methods_length; 357 static int _added_methods_length; 358 static klassOop _the_class_oop; 359 360 // The instance fields are used to pass information from 361 // doit_prologue() to doit() and doit_epilogue(). 362 jint _class_count; 363 const jvmtiClassDefinition *_class_defs; // ptr to _class_count defs 364 365 // This operation is used by both RedefineClasses and 366 // RetransformClasses. Indicate which. 367 JvmtiClassLoadKind _class_load_kind; 368 369 // _index_map_count is just an optimization for knowing if 370 // _index_map_p contains any entries. 371 int _index_map_count; 372 intArray * _index_map_p; 373 // ptr to _class_count scratch_classes 374 instanceKlassHandle * _scratch_classes; 375 jvmtiError _res; 376 377 // Performance measurement support. These timers do not cover all 378 // the work done for JVM/TI RedefineClasses() but they do cover 379 // the heavy lifting. 380 elapsedTimer _timer_rsc_phase1; 381 elapsedTimer _timer_rsc_phase2; 382 elapsedTimer _timer_vm_op_prologue; 383 384 // These routines are roughly in call order unless otherwise noted. 385 386 // Load the caller's new class definition(s) into _scratch_classes. 387 // Constant pool merging work is done here as needed. Also calls 388 // compare_and_normalize_class_versions() to verify the class 389 // definition(s). 390 jvmtiError load_new_class_versions(TRAPS); 391 392 // Verify that the caller provided class definition(s) that meet 393 // the restrictions of RedefineClasses. Normalize the order of 394 // overloaded methods as needed. 395 jvmtiError compare_and_normalize_class_versions( 396 instanceKlassHandle the_class, instanceKlassHandle scratch_class); 397 398 // Swap annotations[i] with annotations[j] 399 // Used by compare_and_normalize_class_versions() when normalizing 400 // overloaded methods or changing idnum as when adding or deleting methods. 401 void swap_all_method_annotations(int i, int j, instanceKlassHandle 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 obsolete, this routine 411 // records which methods are EMCP (Equivalent Module Constant 412 // Pool) in the emcp_methods BitMap and returns the number of 413 // EMCP methods via emcp_method_count_p. This information is 414 // used when information about the previous version of the_class 415 // is squirreled away. 416 void check_methods_and_mark_as_obsolete(BitMap *emcp_methods, 417 int * emcp_method_count_p); 418 void transfer_old_native_function_registrations(instanceKlassHandle the_class); 419 420 // Unevolving classes may point to methods of the_class directly 421 // from their constant pool caches, itables, and/or vtables. We 422 // use the SystemDictionary::classes_do() facility and this helper 423 // to fix up these pointers. 424 static void adjust_cpool_cache_and_vtable(klassOop k_oop, oop loader, TRAPS); 425 426 // Install the redefinition of a class 427 void redefine_single_class(jclass the_jclass, 428 instanceKlassHandle scratch_class, TRAPS); 429 430 // Increment the classRedefinedCount field in the specific instanceKlass 431 // and in all direct and indirect subclasses. 432 void increment_class_counter(instanceKlass *ik, TRAPS); 433 434 // Support for constant pool merging (these routines are in alpha 435 // order): 436 void append_entry(constantPoolHandle scratch_cp, int scratch_i, 437 constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 438 int find_new_index(int old_index); 439 bool is_unresolved_class_mismatch(constantPoolHandle cp1, int index1, 440 constantPoolHandle cp2, int index2); 441 bool is_unresolved_string_mismatch(constantPoolHandle cp1, int index1, 442 constantPoolHandle cp2, int index2); 443 void map_index(constantPoolHandle scratch_cp, int old_index, int new_index); 444 bool merge_constant_pools(constantPoolHandle old_cp, 445 constantPoolHandle scratch_cp, constantPoolHandle *merge_cp_p, 446 int *merge_cp_length_p, TRAPS); 447 jvmtiError merge_cp_and_rewrite(instanceKlassHandle the_class, 448 instanceKlassHandle scratch_class, TRAPS); 449 u2 rewrite_cp_ref_in_annotation_data( 450 typeArrayHandle annotations_typeArray, int &byte_i_ref, 451 const char * trace_mesg, TRAPS); 452 bool rewrite_cp_refs(instanceKlassHandle scratch_class, TRAPS); 453 bool rewrite_cp_refs_in_annotation_struct( 454 typeArrayHandle class_annotations, int &byte_i_ref, TRAPS); 455 bool rewrite_cp_refs_in_annotations_typeArray( 456 typeArrayHandle annotations_typeArray, int &byte_i_ref, TRAPS); 457 bool rewrite_cp_refs_in_class_annotations( 458 instanceKlassHandle scratch_class, TRAPS); 459 bool rewrite_cp_refs_in_element_value( 460 typeArrayHandle class_annotations, int &byte_i_ref, TRAPS); 461 bool rewrite_cp_refs_in_fields_annotations( 462 instanceKlassHandle scratch_class, TRAPS); 463 void rewrite_cp_refs_in_method(methodHandle method, 464 methodHandle * new_method_p, TRAPS); 465 bool rewrite_cp_refs_in_methods(instanceKlassHandle scratch_class, TRAPS); 466 bool rewrite_cp_refs_in_methods_annotations( 467 instanceKlassHandle scratch_class, TRAPS); 468 bool rewrite_cp_refs_in_methods_default_annotations( 469 instanceKlassHandle scratch_class, TRAPS); 470 bool rewrite_cp_refs_in_methods_parameter_annotations( 471 instanceKlassHandle scratch_class, TRAPS); 472 void rewrite_cp_refs_in_stack_map_table(methodHandle method, TRAPS); 473 void rewrite_cp_refs_in_verification_type_info( 474 address& stackmap_addr_ref, address stackmap_end, u2 frame_i, 475 u1 frame_size, TRAPS); 476 void set_new_constant_pool(instanceKlassHandle scratch_class, 477 constantPoolHandle scratch_cp, int scratch_cp_length, bool shrink, TRAPS); 478 479 void flush_dependent_code(instanceKlassHandle k_h, TRAPS); 480 481 static void check_class(klassOop k_oop, oop initiating_loader, TRAPS) PRODUCT_RETURN; 482 483 static void dump_methods() PRODUCT_RETURN; 484 485 public: 486 VM_RedefineClasses(jint class_count, 487 const jvmtiClassDefinition *class_defs, 488 JvmtiClassLoadKind class_load_kind); 489 VMOp_Type type() const { return VMOp_RedefineClasses; } 490 bool doit_prologue(); 491 void doit(); 492 void doit_epilogue(); 493 494 bool allow_nested_vm_operations() const { return true; } 495 jvmtiError check_error() { return _res; } 496 497 // Modifiable test must be shared between IsModifiableClass query 498 // and redefine implementation 499 static bool is_modifiable_class(oop klass_mirror); 500}; 501 502#endif // SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP 503