Return value type fields in registers

[Tobias Hartmann]

Hi Roland,

On 28.03.2017 14:25, Roland Westrelin wrote:
> Because the compiled code now returns multiple values, the interpreter
> needs to be able to handle multiple return values. Because the
> interpreter works with value type references, on method return, it has
> to allocate a new value type and initialize it with the field's values
> from the registers of the calling convention. Because the interpreter
> now expects multiple return values from a call, returning from an
> interpreted method also needs to follow the calling convention and
> return a value type instance in registers. Both loading the fields into
> registers from a value type instance on return and allocating a new
> value type instance initialized from the field values in registers is
> performed through runtime calls that read/write register values using a
> RegisterMap.

Very nice! Here are some minor comments/questions:

templateInterpreterGenerator_x86.cpp
- What is 'skip' used for?

deoptimization.cpp
- you can merge the check in line 232 with the check in line 252
- 'return_values' is a bit misleading because it contains Handles for oop fields or the oop return and not all returned values. Maybe rename to 'return_oops' or 'return_handles'.

sharedRuntime.cpp
- line 3176, missing whitespace

I'm currently working on reference field support and it requires some significant changes. How did you check the save_oop_results() code without oop field support? 

> This is not turned on by default for 2 reasons: 1) The interpreter
> reallocates value types in the heap. It would make more sense for the
> interpreter to do it using the new buffer scheme that's being
> developed. 2) If lambda form are involved, exact types for return values
> are lost and this return scheme breaks. It needs lambda form to be
> specialized to each value type types.

I wonder if it would make sense to also pass/return the oop of a value type?

In C2I we would then only need to allocate if the oop is NULL and in IC2 we can pass on the oop of the interpreter-allocated value type.

We could do the same when returning from the interpreter or compiled code.

> This is mostly unrelated but I noticed that calling a method that
> returns a value type through reflection is currently broken (assert
> failure somewhere in the reflection code). I suppose that when
> reflection is fixed, it will box the returned value type so it's not
> affected by that change to the calling convention. I suppose a similar
> problem exists with passing value type arguments through reflection
> though I haven't tried it.

Right, I also recently hit some problems with reflection.

Thanks,
Tobias