RFR: JDK-8213615: GC/C2 abstraction for escape analysis

Vladimir Kozlov 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 
as before.

Vladimir

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:
> https://builds.shipilev.net/patch-openjdk-shenandoah-jdk-only-shared/b64-vs-dc1f9dec2018/src/hotspot/share/opto/escape.cpp.sdiff.html
> 
> 
> The following proposed changeset covers all needs of G1, ZGC and Shenandoah:
> http://cr.openjdk.java.net/~rkennke/JDK-8213615/webrev.01/
> 
> 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.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8213615
> 
> Testing: passes hotspot/jtreg:tier1 locally.
> 
> Thoughts? Reviews?
> 
> Roman
> 


More information about the hotspot-gc-dev mailing list