RFR: JDK-8213615: GC/C2 abstraction for escape analysis
rkennke at redhat.com
Fri Nov 9 19:45: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.
Yes. I gave my best to make the results /code paths taken identical, but
it's better to give it some scrutiny.
> 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
>> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev