Some incremental inlining fixes

Tobias Hartmann tobias.hartmann at oracle.com
Thu Mar 9 09:57:32 UTC 2017


Hi Roland,

On 09.03.2017 09:58, Roland Westrelin wrote:
> 
> http://cr.openjdk.java.net/~roland/valhalla/incrementalinlining2/webrev.00/
> 
> With incremental inlining, an inlined call that returns a value type can
> be first compiled as a call. The compiler then expects a ptr to the
> result to be returned. When the method is inlined incrementally, it thus
> has to return a ptr and so allocates an object for the value type. We
> then rely on escape analysis + scalarization to eliminate the allocation
> and obtain the same result we would get with parse time inlining. EA +
> scalarization doesn't support value type ptrs. This change tweaks the
> code so it is now enabled for them. 

Looks good to me.

> Sometimes, a value type allocation
> is not eliminated because it is referenced by a value type node itself
> referenced by a safepoint. The change in SafePointNode::Ideal fixes
> that. 

The comment in SafePointNode::Ideal is a bit misleading because "a valid object input" could also mean that the ValueTypeNode has an object *field* input.

Maybe change it to:
1147     // An allocated ValueTypeNode in the debug info?
1148     // Reference the oop directly. Helps removal of useless value
1149     // type allocations with incremental inlining.

You don't need to send an updated webrev.

> The change also includes some fixes to replay inlining to record
> static fields that are value types and replay them.

Very nice!

Thanks,
Tobias



More information about the valhalla-dev mailing list