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