RFR(S) JDK-8206140 [lworld] Move return value null checks into the callee

[Tobias Hartmann]

Hi Ioi,

On 25.07.2018 16:22, Ioi Lam wrote:
> I modified the patch so that the compiled code matches what the interpreter does: we assumed the
> returned oop will not be NULL only if Method::is_returning_vt() is true.
> 
> http://cr.openjdk.java.net/~iklam/valhalla/8206140_lworld_null_check_in_callee.v05/

That makes sense to me. Like this, we will add a null check at the call site if there's an
inconsistency in the expected return type between caller and callee.

Maybe adjust the comment in type.cpp a bit, explaining why the basic return type can be T_VALUETYPE
but is_returning_vt() can be false (i.e., that there can be inconsistencies).

> With this change, I think it's no longer to fix JDK-8207219 (as it would enforce a behavior that's
> more strict than what we actually need). What do you think?

Yes, I think that 8207219 can be closed as "Not an issue".

> I'll also update the test cases for this bug and post a new webrev later today.

Yes, please add the test from 8207219.

I'll have another look tomorrow (with a "fresh" brain) and then sponsor the change.

Thanks,
Tobias