[lworld] Move null check from method entry into i2c adapter

[Tobias Hartmann]

Hi Roland,

I've updated the webrev and added a check for value type arguments that are constant null:
http://cr.openjdk.java.net/~thartmann/valhalla/lworld/adapter_null_check/

I've also updated the test to trigger the problem.

Thanks,
Tobias

On 29.05.2018 15:01, Tobias Hartmann wrote:
> Hi Roland,
> 
> thanks for looking at this!
> 
> On 29.05.2018 11:55, Roland Westrelin wrote:
>>
>>> http://cr.openjdk.java.net/~thartmann/valhalla/lworld/adapter_null_check/
>>
>> That was fast!
>>
>> How is the change in sharedRuntime.cpp related to the null check change?
> 
> In lworld, we don't use Q in the signature anymore but need to check the actual type to see if it's
> a value type. As a result, the code that created the "extended signature" for the calling convention
> is broken because ss.type() == T_VALUETYPE will always return false. The value types attribute [1]
> ensures that value type classes are loaded eagerly and we can rely on that when creating the
> adapters. There's some other dead code that we should fix once we re-enable the calling convention
> optimization.
> 
>> We could still have a null literal in the code so checks for non null
>> arguments and an unconditional deoptimization is required.
> 
> Yes, my bad. In the meantime I've also hit this problem with a slight modification to our tests.
> Will send a fixed webrev tomorrow.
> 
>> Another related change to move null checks out of the common path would
>> be to null check return values in the callee rather than the caller and
>> then deoptimize the caller if it is compiled. That would require a
>> runtime check in the interpreter but in new code we would statically
>> know that a value being returned is not null and so would have no check
>> (unless the value returned is a null literal).
> 
> Yes, I think we've discussed this before. It's already on my todo list.
> 
> Thanks,
> Tobias
> 
> http://hg.openjdk.java.net/valhalla/valhalla/rev/951b87a3f2c2
>