[9] RFR (XS): 8036588 : VerifyFieldClosure fails instanceKlass:3133

[Igor Veresov]

That looks good to me.

igor

On Jul 8, 2014, at 12:13 PM, David Chase <david.r.chase at oracle.com> wrote:

> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8036588 (closed because only seen in SQE)
> 
> webrev: http://cr.openjdk.java.net/~drchase/8036588/webrev.00/
> 
> cause+fix: 
> The root cause is use of the wrong liveness information at deoptimization point.
> The old code uses the optimizer's notion of "live" -- but deoptimization transfers to the
> interpreter and which can (will) manipulate values that are dead to the optimizer.
> The trigger is very tricky -- the following things need to happen:
> 
> 1) an object D that will be dead is allocated
> 2) a method M is invoked that returns an object F, to only be stored in a field f of D
> 3) the optimizer eliminates the allocation of D and the storefield into D.f
> 4) deoptimization hits an execution of M; deoptimization reallocates D for the
>    interpreter; BUT the reallocation triggers a GC, which would forward F if
>    it had been correctly noted as live out of the call to M (but the bug is that it
>    was not).
> 5) the interpreter evaluates D.f = F (this succeeds)
> 6) before the frame with D in it exits, ANOTHER garbage collection occurs (or perhaps
>     GC was running concurrently in some way) and attempts to trace/copy through
>     D and D.f.
> 7) Hilarity ensues.
> 8) For extra giggles, this has only ever been observed with -Xmx=32G (or the corresponding
>     -XX:MaxRAMFraction= option) plus of course -XX:+DeoptimizeALot.  Also setting
>    -XX:DeoptimizeALotInterval=1 increases the failure rate to about 10% of test runs.
>    There's some additional missing context, because following this recipe to write a simpler
>    test for public consumption did not result in a crashing program.
> 
> fix: Use a simpler test for "pointer is live from M" -- if the return type is an object,
>      then it is "live", at least for the interpreter.
> 
> testing: 
>  jtreg of runtime, gc, compiler
> 
>  got to the point where I could see fails often enough for the two tests known to trigger this,
>  and after the fix neither test was observed to fail even once, even with hundreds of repetitions.