During my investigation of the following bug:

    6497639 4/3 Profiling Swing application caused JVM crash

I tripped across this problem with the OopMapCache.

The failure modes that I observed:

- SIGSEGV in markOopDesc::prototype_for_object()
- Internal Error (src/share/vm/oops/markOop.inline.hpp:80)
  Error: assert(prototype_header == prototype() ||
         prototype_header->has_bias_pattern(),"corrupt prototype header")

Currently this failure is only reproducible using the testing
set up that I have for 6497639.


Bug prerequisites:

- Client VM with sharing enabled
  Update: reproduced this failure on 2008.01.11 without sharing;
  it took more playing with Java2Demo, but it crahed
- Full GC in progress; we are in GC phase 3
- target methodOop is from a shared class
- target methodOop is being forwarded
- target methodOop is found on the stack of a JavaThread
- the instanceKlass' OopMapCache has already been forwarded and
  adjusted so the entry that refers to our method contains the
  forwardee methodOop

We're in the middle of a Full GC. The VMThread is walking JavaThread
stacks and runs into a methodOop that refers to an object that is being
forwarded. The VMThread creates a methodHandle via
methodOopDesc::mask_for(). The methodHandle is eventually passed to
OopMapCache::lookup(). Because this methodHandle is owned by the
VMThread, it has not yet been adjusted to the new location. The
OopMapCache's methodOop has already been adjusted to the new location.
The lookup() code does not find a match in the OopMapCache so the
VMThread's methodOop is added to the OopMapCache. Unfortunately, the
methodOop's mark word still contains the forwarding info so things blow
up later.

Here is a snippet of a stack from a subsequent blow up:

  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [8] markOopDesc::prototype_for_object(0xd4c047d0, 0xd05c0000, 0x1, 0xfee4a800, 0xd929f5d8, 0x15c), at 0xfec01234
  [9] MarkSweep::mark_object(0xd4c047d0, 0x20, 0x1, 0xfee45000, 0x0, 0x0), at 0xfec015c8
  [10] MarkSweep::_mark_and_push(0xa3610, 0xa3610, 0x21, 0x80, 0xd4c047d0, 0xfee4b000), at 0xfe98c8d0
  [11] OopMapCache::oop_iterate(0x3fd2b0, 0xfee4b0f0, 0xfee4b1b0, 0xfe98d240, 0x3, 0x2), at 0xfe986ae8
  [12] instanceKlassKlass::oop_follow_contents(0xd8c00890, 0x3fd2b0, 0xfee4b000, 0xd8c84740, 0xd845c018, 0x3), at 0xfe98d05c
  [13] MarkSweep::FollowRootClosure::do_oop(0xd8c00888, 0x2950940, 0xfee4b0d0, 0xfc, 0x3f, 0x40), at 0xfe98c700
  [14] SystemDictionary::shared_oops_do(0xfee4b0f8, 0x18000, 0xfee4b194, 0xfe98c660, 0xfee38000, 0x18210), at 0xfeca3bf0
  [15] Universe::oops_do(0xfee4b0f8, 0x0, 0x33188, 0x0, 0xfee38000, 0xfee50800), at 0xfecbe820
  [16] SharedHeap::process_strong_roots(0x33090, 0x1, 0x2, 0xfee4b0f8, 0xfee4b0f8, 0x0), at 0xfec66ad4
  [17] GenCollectedHeap::gen_process_strong_roots(0x33090, 0x1, 0x0, 0x1, 0x0, 0xfee4b0f8), at 0xfeaafc70
  [18] GenMarkSweep::mark_sweep_phase1(0x1, 0xfee4b000, 0xfed73000, 0x2, 0x30e28, 0x0), at 0xfeab228c

The forwarding info in the mark word is used in the
markOopDesc::prototype_for_object() call. The failure modes
I've seen are SIGSEGVs and assertion failures.