RFR(S): 8214172: GC interface entry points for loop opts
Roman Kennke
rkennke at redhat.com
Wed Nov 21 09:52:13 UTC 2018
This looks mostly good to me. I like the extra phase for barrier expansion.
- Instead of exposing _loop_opts_cnt, can we keep it private, and
provide accessors like dec_loop_opts_cnt() and the usual getter?
Somebody ought to look at the loop* changes. Not my field of expertise ;-)
Thanks,
Roman
> http://cr.openjdk.java.net/~roland/8214172/webrev.00/
>
> For Shenandoah, we apply our own set of optimizations as part of loop
> optimizations. This patch adds some hooks for this.
>
> Shenandoah:
>
> 1- optimizes its write barriers during loop optimizations
> 2- expands write barriers as a special pass of loop optimizations (write
> barriers are kept floating for most of optimizations and then need to be
> pinned which requires control and dominator information)
> 3- has a few optimizations that are applied to expanded write barriers
> as further passes of optimizations after expansion
>
> Because of 2-, this patch changes the gc interface for barrier expansion
> so it doesn't have to happen as part of macro expansion.
>
> Because of 3-, we call back Compile::optimize_loops() from shenandoah
> code, I made _loop_opts_cnt an instance variable so a global count can
> be kept and there's no need to pass it around across multiple gc
> interface calls.
>
> Because of 3-, we optimize loops after loop strip mined loops are fully
> expanded. So we must not create new loop strip mined loops in those
> passes. The logic in PhaseIdealLoop::verify_strip_mined_scheduling()
> breaks in that case too so it is skipped for those passes.
>
> Roland.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20181121/1f4761a1/signature.asc>
More information about the hotspot-compiler-dev
mailing list