RFR(L): 8206139: [lworld] Re-enable calling convention optimizations

[Tobias Hartmann]

Hi Roland,

thanks a lot for reviewing this large change!

> How does the new entry point interacts with stack banging? Does stack
> banging takes extra space on the stack that may allocated by the new
> entry point into account?

Stack banging code is added by MacroAssembler::verified_entry() -> generate_stack_overflow_check()
which is emitted both for the new entry point as well as the normal entry point. However, we might
want to emit this check before we do the unpacking and take the extra space into account. I'll file
a follow up task to investigate this.

> In sharedRuntime_x86_64.cpp:
> 
> 4388       // We don't need barriers because the destination is a newly allocated object.
> 
> That seems like a risky assumption. We're likely to need load barriers
> with concurrent collector too.

Right, I'll file a follow-up bug to take care of this as well (it's not trivial because
store_heap_oop() kills r8, a bug that existed already in MVT).

> Would it be possible to save restore sp in the caller around the call to
> the new entry point, then the new entry point would extend the caller's
> stack but the compiled code would otherwise use a known constant frame
> size? How much harder would it be to support stack walking?

The new entry point is (currently) only used for calls through the method handle linkTo adapters and
in this case the caller does not know it is calling a method with scalarized value type args. Do you
mean _always_ saving/restoring the sp in the caller? This would penalize all interface calls once we
scalarize value type receivers as well.

I need to think about this more but I don't think it would be simpler.

> In any case, this is good to push.

Thanks I'll push. We can always improve/fix the implementation.

Best regards,
Tobias