1.1 --- a/src/share/vm/oops/markOop.cpp Thu Mar 13 05:40:44 2008 -0700
1.2 +++ b/src/share/vm/oops/markOop.cpp Thu Mar 13 14:17:48 2008 -0700
1.3 @@ -37,3 +37,32 @@
1.4 st->print("age %d)", age());
1.5 }
1.6 }
1.7 +
1.8 +
1.9 +// Give advice about whether the oop that contains this markOop
1.10 +// should be cached or not.
1.11 +bool markOopDesc::should_not_be_cached() const {
1.12 + // the cast is because decode_pointer() isn't marked const
1.13 + if (is_marked() && ((markOopDesc *)this)->decode_pointer() != NULL) {
1.14 + // If the oop containing this markOop is being forwarded, then
1.15 + // we are in the middle of GC and we do not want the containing
1.16 + // oop to be added to a cache. We have no way of knowing whether
1.17 + // the cache has already been visited by the current GC phase so
1.18 + // we don't know whether the forwarded oop will be properly
1.19 + // processed in this phase. If the forwarded oop is not properly
1.20 + // processed, then we'll see strange crashes or asserts during
1.21 + // the next GC run because the markOop will contain an unexpected
1.22 + // value.
1.23 + //
1.24 + // This situation has been seen when we are GC'ing a methodOop
1.25 + // because we use the methodOop while we're GC'ing it. Scary
1.26 + // stuff. Some of the uses the methodOop cause the methodOop to
1.27 + // be added to the OopMapCache in the instanceKlass as a side
1.28 + // effect. This check lets the cache maintainer know when a
1.29 + // cache addition would not be safe.
1.30 + return true;
1.31 + }
1.32 +
1.33 + // caching the containing oop should be just fine
1.34 + return false;
1.35 +}
