Return value type fields in registers

Roland Westrelin rwestrel at redhat.com
Mon May 29 16:24:24 UTC 2017


Here is a new webrev for this. This one relies on Maurizio's patches to
the method handles runtime (to generate lambda forms specialized to
the value type supertype).

Interpreter methods now returns a pointer to the returned value type
instance and the fields of the value types.

Compiled methods now returns a pointer to the returned value type's
klass and the fields of the values types.

Interpreter->interpreter returns still go through a runtime call but
that runtime call finds that the first argument is an oop and returns
without doing anything else.

Compiled code->interpreter returns go through the same runtime call
which uses the klass pointer that is returned to allocate a new value
type instance that is then initialized from the values of the fields
being returned.

Interpreter->compiled code and Compiled code->compiled code returns
ignore the first returned value (the instance/klass pointer) and use the
fields being returned directly unless the caller doesn't know the exact
klass of the value type being returned (that is at a method handle
linker call). In that case, the compiled code calls the same runtime
call that the interpreter uses to allocate and initialize a new value
type instance.

The webrev also fixes a couple 32 bit x86 build errors.

I noticed the ValueTypeTestBench test would sometimes get confused when
parsing the output of the child JVM if an unexpected method is compiled
(which can happen with method handle utility methods, at least with the
new tests I added). I tried to make the parsing logic more robust. I
also improved handling of AlwaysIncrementalInline by C2 so its behavior
is closer to the non incremental inline case. As a consequence I removed
some of the special case match rules for AlwaysIncrementalInline.

http://cr.openjdk.java.net/~roland/valhalla/returnconvention/webrev.01/

Roland.


More information about the valhalla-dev mailing list