RFR(S): 8214172: GC interface entry points for loop opts
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.
More information about the hotspot-compiler-dev