invalid oops during oop_do() iteration?

[Keith McGuigan]

Hello,

In some recent changes to JVMTI breakpoint code, I added some code to  
update a cache during an oop_do() iteration over of methodOop.  The  
cache update involves dereferencing the methodOop's constMethodOop and  
getting the address to the code in it.

Essentially, I'm doing something like this:

JvmtiBreakpoint::oops_do(OopClosure* f) {
   for (int i = 0; i < _num_methods; ++i) {
     methodOop* m = method_at(i);
     f->do_oop(m);

   // update the cache in case the methodOop moved
    _cache[i] =  (*m)->code_base() + _bci;
   }
}

(The actual code is in GrowableCache::oops_do() in jvmtiImpl.cpp, but  
this is the general idea)

Doing this assumes that the methodOops will always be valid and refer  
to the same method.  Considering what I'm seeing, I think this might  
be an invalid assumption.   When oops_do() is called from  
PSMarkSweep::mark_sweep_phase3(), I occasionally see that the  
resulting methodOop* refers to something else when I'm updating the  
cache (not sure what, but it doesn't appear to be the same  
methodOop).  It appears to be reset correctly in a later oops_do()  
iteration.

Is this expected?  And if so, is there any way for me to tell when  
doing the oops_do() whether or not the resulting oops are valid?   
We're seeing assertion failures and crashes in nightly testing when  
the oop is not the methodOop that we expected.  I'll take a quick hack  
to make it work for now if we can fix it better later.

If you've got anything for me to try, IM me (or email, but IM might be  
faster) and I'll give it a shot.

--
- Keith