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