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

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Nov 27 00:52:42 UTC 2018

On 11/22/18 6:40 AM, Roland Westrelin wrote:
> 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.

I prefer if you add checks for gc specific modes to stop_early.

>> 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.

Got it.


> Roland.

More information about the hotspot-compiler-dev mailing list