request for review (M), 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent

[Keith McGuigan]

On Jan 6, 2011, at 9:01 AM, Alan Bateman wrote:

> Keith McGuigan wrote:
>>
>> :
>> I'll find and fix those comments.  Can you expand upon what you  
>> mean by "re-hash to the same slot"?  I don't understand how that  
>> would work.
> Sorry for the delay getting back to you on this. I was just  
> wondering about JvmtiTagMap::do_weak_oops and whether the  
> delayed_add list could be avoided. Maybe not and I was just  
> wondering about the cost of visiting objects that were re-hashed to  
> higher slots. I guess it's an is_alive vs. iterating over the  
> delay_add list to put the entries into the right place. The hashing  
> code would be the same.

Actually, we cannot re-visit an object that was re-hashed to a higher  
slot.   The body of one of those closures asserts out if you pass an  
oop in it's new location (I think it's expecting to see a fowarding  
pointer and doesn't see it).  This is why I added the delayed_add list  
originally.   We could flag these entries as "already-moved" or  
something like that, and reset the flag as we encounter them instead  
of passing them to the iterator.   I didn't do that at first because I  
didn't want to make the entries bigger and use more memory, but maybe  
I could do some bit tricks in the oop*.  I'd rather not have to resort  
to that unless the cost of processing the delayed list is an issue.   
It doesn't appear to be at the moment.

--
- Keith