RFR (XS): JDK-8040977: G1 crashes when run with -XX:-G1DeferredRSUpdate

Thomas Schatzl thomas.schatzl at oracle.com
Tue May 27 10:39:16 UTC 2014


Hi Bengt,

  thanks for the review.

On Wed, 2014-04-30 at 12:50 +0200, Bengt Rutisson wrote:
> Hi Thomas,
> 
> On 2014-04-22 14:56, Thomas Schatzl wrote:
> > Hi all,
> >
> >    can I have reviews for this change? It fixes wrong order of
> > declaration of members of G1ParScanThreadState that causes crashes when
> > G1DeferredRSUpdate is disabled.
> >
> > The change is based on the changes for 8035400 and8035401 posted recently.
> >
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8040977
> >
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8040977/webrev/
> 
> I realize that this fixes the code but I would really appreciate a more 
> stable way of handling the dependencies.
> 
> As it it now we end up calling methods on a G1ParScanThreadState 
> instance while we are setting it up. This seems broken to me and will 
> probably lead to similar initialization order issues again. Best would 
> be to not pass "this" to the constructor of G1ParScanClosure and instead 
> manage the circular dependency between G1ParScanClosure and 
> G1ParScanThreadState more explicitly after they have both been properly 
> set up.
> 
> Second best would be to at least pass the worker id/queue num as a 
> separate parameter to avoid having to call methods on an uninitialized 
> object.

I fixed this implementing the former idea. Also added some 

New webrev at 
http://cr.openjdk.java.net/~tschatzl/8040977/webrev.1/

(Sorry, I already had merged the changes before making a diff webrev -
however, most changes in the VM code have been redone anyway. The test
case stayed the same).

Thanks,
  Thomas



More information about the hotspot-gc-dev mailing list