Mercurial > hg > graal-compiler
annotate src/share/vm/prims/jvmtiRedefineClasses.hpp @ 3992:d1bdeef3e3e2
7098282: G1: assert(interval >= 0) failed: Sanity check, referencePolicy.cpp: 76
Summary: There is a race between one thread successfully forwarding and copying the klass mirror for the SoftReference class (including the static master clock) and another thread attempting to use the master clock while attempting to discover a soft reference object. Maintain a shadow copy of the soft reference master clock and use the shadow during reference discovery and reference processing.
Reviewed-by: tonyp, brutisso, ysr
| author | johnc |
|---|---|
| date | Wed, 12 Oct 2011 10:25:51 -0700 |
| parents | 1d1603768966 |
| children | da91efe96a93 |
| rev | line source |
|---|---|
| 0 | 1 /* |
|
2426
1d1603768966
7010070: Update all 2010 Oracle-changed OpenJDK files to have the proper copyright dates - second pass
trims
parents:
2177
diff
changeset
|
2 * Copyright (c) 2003, 2011, Oracle and/or its affiliates. All rights reserved. |
| 0 | 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 * | |
|
1552
c18cbe5936b8
6941466: Oracle rebranding changes for Hotspot repositories
trims
parents:
0
diff
changeset
|
19 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA |
|
c18cbe5936b8
6941466: Oracle rebranding changes for Hotspot repositories
trims
parents:
0
diff
changeset
|
20 * or visit www.oracle.com if you need additional information or have any |
|
c18cbe5936b8
6941466: Oracle rebranding changes for Hotspot repositories
trims
parents:
0
diff
changeset
|
21 * questions. |
| 0 | 22 * |
| 23 */ | |
| 24 | |
| 1972 | 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 | |
| 0 | 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 | |
|
2177
3582bf76420e
6990754: Use native memory and reference counting to implement SymbolTable
coleenp
parents:
1972
diff
changeset
|
226 // JVM_CONSTANT_StringIndex entries are changed into Symbol*s and the |
|
3582bf76420e
6990754: Use native memory and reference counting to implement SymbolTable
coleenp
parents:
1972
diff
changeset
|
227 // entries are modified to refer to the Symbol*s. This optimization |
| 0 | 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 | |
| 345 class 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 }; | |
| 1972 | 501 |
| 502 #endif // SHARE_VM_PRIMS_JVMTIREDEFINECLASSES_HPP |