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