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

[Vladimir Kozlov]

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.

Thanks,
Vladimir

> 
> Roland.
>