RFR(S): 8207773: [lworld] C2 should not allocate when returning a value type as Object from an inlined method

[John Rose]

On Jul 18, 2018, at 11:23 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
> 
> Hi John,
> 
> thanks for looking at this.
> 
> On 18.07.2018 22:08, John Rose wrote:
>> That looks good, but the pre-existing assert may be overly restrictive:
>> 
>>       assert(tr->isa_instptr()->klass()->is_java_lang_Object(), "must be java.lang.Object");
> 
> I think the assert is fine because the interface case is handled just above in line 2365. We could
> handle value type to interface type returns here as well though. I've seen that you've filed
> JDK-8207811, we can do some code cleanups in that context.

In the context of JDK-8207811 I'd suggest adding a comment saying
something like "interfaces are handled above".  The theory I'm proposing
is that a bare test for Object (without interfaces also) needs an excuse.
…But it's mainly a suggestion for avoiding future bugs, of a kind I've
seen several times in the (long-gone) past.

> 
>> The JVM treats all interfaces as untyped pointers, as well as Object.
>> The verifier allows pervasive unchecked conversions between any interface
>> and Object.  See VerificationType::resolve_and_check_assignability
>> and note that from_field_is_protected is false almost always.
>> 
>> This odd status of interfaces has often been forgotten in JIT code.
>> Any C2 TypeInstPtr whose klass is an interface is a general reference,
>> a value of which may or may not implement the interface in question.
>> In other words, anywhere an Object is allows, an interface is probably
>> also valid.
> 
> Yes, we've introduced TypeOopPtr::can_be_value_type() for this:
> http://hg.openjdk.java.net/valhalla/valhalla/file/d44793ca7966/src/hotspot/share/opto/type.hpp#l1090

OK.  The name reads oddly; Object itself isn't (and so can't) be a value
type, but can be a super of value types, and its domain is able to contain
value instances; same point for any interface.  I won't bikeshed here.

> 
>> I wonder, do we have to do a round of assert adjustment the first time we
>> mix values with interfaces?  And one of the advantages of L-world is simple
>> interop between interfaces and values:  Are we giving up on this in LW1?
> 
> No, this *is* supported for LW1 and we have the corresponding JIT functionality and tests (basically
> whenever we have tests with java.lang.Object, we (should) have added tests with "MyInterface" which
> is implemented by our test value types). For example:
> http://hg.openjdk.java.net/valhalla/valhalla/file/d44793ca7966/test/hotspot/jtreg/compiler/valhalla/valuetypes/TestLWorld.java#l741

Oh, good.  I was slightly worried, along the lines of "how can that
possibly work?"

— John