request for review (M), 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent
keith.mcguigan at oracle.com
Thu Jan 6 14:13:21 UTC 2011
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.
More information about the hotspot-gc-dev