RFR (XS): 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj

[Srinivas Ramakrishna]

Hi John -- I am wondering if we should simply prevent the second closure
application if we have already
done it once. That is easy to set-up. Of course such a test penalizes all
collectors when they scan Reference objects, but perhaps the cost of the
test
will be lost in the noise of all the other test-logic when scanning
Reference objects...

But since G1 deals with multiple scans anyway, perhaps this is not worth
worrying over.

I also have some related questions: what forces G1 to have to deal with the
multiple scan possibility anyway?
I had previously incorrectly assumed that G1's remembered set scanning also
avoids multiple scans of any
reference...

In the scenario that you outlined, when the second thread processes the
reference the second
time, how does it determine that it should do nothing? (I guess I am asking
for a pointer to the
code that does the processing of the stack elements and does the recursive
copying.)

thanks!
-- ramki

On Wed, Nov 30, 2011 at 11:23 AM, John Cuthbertson <
john.cuthbertson at oracle.com> wrote:

> Hi Everyone,
>
> Can I have a couple of volunteers look over the fix for this CR? The
> webrev can be found at: http://http://cr.openjdk.java.**
> net/~johnc/7114095/webrev.0/<http://cr.openjdk.java.net/%7Ejohnc/7114095/webrev.0/>
>
> Summary:
> As a result of the changes for 4965777, we could apply the
> G1ParScanClosure twice to the discovered field of a reference object. Once
> because the closure itself has the apply_to_weak_discovered_field attribute
> (as I think it should) and the other because of the changes for 4965777.
> This causes the discovered field of an evacuated reference object to be
> pushed to the _refs_to_scan queue twice. Normally this is not a problem as
> the evacuation code can handle seeing the same object more than once. In
> this case however, if the result of the first push is stolen and the
> referenced object successfully evacuated by another worker thread, then the
> assert is too strong.  The other worker will update the discovered field to
> point to the new location while the current thread is pushing the
> discovered field for the second time. As a result when the current thread
> executes the assert, the discovered field could have been updated and trips
> the assert.
>
> The solution is to weaken the assert slightly.
>
> Testing: Both failing test cases running continuously overnight (they
> typically fail within a few iterations); the GC test suite with a delay in
> the offending code; jprt.
>
> Thanks,
>
> JohnC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111201/6091b356/attachment.htm>