Poor performance with invokedynamic on Graal

[Charles Oliver Nutter]

On Mon, Aug 8, 2016 at 10:49 AM, Thomas Wuerthinger <
thomas.wuerthinger at oracle.com> wrote:

> Thanks for the regression report. Our policy with Graal is to not accept
> any significant peak slow-down on realistic workloads compared to C2. We
> will create a ticket to track progress. Can you also specify the version of
> the JDK used with Graal (i.e., the full “-version” output of the JVM)?
>

Here's the full -version:

java version "1.8.0_92"

Java(TM) SE Runtime Environment (build 1.8.0_92-b14)

OpenJDK 64-Bit Server VM (build 25.71-b01-internal-jvmci-0.19-dev, mixed
mode)

> We did not (wittingly) change the behavior of Graal related to
> invokedynamic. Maybe some VM internals have changed that we did not yet
> adopt for.
>

At the moment I'm digging into PEA to see why it's not doing anything for a
simple Ruby loop. Everything inlines, but boxes are apparently still being
created. PEA finishes without making any changes.


> Obviously, we recommend on the long run to use Truffle+JRuby. We see
> fairly convincing numbers with Truffle enabled for the mentioned red-black
> tree benchmark on our performance tracking infrastructure.
>

Yes, I'm sure you do :-) However I'm interested in getting current JRuby
users better performance...I'm interested in near-term production Ruby use
cases.

I also believe that with better object shaping and a bit of method
specialization (both works-in-progress) in JRuby's IR, we can be
competitive with JRuby+Truffle on any compiler that provides partial escape
analysis.

- Charlie