--- a/src/share/vm/oops/markOop.cpp	Mon Nov 12 18:11:17 2012 +0100
+++ b/src/share/vm/oops/markOop.cpp	Mon Nov 12 23:14:12 2012 +0100
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1997, 2010, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -50,32 +50,3 @@
     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;
-}