RFR: 8289943: Simplify some object allocation merges
Cesar Soares
duke at openjdk.org
Mon Jul 11 19:38:44 UTC 2022
On Fri, 8 Jul 2022 23:34:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> This is good starting point. To have new "Phi" type node to collect information about merged allocation.
> I need more time to dive into changes to give review.
Thanks for taking the time to look into this!
> I currently found one issue we need discuss - merge allocation of different subclasses (of the same parent class) which may have different number of fields. Current implementation assume objects are the same but I don't see the check for it during RAM node creation. May be we should have it at this initial implementation.
Got it. I'll create some tests for this and see what happens.
> What about adjust_scalar_replaceable_state() code mark allocation as non-SR if they are merged?
I didn't get this part. Can you please clarify?
> About input memory slices. Since merged allocation are SR we should have some new memory Phi created in EA split_memory_phi() which we can try to identify instead of adding all memory slices we find (I am talking about RAM constructor).
I'll take a look into that. Thanks for the suggestion.
> I see you bailed compilation to recompile in case you can't remove RAM node. I think it is fine for initial implementation.
Great.
-------------
PR: https://git.openjdk.org/jdk/pull/9073
More information about the hotspot-compiler-dev
mailing list