RFR(M): 8024069: replace_in_map() should operate on parent maps
roland.westrelin at oracle.com
Wed Oct 16 02:23:17 PDT 2013
On Oct 15, 2013, at 8:50 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> On Oct 12, 2013, at 2:31 PM, Roland Westrelin <roland.westrelin at oracle.com> 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.
> What if we would do a deep-clone? Are there any potential performance or memory issues?
What this change targets is stuff happening during inlining. Inlining is not performed from within a PreserveJVMState. So the PreserveJVMState case is not something we want to optimize for. We just want to make sure a replace_in_map called from within a PreserveJVMState doesn't break something.
>> 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.
More information about the hotspot-compiler-dev