hotspot-compiler-dev Digest, Vol 145, Issue 95

[Alfonso² Peterssen]

We considered adding interfaces to the compiler type system ("stamps") 
in Graal as well, but we dropped the effort since there was no real 
performance benefit (see below) to justify the compiler performance hit.
Measuring the impact of such a change is hard, we opted to measure how 
often the "stamps" with interfaces produced a better, more precise type. 
Note that this number is an upper-bound, that does't not necessarily 
translates to performance gains, most of the time this "improved" type 
is discarded or not used at all.

In our tests we saw a mere 1% improvement for Java (dacapo), which means 
that with the interfaces we had a "better" type just 1% of the time.

For Scala (scala-dacapo) the impact was slightly higher, just below 3% 
since traits are encoded using interfaces. Scala is in general 
interface-heavy; any effect would be more visible in Scala workloads.

We also tried several representations: flat sets (the representation you 
are using) and cannonical sets (minimal set of disjoint interface roots) 
which are more compact but union/intersection operations are more 
expensive complexity-wise.
The measurements revelead that the cannonical sets were more compact 
than the flat sets in the wild, while the cost of union/intersection 
operations was comparable (e.g. the cannonical sets operations were more 
expensive but they where always very small).

Another issue with having interfaces is that it can easily explode on 
pathological cases; for such cases we also considered bounded sets 
(dropping interfaces) but again saw no improvement and had issues 
because we couldn't trust the "stamp" anymore (since some interfaces 
could be missing).
The last option we considered was bounded union types, think 1 | 12 
instead of 1..12; we tried for types and for ints, but again, saw little 
improvements that didn't justify the complexity and the compiler perf hit.

We have different implementations, so your approach may still be worth 
it performance wise (please do try some Scala workloads). Finally... 
it's very hard to change the "stamps" in Graal without breaking things, 
but it seems you succeeded which may indicate that your "stamps" are not 
abused as much all over the codebase as the Graal ones.

Best,

Alfonso2


On 6/27/19 2:00 PM, hotspot-compiler-dev-request at openjdk.java.net wrote:
> Send hotspot-compiler-dev mailing list submissions to
> 	hotspot-compiler-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mail.openjdk.java.net/mailman/listinfo/hotspot-compiler-dev
> or, via email, send a message with subject or body 'help' to
> 	hotspot-compiler-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
> 	hotspot-compiler-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hotspot-compiler-dev digest..."
>
>
> Today's Topics:
>
>     1. Re: RFR(XL): 6312651: Compiler should only use verified
>        interface types for optimization (Roland Westrelin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 27 Jun 2019 13:17:41 +0200
> From: Roland Westrelin <rwestrel at redhat.com>
> To: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>,
> 	hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(XL): 6312651: Compiler should only use verified
> 	interface types for optimization
> Message-ID: <87a7e3b7l6.fsf at redhat.com>
> Content-Type: text/plain
>
>
>> Do you see any value in representing subtype checks as macro nodes once
>> C2 type system handles interfaces better?
> I noticed that sometimes (profile) predication moves the second test in
> the general subtype check out of loop but not the first one (because its
> input is not loop invariant). Because that second test is really
> designed to be executed only after the first one fails, it can fail for
> a valid subtype check when it's a predicate causing (profile)
> predication to be disabled on next compilation. A macro node would solve
> that problem. Beyond that, turning subtype checks into a macro nodes
> sound like a reasonable move.
>
> Roland.
>
>
> End of hotspot-compiler-dev Digest, Vol 145, Issue 95
> *****************************************************