RFR: Fix safepoint

Roman Kennke rkennke at redhat.com
Thu Jun 30 07:38:02 UTC 2016


Am Donnerstag, den 30.06.2016, 09:27 +0200 schrieb Roland Westrelin:
> > 
> > In Safepoint::push_monitor() we skip over shenandoah barriers when
> > linking a lock's object to the safepoint. I think that's wrong. The
> > inputs to a SafepointNode are used to build the oopmap for that
> > safepoint. If have this wb->sp->lock, and at the safepoint, the
> > output
> > of the wb is not in the oopmap, we may get a fromspace-ref in the
> > locking code.
> > 
> > The patch reverts back to the original code that does not skip the
> > shenandoah barrier. It fixes SPECjvm benchmarks that were crashing
> > before.
> > 
> > http://cr.openjdk.java.net/~rkennke/fixsafepoint/webrev.01/
> > 
> > Ok to commit+push?
> Could this be fixed on the runtime/GC side?

I don't see how. If we don't link it to the SafepointNode, it will not
end up in the oopmap, and thus we don't even see it in the runtime. 


> Scalar replaced objects are also affected by a similar problem
> AFAICT.
> It's not optimal to keep barriers in the code that are potentially
> useless.

We can only eliminate them if we know 100% they are useless. I think :-
)

Roman



More information about the shenandoah-dev mailing list