Poor performance with invokedynamic on Graal
Charles Oliver Nutter
headius at headius.com
Mon Aug 8 17:53:00 UTC 2016
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
More information about the graal-dev
mailing list