RFR(M): 8024069: replace_in_map() should operate on parent maps

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Oct 14 16:10:35 PDT 2013


Why in LateInlineCallGenerator::do_late_inline() you pass NULL?:
_inline_cg->generate(jvms, NULL);

In general, why we should care about intrinsics? There should be no 
inlining in them. And we will get speculative argument for instrinsics 
without recording parent parser in them. If we ignore intrinsics, we 
will need only cases when is_Parse() returns Parse object and we don't 
need parent_parser(). What I am missing?
Also why not use parser->caller()->map()? jvms() comes from GraphKit and 
if there was not inlined call before map() will point to it (deep clone) 
instead of the parent's map.

And I don't understand where 1) requirement comes from.

I am fine with moving is_uncommon_trap_*() mathods.

Thanks,
Vladimir

On 10/12/13 2:31 PM, Roland Westrelin wrote:
> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods.
>
> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers.
>
> http://cr.openjdk.java.net/~roland/8024069/webrev.00/
>
> Roland.
>


More information about the hotspot-compiler-dev mailing list