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

Tobias Hartmann tobias.hartmann at oracle.com
Tue May 29 13:01:21 UTC 2018

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

> 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.



More information about the valhalla-dev mailing list