Mercurial > hg > graal-jvmci-8
diff src/share/vm/oops/markOop.cpp @ 48:d8b3ef7ee3e5
6599425: 4/3 OopMapCache::lookup() can cause later crash or assert() failure
Summary: Add should_not_be_cached() to markOop and methodOop and query that status inOopMapCache::lookup()
Reviewed-by: coleenp, sspitsyn, jmasa
author | dcubed |
---|---|
date | Wed, 12 Mar 2008 18:07:46 -0700 |
parents | a61af66fc99e |
children | d1605aabd0a1 |
line wrap: on
line diff
--- a/src/share/vm/oops/markOop.cpp Wed Mar 12 18:06:50 2008 -0700 +++ b/src/share/vm/oops/markOop.cpp Wed Mar 12 18:07:46 2008 -0700 @@ -37,3 +37,32 @@ st->print("age %d)", age()); } } + + +// Give advice about whether the oop that contains this markOop +// should be cached or not. +bool markOopDesc::should_not_be_cached() const { + // the cast is because decode_pointer() isn't marked const + if (is_marked() && ((markOopDesc *)this)->decode_pointer() != NULL) { + // If the oop containing this markOop is being forwarded, then + // we are in the middle of GC and we do not want the containing + // oop to be added to a cache. We have no way of knowing whether + // the cache has already been visited by the current GC phase so + // we don't know whether the forwarded oop will be properly + // processed in this phase. If the forwarded oop is not properly + // processed, then we'll see strange crashes or asserts during + // the next GC run because the markOop will contain an unexpected + // value. + // + // This situation has been seen when we are GC'ing a methodOop + // because we use the methodOop while we're GC'ing it. Scary + // stuff. Some of the uses the methodOop cause the methodOop to + // be added to the OopMapCache in the instanceKlass as a side + // effect. This check lets the cache maintainer know when a + // cache addition would not be safe. + return true; + } + + // caching the containing oop should be just fine + return false; +}