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

Tobias Hartmann tobias.hartmann at oracle.com
Thu Jul 19 06:23:10 UTC 2018

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.

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

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


More information about the valhalla-dev mailing list