35 st->print("mark("); |
35 st->print("mark("); |
36 st->print("hash %#lx,", hash()); |
36 st->print("hash %#lx,", hash()); |
37 st->print("age %d)", age()); |
37 st->print("age %d)", age()); |
38 } |
38 } |
39 } |
39 } |
|
40 |
|
41 |
|
42 // Give advice about whether the oop that contains this markOop |
|
43 // should be cached or not. |
|
44 bool markOopDesc::should_not_be_cached() const { |
|
45 // the cast is because decode_pointer() isn't marked const |
|
46 if (is_marked() && ((markOopDesc *)this)->decode_pointer() != NULL) { |
|
47 // If the oop containing this markOop is being forwarded, then |
|
48 // we are in the middle of GC and we do not want the containing |
|
49 // oop to be added to a cache. We have no way of knowing whether |
|
50 // the cache has already been visited by the current GC phase so |
|
51 // we don't know whether the forwarded oop will be properly |
|
52 // processed in this phase. If the forwarded oop is not properly |
|
53 // processed, then we'll see strange crashes or asserts during |
|
54 // the next GC run because the markOop will contain an unexpected |
|
55 // value. |
|
56 // |
|
57 // This situation has been seen when we are GC'ing a methodOop |
|
58 // because we use the methodOop while we're GC'ing it. Scary |
|
59 // stuff. Some of the uses the methodOop cause the methodOop to |
|
60 // be added to the OopMapCache in the instanceKlass as a side |
|
61 // effect. This check lets the cache maintainer know when a |
|
62 // cache addition would not be safe. |
|
63 return true; |
|
64 } |
|
65 |
|
66 // caching the containing oop should be just fine |
|
67 return false; |
|
68 } |