RFR: 8320128: Clean up Parse constructor for OSR

Xin Liu xliu at openjdk.org
Tue Nov 21 05:23:04 UTC 2023


On Wed, 15 Nov 2023 07:01:35 GMT, Xin Liu <xliu at openjdk.org> wrote:

> There's a special case for the constructor of Parse. If current compilation is OSR and it is handling the top-level method(depth() == 1), then
> 
> 1. _tf = C->tf();
> 2. _entry_bci = C->entry_bci();
> 3. _flow = method()->get_osr_flow_analysis(_entry_bci);
> 
> We don't need to assign those member data twice. We can also factor out _flow->failing() for the special case and normal cases. 
> 
> It's worth mentioning that we can't save ciTypeFlow computation because
> get_osr_flow_analysis(_entry_bci) actually needs get_flow_analysis(method()).

hi, @TobiHartmann
[Those 3 lines](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/parse1.cpp#L414-L416) of code are confusing. 
1. is_osr_parse() is certainly false here. _entry_bci is assigned to InvocationEntryBci at 404.
2. logic like "**is_osr_parse() ? caller->caller() : caller**" is suspicious! I guess the author wants to stress that osr compilation is artifactual. We should get its surrounding JVMState. From my reading of Compile::build_start_state(), I don't think it's true. caller->caller() is null. 
3. I also not sure what's the point of find_subtree_from_root() call here. it doesn't save or print ILT. its only side effect is assertions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16669#issuecomment-1820258714


More information about the hotspot-compiler-dev mailing list