1.1 --- a/src/share/vm/oops/markOop.cpp Fri Aug 31 16:39:35 2012 -0700
1.2 +++ b/src/share/vm/oops/markOop.cpp Sat Sep 01 13:25:18 2012 -0400
1.3 @@ -1,5 +1,5 @@
1.4 /*
1.5 - * Copyright (c) 1997, 2010, Oracle and/or its affiliates. All rights reserved.
1.6 + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights reserved.
1.7 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
1.8 *
1.9 * This code is free software; you can redistribute it and/or modify it
1.10 @@ -50,32 +50,3 @@
1.11 st->print("age %d)", age());
1.12 }
1.13 }
1.14 -
1.15 -
1.16 -// Give advice about whether the oop that contains this markOop
1.17 -// should be cached or not.
1.18 -bool markOopDesc::should_not_be_cached() const {
1.19 - // the cast is because decode_pointer() isn't marked const
1.20 - if (is_marked() && ((markOopDesc *)this)->decode_pointer() != NULL) {
1.21 - // If the oop containing this markOop is being forwarded, then
1.22 - // we are in the middle of GC and we do not want the containing
1.23 - // oop to be added to a cache. We have no way of knowing whether
1.24 - // the cache has already been visited by the current GC phase so
1.25 - // we don't know whether the forwarded oop will be properly
1.26 - // processed in this phase. If the forwarded oop is not properly
1.27 - // processed, then we'll see strange crashes or asserts during
1.28 - // the next GC run because the markOop will contain an unexpected
1.29 - // value.
1.30 - //
1.31 - // This situation has been seen when we are GC'ing a methodOop
1.32 - // because we use the methodOop while we're GC'ing it. Scary
1.33 - // stuff. Some of the uses the methodOop cause the methodOop to
1.34 - // be added to the OopMapCache in the instanceKlass as a side
1.35 - // effect. This check lets the cache maintainer know when a
1.36 - // cache addition would not be safe.
1.37 - return true;
1.38 - }
1.39 -
1.40 - // caching the containing oop should be just fine
1.41 - return false;
1.42 -}
