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

[Ioi Lam]

https://bugs.openjdk.java.net/browse/JDK-8206140
http://cr.openjdk.java.net/~iklam/valhalla/8206140_lworld_null_check_in_callee.v02/

First of all, thank you Tobias for helping me get started with Valhalla 
and the compiler,
both of which I am still mostly clueless ...


When a callee method has a VT return type, the method may return a null 
value. The null
check used to be done inside the compiled code of the method's caller.

With this fix, the null check is now done by the callee, inside the 
areturn bytecode
handler in the interpreter. When areturn sees a null value, it calls 
into the VM to
deoptimize the caller, so the caller will continue running in 
interpreter mode and handle
the NULL value appropriately.

To improve interpreter speed (so we won't excessively trap into the VM 
whenever a
null is returned -- this is especially important for methods that are 
NOT returning
a VT), I added 2 bits in Method::_flags. These allow the interpreter to 
quickly
check if the areturn is working on a method that returns a VT.

The flags handling is complicated by the fact that "legacy" classes may 
return a VT
(see [1]). Please see my comments around Method::check_returning_vt. I 
added a new
test case for this -- see TestLWorld::test78). Anyway, I am not happy 
with this check,
so if you can think of a better way, please let me know.

Thanks
- Ioi


[1] 
http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-July/004567.html