RFR(S): 8214172: GC interface entry points for loop opts

Roland Westrelin rwestrel at redhat.com
Thu Nov 22 14:40:59 UTC 2018

Hi Vladimir,

Thanks for looking at this.

> Why you changed stop_early conditions?

With Shenandoah, we have a couple extra LoopOptsMode. When loop opts are
run with one of the shenandoah specific modes, we don't want stop_early
to be true otherwise the gc specific calls won't be executed. One
solution would be to add more checks for gc specific modes to
stop_early. The other solution is to pick the only mode for which
stop_early is true.

> Why you have strip_mined_loops_expanded shenandoah specific? And why you need it?

We run loop opts after strip mined loops are expanded as extra rounds of
loop optimizations. When running after strip mined loops are expanded,
new counted loop cannot be created because then new strip mined loop
would be created which we would never be expanded. In the current code,
strip mined loops are expanded after loop opts so there's no need to
worry about loop opts happening after.


More information about the hotspot-compiler-dev mailing list