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