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
