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