RFR(S): 8207773: [lworld] C2 should not allocate when returning a value type as Object from an inlined method (original) (raw)
John Rose john.r.rose at oracle.com
Thu Jul 19 07:11:51 UTC 2018
- Previous message (by thread): RFR(S): 8207773: [lworld] C2 should not allocate when returning a value type as Object from an inlined method
- Next message (by thread): RFR(S): 8207773: [lworld] C2 should not allocate when returning a value type as Object from an inlined method
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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->isainstptr()->klass()->isjavalangObject(), "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::resolveandcheckassignability and note that fromfieldisprotected 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::canbevaluetype() 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
- Previous message (by thread): RFR(S): 8207773: [lworld] C2 should not allocate when returning a value type as Object from an inlined method
- Next message (by thread): RFR(S): 8207773: [lworld] C2 should not allocate when returning a value type as Object from an inlined method
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]