RFR: JDK-8213615: GC/C2 abstraction for escape analysis
vladimir.kozlov at oracle.com
Fri Nov 9 18:03:35 UTC 2018
I like proposal from JIT POV. I did not look in details but we need to make sure that changes produce the same results
On 11/9/18 8:46 AM, Roman Kennke wrote:
> There's plenty of GC related+specific (G1, ZGC, Shenandoah) code in
> escape.cpp that needs to be abstracted out into BarrierSetC2 or similar.
> Consider for example the mess we needed to make in Shenandoah:
> The following proposed changeset covers all needs of G1, ZGC and Shenandoah:
> Some notes:
> - Similar to how it works with the hooks for
> Compile::final_graph_reshaping(), if GC returns true (meaning the GC
> completely handled the current node), the main switch is skipped.
> - The bodies of the unsafe (CAS, etc) handlers are factored out so that
> they can be called back from GC handlers. For example, in Shenandoah we
> have our own set of CAS nodes that need to call back into those.
> - A bunch of methods in ConnectionGraph (e.g. add_local_var_and_edge)
> needed to be made public so that they can be accessed from the GC code.
> - ConnectionGraph::record_for_optimizer() body has been moved into
> escape.cpp because it depends on PhaseIterGVN to be known, and I did not
> feel like adding include phaseX.hpp to escape.hpp. This popped up
> because of changed include order.
> Testing: passes hotspot/jtreg:tier1 locally.
> Thoughts? Reviews?
More information about the hotspot-compiler-dev