RFR(L): 8185265 [MVT] improve performance of return of value types with new calling convention

Roland Westrelin rwestrel at redhat.com
Fri Aug 4 19:42:11 UTC 2017

(that patch includes some runtime/interpreter changes)


JDK-8184795 disabled compilation of LFs as compilation root if they
return a value type. The logic in CheckCastPPNode::Ideal() expects
values to be returned in registers but if the called method is a lambda
form, a value can be returned as a buffered value. I fixed the logic in
CheckCastPPNode::Ideal() to properly handle return of a buffered value.

One of Sergey's micro benchmarks takes forever to warmup. I found it's
related to the return of value types and, in particular, calling the
runtime to pack/unpack values (i.e. load fields in registers on return,
allocate a buffered value and initialize it once returned to the
caller).  It causes a ~10x slow down during warmup. To address this, the
VM now generates little pieces of assembly code to perform the packing
or unpacking. On return, unpacking a buffered value is performed by
calling the value klass's unpack unhandler. When returned in the caller,
a fast path allocation is attempted for a new value from the TLAB (I
left off heap buffers out for now). If that allocation succeeds the
value klass pack handler is called an initializes the value. If the
allocation fails, we fall back to the same runtime call that is used
currently (that calls knows there can be live oops, where to look for
them and how to preserve them across a GC).

C2 doesn't support calling to an address that is loaded in a register. I
hacked support for it from the existing CallLeafNoFP node. It's somewhat
ugly but I would say it's good enough for now.

With this change, AFAICT, the warmup issue caused by return of value
types in Sergey's test is gone. It doesn't mean it warmups fast (we
still have some disabled compilation of LF for another reason) but it's
now decent.


More information about the valhalla-dev mailing list