1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/src/share/vm/prims/jvmtiRedefineClasses.hpp Wed Apr 27 01:25:04 2016 +0800 1.3 @@ -0,0 +1,525 @@ 1.4 +/* 1.5 + * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved. 1.6 + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 1.7 + * 1.8 + * This code is free software; you can redistribute it and/or modify it 1.9 + * under the terms of the GNU General Public License version 2 only, as 1.10 + * published by the Free Software Foundation. 1.11 + * 1.12 + * This code is distributed in the hope that it will be useful, but WITHOUT 1.13 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 1.14 + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 1.15 + * version 2 for more details (a copy is included in the LICENSE file that 1.16 + * accompanied this code). 1.17 + * 1.18 + * You should have received a copy of the GNU General Public License version 1.19 + * 2 along with this work; if not, write to the Free Software Foundation, 1.20 + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 1.21 + * 1.22 + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 1.23 + * or visit www.oracle.com if you need additional information or have any 1.24 + * questions. 1.25 + * 1.26 + */ 1.27 + 1.28 +#ifndef SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP 1.29 +#define SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP 1.30 + 1.31 +#include "jvmtifiles/jvmtiEnv.hpp" 1.32 +#include "memory/oopFactory.hpp" 1.33 +#include "memory/resourceArea.hpp" 1.34 +#include "oops/objArrayKlass.hpp" 1.35 +#include "oops/objArrayOop.hpp" 1.36 +#include "prims/jvmtiRedefineClassesTrace.hpp" 1.37 +#include "runtime/vm_operations.hpp" 1.38 + 1.39 +// Introduction: 1.40 +// 1.41 +// The RedefineClasses() API is used to change the definition of one or 1.42 +// more classes. While the API supports redefining more than one class 1.43 +// in a single call, in general, the API is discussed in the context of 1.44 +// changing the definition of a single current class to a single new 1.45 +// class. For clarity, the current class is will always be called 1.46 +// "the_class" and the new class will always be called "scratch_class". 1.47 +// 1.48 +// The name "the_class" is used because there is only one structure 1.49 +// that represents a specific class; redefinition does not replace the 1.50 +// structure, but instead replaces parts of the structure. The name 1.51 +// "scratch_class" is used because the structure that represents the 1.52 +// new definition of a specific class is simply used to carry around 1.53 +// the parts of the new definition until they are used to replace the 1.54 +// appropriate parts in the_class. Once redefinition of a class is 1.55 +// complete, scratch_class is thrown away. 1.56 +// 1.57 +// 1.58 +// Implementation Overview: 1.59 +// 1.60 +// The RedefineClasses() API is mostly a wrapper around the VM op that 1.61 +// does the real work. The work is split in varying degrees between 1.62 +// doit_prologue(), doit() and doit_epilogue(). 1.63 +// 1.64 +// 1) doit_prologue() is called by the JavaThread on the way to a 1.65 +// safepoint. It does parameter verification and loads scratch_class 1.66 +// which involves: 1.67 +// - parsing the incoming class definition using the_class' class 1.68 +// loader and security context 1.69 +// - linking scratch_class 1.70 +// - merging constant pools and rewriting bytecodes as needed 1.71 +// for the merged constant pool 1.72 +// - verifying the bytecodes in scratch_class 1.73 +// - setting up the constant pool cache and rewriting bytecodes 1.74 +// as needed to use the cache 1.75 +// - finally, scratch_class is compared to the_class to verify 1.76 +// that it is a valid replacement class 1.77 +// - if everything is good, then scratch_class is saved in an 1.78 +// instance field in the VM operation for the doit() call 1.79 +// 1.80 +// Note: A JavaThread must do the above work. 1.81 +// 1.82 +// 2) doit() is called by the VMThread during a safepoint. It installs 1.83 +// the new class definition(s) which involves: 1.84 +// - retrieving the scratch_class from the instance field in the 1.85 +// VM operation 1.86 +// - house keeping (flushing breakpoints and caches, deoptimizing 1.87 +// dependent compiled code) 1.88 +// - replacing parts in the_class with parts from scratch_class 1.89 +// - adding weak reference(s) to track the obsolete but interesting 1.90 +// parts of the_class 1.91 +// - adjusting constant pool caches and vtables in other classes 1.92 +// that refer to methods in the_class. These adjustments use the 1.93 +// ClassLoaderDataGraph::classes_do() facility which only allows 1.94 +// a helper method to be specified. The interesting parameters 1.95 +// that we would like to pass to the helper method are saved in 1.96 +// static global fields in the VM operation. 1.97 +// - telling the SystemDictionary to notice our changes 1.98 +// 1.99 +// Note: the above work must be done by the VMThread to be safe. 1.100 +// 1.101 +// 3) doit_epilogue() is called by the JavaThread after the VM op 1.102 +// is finished and the safepoint is done. It simply cleans up 1.103 +// memory allocated in doit_prologue() and used in doit(). 1.104 +// 1.105 +// 1.106 +// Constant Pool Details: 1.107 +// 1.108 +// When the_class is redefined, we cannot just replace the constant 1.109 +// pool in the_class with the constant pool from scratch_class because 1.110 +// that could confuse obsolete methods that may still be running. 1.111 +// Instead, the constant pool from the_class, old_cp, is merged with 1.112 +// the constant pool from scratch_class, scratch_cp. The resulting 1.113 +// constant pool, merge_cp, replaces old_cp in the_class. 1.114 +// 1.115 +// The key part of any merging algorithm is the entry comparison 1.116 +// function so we have to know the types of entries in a constant pool 1.117 +// in order to merge two of them together. Constant pools can contain 1.118 +// up to 12 different kinds of entries; the JVM_CONSTANT_Unicode entry 1.119 +// is not presently used so we only have to worry about the other 11 1.120 +// entry types. For the purposes of constant pool merging, it is 1.121 +// helpful to know that the 11 entry types fall into 3 different 1.122 +// subtypes: "direct", "indirect" and "double-indirect". 1.123 +// 1.124 +// Direct CP entries contain data and do not contain references to 1.125 +// other CP entries. The following are direct CP entries: 1.126 +// JVM_CONSTANT_{Double,Float,Integer,Long,Utf8} 1.127 +// 1.128 +// Indirect CP entries contain 1 or 2 references to a direct CP entry 1.129 +// and no other data. The following are indirect CP entries: 1.130 +// JVM_CONSTANT_{Class,NameAndType,String} 1.131 +// 1.132 +// Double-indirect CP entries contain two references to indirect CP 1.133 +// entries and no other data. The following are double-indirect CP 1.134 +// entries: 1.135 +// JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref} 1.136 +// 1.137 +// When comparing entries between two constant pools, the entry types 1.138 +// are compared first and if they match, then further comparisons are 1.139 +// made depending on the entry subtype. Comparing direct CP entries is 1.140 +// simply a matter of comparing the data associated with each entry. 1.141 +// Comparing both indirect and double-indirect CP entries requires 1.142 +// recursion. 1.143 +// 1.144 +// Fortunately, the recursive combinations are limited because indirect 1.145 +// CP entries can only refer to direct CP entries and double-indirect 1.146 +// CP entries can only refer to indirect CP entries. The following is 1.147 +// an example illustration of the deepest set of indirections needed to 1.148 +// access the data associated with a JVM_CONSTANT_Fieldref entry: 1.149 +// 1.150 +// JVM_CONSTANT_Fieldref { 1.151 +// class_index => JVM_CONSTANT_Class { 1.152 +// name_index => JVM_CONSTANT_Utf8 { 1.153 +// <data-1> 1.154 +// } 1.155 +// } 1.156 +// name_and_type_index => JVM_CONSTANT_NameAndType { 1.157 +// name_index => JVM_CONSTANT_Utf8 { 1.158 +// <data-2> 1.159 +// } 1.160 +// descriptor_index => JVM_CONSTANT_Utf8 { 1.161 +// <data-3> 1.162 +// } 1.163 +// } 1.164 +// } 1.165 +// 1.166 +// The above illustration is not a data structure definition for any 1.167 +// computer language. The curly braces ('{' and '}') are meant to 1.168 +// delimit the context of the "fields" in the CP entry types shown. 1.169 +// Each indirection from the JVM_CONSTANT_Fieldref entry is shown via 1.170 +// "=>", e.g., the class_index is used to indirectly reference a 1.171 +// JVM_CONSTANT_Class entry where the name_index is used to indirectly 1.172 +// reference a JVM_CONSTANT_Utf8 entry which contains the interesting 1.173 +// <data-1>. In order to understand a JVM_CONSTANT_Fieldref entry, we 1.174 +// have to do a total of 5 indirections just to get to the CP entries 1.175 +// that contain the interesting pieces of data and then we have to 1.176 +// fetch the three pieces of data. This means we have to do a total of 1.177 +// (5 + 3) * 2 == 16 dereferences to compare two JVM_CONSTANT_Fieldref 1.178 +// entries. 1.179 +// 1.180 +// Here is the indirection, data and dereference count for each entry 1.181 +// type: 1.182 +// 1.183 +// JVM_CONSTANT_Class 1 indir, 1 data, 2 derefs 1.184 +// JVM_CONSTANT_Double 0 indir, 1 data, 1 deref 1.185 +// JVM_CONSTANT_Fieldref 2 indir, 3 data, 8 derefs 1.186 +// JVM_CONSTANT_Float 0 indir, 1 data, 1 deref 1.187 +// JVM_CONSTANT_Integer 0 indir, 1 data, 1 deref 1.188 +// JVM_CONSTANT_InterfaceMethodref 2 indir, 3 data, 8 derefs 1.189 +// JVM_CONSTANT_Long 0 indir, 1 data, 1 deref 1.190 +// JVM_CONSTANT_Methodref 2 indir, 3 data, 8 derefs 1.191 +// JVM_CONSTANT_NameAndType 1 indir, 2 data, 4 derefs 1.192 +// JVM_CONSTANT_String 1 indir, 1 data, 2 derefs 1.193 +// JVM_CONSTANT_Utf8 0 indir, 1 data, 1 deref 1.194 +// 1.195 +// So different subtypes of CP entries require different amounts of 1.196 +// work for a proper comparison. 1.197 +// 1.198 +// Now that we've talked about the different entry types and how to 1.199 +// compare them we need to get back to merging. This is not a merge in 1.200 +// the "sort -u" sense or even in the "sort" sense. When we merge two 1.201 +// constant pools, we copy all the entries from old_cp to merge_cp, 1.202 +// preserving entry order. Next we append all the unique entries from 1.203 +// scratch_cp to merge_cp and we track the index changes from the 1.204 +// location in scratch_cp to the possibly new location in merge_cp. 1.205 +// When we are done, any obsolete code that is still running that 1.206 +// uses old_cp should not be able to observe any difference if it 1.207 +// were to use merge_cp. As for the new code in scratch_class, it is 1.208 +// modified to use the appropriate index values in merge_cp before it 1.209 +// is used to replace the code in the_class. 1.210 +// 1.211 +// There is one small complication in copying the entries from old_cp 1.212 +// to merge_cp. Two of the CP entry types are special in that they are 1.213 +// lazily resolved. Before explaining the copying complication, we need 1.214 +// to digress into CP entry resolution. 1.215 +// 1.216 +// JVM_CONSTANT_Class entries are present in the class file, but are not 1.217 +// stored in memory as such until they are resolved. The entries are not 1.218 +// resolved unless they are used because resolution is expensive. During class 1.219 +// file parsing the entries are initially stored in memory as 1.220 +// JVM_CONSTANT_ClassIndex and JVM_CONSTANT_StringIndex entries. These special 1.221 +// CP entry types indicate that the JVM_CONSTANT_Class and JVM_CONSTANT_String 1.222 +// entries have been parsed, but the index values in the entries have not been 1.223 +// validated. After the entire constant pool has been parsed, the index 1.224 +// values can be validated and then the entries are converted into 1.225 +// JVM_CONSTANT_UnresolvedClass and JVM_CONSTANT_String 1.226 +// entries. During this conversion process, the UTF8 values that are 1.227 +// indirectly referenced by the JVM_CONSTANT_ClassIndex and 1.228 +// JVM_CONSTANT_StringIndex entries are changed into Symbol*s and the 1.229 +// entries are modified to refer to the Symbol*s. This optimization 1.230 +// eliminates one level of indirection for those two CP entry types and 1.231 +// gets the entries ready for verification. Verification expects to 1.232 +// find JVM_CONSTANT_UnresolvedClass but not JVM_CONSTANT_Class entries. 1.233 +// 1.234 +// Now we can get back to the copying complication. When we copy 1.235 +// entries from old_cp to merge_cp, we have to revert any 1.236 +// JVM_CONSTANT_Class entries to JVM_CONSTANT_UnresolvedClass entries 1.237 +// or verification will fail. 1.238 +// 1.239 +// It is important to explicitly state that the merging algorithm 1.240 +// effectively unresolves JVM_CONSTANT_Class entries that were in the 1.241 +// old_cp when they are changed into JVM_CONSTANT_UnresolvedClass 1.242 +// entries in the merge_cp. This is done both to make verification 1.243 +// happy and to avoid adding more brittleness between RedefineClasses 1.244 +// and the constant pool cache. By allowing the constant pool cache 1.245 +// implementation to (re)resolve JVM_CONSTANT_UnresolvedClass entries 1.246 +// into JVM_CONSTANT_Class entries, we avoid having to embed knowledge 1.247 +// about those algorithms in RedefineClasses. 1.248 +// 1.249 +// Appending unique entries from scratch_cp to merge_cp is straight 1.250 +// forward for direct CP entries and most indirect CP entries. For the 1.251 +// indirect CP entry type JVM_CONSTANT_NameAndType and for the double- 1.252 +// indirect CP entry types, the presence of more than one piece of 1.253 +// interesting data makes appending the entries more complicated. 1.254 +// 1.255 +// For the JVM_CONSTANT_{Double,Float,Integer,Long,Utf8} entry types, 1.256 +// the entry is simply copied from scratch_cp to the end of merge_cp. 1.257 +// If the index in scratch_cp is different than the destination index 1.258 +// in merge_cp, then the change in index value is tracked. 1.259 +// 1.260 +// Note: the above discussion for the direct CP entries also applies 1.261 +// to the JVM_CONSTANT_UnresolvedClass entry types. 1.262 +// 1.263 +// For the JVM_CONSTANT_Class entry types, since there is only 1.264 +// one data element at the end of the recursion, we know that we have 1.265 +// either one or two unique entries. If the JVM_CONSTANT_Utf8 entry is 1.266 +// unique then it is appended to merge_cp before the current entry. 1.267 +// If the JVM_CONSTANT_Utf8 entry is not unique, then the current entry 1.268 +// is updated to refer to the duplicate entry in merge_cp before it is 1.269 +// appended to merge_cp. Again, any changes in index values are tracked 1.270 +// as needed. 1.271 +// 1.272 +// Note: the above discussion for JVM_CONSTANT_Class entry 1.273 +// types is theoretical. Since those entry types have already been 1.274 +// optimized into JVM_CONSTANT_UnresolvedClass entry types, 1.275 +// they are handled as direct CP entries. 1.276 +// 1.277 +// For the JVM_CONSTANT_NameAndType entry type, since there are two 1.278 +// data elements at the end of the recursions, we know that we have 1.279 +// between one and three unique entries. Any unique JVM_CONSTANT_Utf8 1.280 +// entries are appended to merge_cp before the current entry. For any 1.281 +// JVM_CONSTANT_Utf8 entries that are not unique, the current entry is 1.282 +// updated to refer to the duplicate entry in merge_cp before it is 1.283 +// appended to merge_cp. Again, any changes in index values are tracked 1.284 +// as needed. 1.285 +// 1.286 +// For the JVM_CONSTANT_{Fieldref,InterfaceMethodref,Methodref} entry 1.287 +// types, since there are two indirect CP entries and three data 1.288 +// elements at the end of the recursions, we know that we have between 1.289 +// one and six unique entries. See the JVM_CONSTANT_Fieldref diagram 1.290 +// above for an example of all six entries. The uniqueness algorithm 1.291 +// for the JVM_CONSTANT_Class and JVM_CONSTANT_NameAndType entries is 1.292 +// covered above. Any unique entries are appended to merge_cp before 1.293 +// the current entry. For any entries that are not unique, the current 1.294 +// entry is updated to refer to the duplicate entry in merge_cp before 1.295 +// it is appended to merge_cp. Again, any changes in index values are 1.296 +// tracked as needed. 1.297 +// 1.298 +// 1.299 +// Other Details: 1.300 +// 1.301 +// Details for other parts of RedefineClasses need to be written. 1.302 +// This is a placeholder section. 1.303 +// 1.304 +// 1.305 +// Open Issues (in no particular order): 1.306 +// 1.307 +// - How do we serialize the RedefineClasses() API without deadlocking? 1.308 +// 1.309 +// - SystemDictionary::parse_stream() was called with a NULL protection 1.310 +// domain since the initial version. This has been changed to pass 1.311 +// the_class->protection_domain(). This change has been tested with 1.312 +// all NSK tests and nothing broke, but what will adding it now break 1.313 +// in ways that we don't test? 1.314 +// 1.315 +// - GenerateOopMap::rewrite_load_or_store() has a comment in its 1.316 +// (indirect) use of the Relocator class that the max instruction 1.317 +// size is 4 bytes. goto_w and jsr_w are 5 bytes and wide/iinc is 1.318 +// 6 bytes. Perhaps Relocator only needs a 4 byte buffer to do 1.319 +// what it does to the bytecodes. More investigation is needed. 1.320 +// 1.321 +// - How do we know if redefine_single_class() and the guts of 1.322 +// InstanceKlass are out of sync? I don't think this can be 1.323 +// automated, but we should probably order the work in 1.324 +// redefine_single_class() to match the order of field 1.325 +// definitions in InstanceKlass. We also need to add some 1.326 +// comments about keeping things in sync. 1.327 +// 1.328 +// - set_new_constant_pool() is huge and we should consider refactoring 1.329 +// it into smaller chunks of work. 1.330 +// 1.331 +// - The exception table update code in set_new_constant_pool() defines 1.332 +// const values that are also defined in a local context elsewhere. 1.333 +// The same literal values are also used in elsewhere. We need to 1.334 +// coordinate a cleanup of these constants with Runtime. 1.335 +// 1.336 + 1.337 +struct JvmtiCachedClassFileData { 1.338 + jint length; 1.339 + unsigned char data[1]; 1.340 +}; 1.341 + 1.342 +class VM_RedefineClasses: public VM_Operation { 1.343 + private: 1.344 + // These static fields are needed by ClassLoaderDataGraph::classes_do() 1.345 + // facility and the AdjustCpoolCacheAndVtable helper: 1.346 + static Array<Method*>* _old_methods; 1.347 + static Array<Method*>* _new_methods; 1.348 + static Method** _matching_old_methods; 1.349 + static Method** _matching_new_methods; 1.350 + static Method** _deleted_methods; 1.351 + static Method** _added_methods; 1.352 + static int _matching_methods_length; 1.353 + static int _deleted_methods_length; 1.354 + static int _added_methods_length; 1.355 + static Klass* _the_class_oop; 1.356 + 1.357 + // The instance fields are used to pass information from 1.358 + // doit_prologue() to doit() and doit_epilogue(). 1.359 + jint _class_count; 1.360 + const jvmtiClassDefinition *_class_defs; // ptr to _class_count defs 1.361 + 1.362 + // This operation is used by both RedefineClasses and 1.363 + // RetransformClasses. Indicate which. 1.364 + JvmtiClassLoadKind _class_load_kind; 1.365 + 1.366 + // _index_map_count is just an optimization for knowing if 1.367 + // _index_map_p contains any entries. 1.368 + int _index_map_count; 1.369 + intArray * _index_map_p; 1.370 + 1.371 + // _operands_index_map_count is just an optimization for knowing if 1.372 + // _operands_index_map_p contains any entries. 1.373 + int _operands_cur_length; 1.374 + int _operands_index_map_count; 1.375 + intArray * _operands_index_map_p; 1.376 + 1.377 + // ptr to _class_count scratch_classes 1.378 + Klass** _scratch_classes; 1.379 + jvmtiError _res; 1.380 + 1.381 + // Performance measurement support. These timers do not cover all 1.382 + // the work done for JVM/TI RedefineClasses() but they do cover 1.383 + // the heavy lifting. 1.384 + elapsedTimer _timer_rsc_phase1; 1.385 + elapsedTimer _timer_rsc_phase2; 1.386 + elapsedTimer _timer_vm_op_prologue; 1.387 + 1.388 + // These routines are roughly in call order unless otherwise noted. 1.389 + 1.390 + // Load the caller's new class definition(s) into _scratch_classes. 1.391 + // Constant pool merging work is done here as needed. Also calls 1.392 + // compare_and_normalize_class_versions() to verify the class 1.393 + // definition(s). 1.394 + jvmtiError load_new_class_versions(TRAPS); 1.395 + 1.396 + // Verify that the caller provided class definition(s) that meet 1.397 + // the restrictions of RedefineClasses. Normalize the order of 1.398 + // overloaded methods as needed. 1.399 + jvmtiError compare_and_normalize_class_versions( 1.400 + instanceKlassHandle the_class, instanceKlassHandle scratch_class); 1.401 + 1.402 + // Figure out which new methods match old methods in name and signature, 1.403 + // which methods have been added, and which are no longer present 1.404 + void compute_added_deleted_matching_methods(); 1.405 + 1.406 + // Change jmethodIDs to point to the new methods 1.407 + void update_jmethod_ids(); 1.408 + 1.409 + // In addition to marking methods as obsolete, this routine 1.410 + // records which methods are EMCP (Equivalent Module Constant 1.411 + // Pool) in the emcp_methods BitMap and returns the number of 1.412 + // EMCP methods via emcp_method_count_p. This information is 1.413 + // used when information about the previous version of the_class 1.414 + // is squirreled away. 1.415 + void check_methods_and_mark_as_obsolete(BitMap *emcp_methods, 1.416 + int * emcp_method_count_p); 1.417 + void transfer_old_native_function_registrations(instanceKlassHandle the_class); 1.418 + 1.419 + // Install the redefinition of a class 1.420 + void redefine_single_class(jclass the_jclass, 1.421 + Klass* scratch_class_oop, TRAPS); 1.422 + 1.423 + void swap_annotations(instanceKlassHandle new_class, 1.424 + instanceKlassHandle scratch_class); 1.425 + 1.426 + // Increment the classRedefinedCount field in the specific InstanceKlass 1.427 + // and in all direct and indirect subclasses. 1.428 + void increment_class_counter(InstanceKlass *ik, TRAPS); 1.429 + 1.430 + // Support for constant pool merging (these routines are in alpha order): 1.431 + void append_entry(constantPoolHandle scratch_cp, int scratch_i, 1.432 + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 1.433 + void append_operand(constantPoolHandle scratch_cp, int scratch_bootstrap_spec_index, 1.434 + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 1.435 + void finalize_operands_merge(constantPoolHandle merge_cp, TRAPS); 1.436 + int find_or_append_indirect_entry(constantPoolHandle scratch_cp, int scratch_i, 1.437 + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 1.438 + int find_or_append_operand(constantPoolHandle scratch_cp, int scratch_bootstrap_spec_index, 1.439 + constantPoolHandle *merge_cp_p, int *merge_cp_length_p, TRAPS); 1.440 + int find_new_index(int old_index); 1.441 + int find_new_operand_index(int old_bootstrap_spec_index); 1.442 + bool is_unresolved_class_mismatch(constantPoolHandle cp1, int index1, 1.443 + constantPoolHandle cp2, int index2); 1.444 + void map_index(constantPoolHandle scratch_cp, int old_index, int new_index); 1.445 + void map_operand_index(int old_bootstrap_spec_index, int new_bootstrap_spec_index); 1.446 + bool merge_constant_pools(constantPoolHandle old_cp, 1.447 + constantPoolHandle scratch_cp, constantPoolHandle *merge_cp_p, 1.448 + int *merge_cp_length_p, TRAPS); 1.449 + jvmtiError merge_cp_and_rewrite(instanceKlassHandle the_class, 1.450 + instanceKlassHandle scratch_class, TRAPS); 1.451 + u2 rewrite_cp_ref_in_annotation_data( 1.452 + AnnotationArray* annotations_typeArray, int &byte_i_ref, 1.453 + const char * trace_mesg, TRAPS); 1.454 + bool rewrite_cp_refs(instanceKlassHandle scratch_class, TRAPS); 1.455 + bool rewrite_cp_refs_in_annotation_struct( 1.456 + AnnotationArray* class_annotations, int &byte_i_ref, TRAPS); 1.457 + bool rewrite_cp_refs_in_annotations_typeArray( 1.458 + AnnotationArray* annotations_typeArray, int &byte_i_ref, TRAPS); 1.459 + bool rewrite_cp_refs_in_class_annotations( 1.460 + instanceKlassHandle scratch_class, TRAPS); 1.461 + bool rewrite_cp_refs_in_element_value( 1.462 + AnnotationArray* class_annotations, int &byte_i_ref, TRAPS); 1.463 + bool rewrite_cp_refs_in_fields_annotations( 1.464 + instanceKlassHandle scratch_class, TRAPS); 1.465 + void rewrite_cp_refs_in_method(methodHandle method, 1.466 + methodHandle * new_method_p, TRAPS); 1.467 + bool rewrite_cp_refs_in_methods(instanceKlassHandle scratch_class, TRAPS); 1.468 + bool rewrite_cp_refs_in_methods_annotations( 1.469 + instanceKlassHandle scratch_class, TRAPS); 1.470 + bool rewrite_cp_refs_in_methods_default_annotations( 1.471 + instanceKlassHandle scratch_class, TRAPS); 1.472 + bool rewrite_cp_refs_in_methods_parameter_annotations( 1.473 + instanceKlassHandle scratch_class, TRAPS); 1.474 + void rewrite_cp_refs_in_stack_map_table(methodHandle method, TRAPS); 1.475 + void rewrite_cp_refs_in_verification_type_info( 1.476 + address& stackmap_addr_ref, address stackmap_end, u2 frame_i, 1.477 + u1 frame_size, TRAPS); 1.478 + void set_new_constant_pool(ClassLoaderData* loader_data, 1.479 + instanceKlassHandle scratch_class, 1.480 + constantPoolHandle scratch_cp, int scratch_cp_length, TRAPS); 1.481 + 1.482 + void flush_dependent_code(instanceKlassHandle k_h, TRAPS); 1.483 + 1.484 + static void dump_methods(); 1.485 + 1.486 + // Check that there are no old or obsolete methods 1.487 + class CheckClass : public KlassClosure { 1.488 + Thread* _thread; 1.489 + public: 1.490 + CheckClass(Thread* t) : _thread(t) {} 1.491 + void do_klass(Klass* k); 1.492 + }; 1.493 + 1.494 + // Unevolving classes may point to methods of the_class directly 1.495 + // from their constant pool caches, itables, and/or vtables. We 1.496 + // use the ClassLoaderDataGraph::classes_do() facility and this helper 1.497 + // to fix up these pointers. 1.498 + class AdjustCpoolCacheAndVtable : public KlassClosure { 1.499 + Thread* _thread; 1.500 + public: 1.501 + AdjustCpoolCacheAndVtable(Thread* t) : _thread(t) {} 1.502 + void do_klass(Klass* k); 1.503 + }; 1.504 + 1.505 + public: 1.506 + VM_RedefineClasses(jint class_count, 1.507 + const jvmtiClassDefinition *class_defs, 1.508 + JvmtiClassLoadKind class_load_kind); 1.509 + VMOp_Type type() const { return VMOp_RedefineClasses; } 1.510 + bool doit_prologue(); 1.511 + void doit(); 1.512 + void doit_epilogue(); 1.513 + 1.514 + bool allow_nested_vm_operations() const { return true; } 1.515 + jvmtiError check_error() { return _res; } 1.516 + 1.517 + // Modifiable test must be shared between IsModifiableClass query 1.518 + // and redefine implementation 1.519 + static bool is_modifiable_class(oop klass_mirror); 1.520 + 1.521 + static jint get_cached_class_file_len(JvmtiCachedClassFileData *cache) { 1.522 + return cache == NULL ? 0 : cache->length; 1.523 + } 1.524 + static unsigned char * get_cached_class_file_bytes(JvmtiCachedClassFileData *cache) { 1.525 + return cache == NULL ? NULL : cache->data; 1.526 + } 1.527 +}; 1.528 +#endif // SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP