JRuby

Compiler emits exception-handling sections of code that can be reached through non-exceptional paths.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: JRuby 1.1RC2
  • Fix Version/s: JRuby 1.1.2
  • Component/s: Compiler
  • Labels:
    None
  • Environment:
    Windows 2003, x64
  • Number of attachments :
    1

Description

JRuby underperformed Ruby for a mathematical oriented algorithm. The script is attached to the bug.

This was running using IBM's J9 JVM:
$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32devifx-20070531a (SR4 + IY99287 + IY99356 + IY98136))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows Server 2003 x86-32 j9vmwi3223ifx-20070525 (JIT enabled)
J9VM - 20070524_12771_lHdSMR
JIT - 20070109_1805ifx1_r8
GC - WASIFIX_2007)
JCL - 20070131

Running the same test with the 64-bit HotSpot JVMs showed JRuby was faster than Ruby.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

This is likely due to an issue in the compiler that also causes the HotSpot C1 compiler to avoid compilation. The issue is that most of our compiled exception handling allows normal execution to fall through into exception-handling blocks. This case is not ever emitted by javac, and as such almost all JITs avoid compiling it in bytecode, leaving the code to interpret.

It is unknown whether this affects the HotSpot C2, compiler, but this is a critical performance issue for 1.1.2 since there are now two different JVM versions that we know downgrade optimization for these cases.

Show
Charles Oliver Nutter added a comment - This is likely due to an issue in the compiler that also causes the HotSpot C1 compiler to avoid compilation. The issue is that most of our compiled exception handling allows normal execution to fall through into exception-handling blocks. This case is not ever emitted by javac, and as such almost all JITs avoid compiling it in bytecode, leaving the code to interpret. It is unknown whether this affects the HotSpot C2, compiler, but this is a critical performance issue for 1.1.2 since there are now two different JVM versions that we know downgrade optimization for these cases.
Hide
Permalink
Charles Oliver Nutter added a comment -

Updating bug title to reflect the actual problem.

Show
Charles Oliver Nutter added a comment - Updating bug title to reflect the actual problem.
Hide
Permalink
Charles Oliver Nutter added a comment -

I don't have a good way to test performance on J9, but the same issue was causing a crash on some versions of HotSpot and now no longer is. So I'm optimistically marking this resolved...if there are still performance issues, and you can confirm they're the same problem, reopen. Otherwise report new issues.

Show
Charles Oliver Nutter added a comment - I don't have a good way to test performance on J9, but the same issue was causing a crash on some versions of HotSpot and now no longer is. So I'm optimistically marking this resolved...if there are still performance issues, and you can confirm they're the same problem, reopen. Otherwise report new issues.
Hide
Permalink
Michael Galpin added a comment -

I confirmed the bug fix on the J9 JVM. JRuby on J9 now handily outperforms CRuby for the algorithm included in the bug. I put some more details on my blog: http://fupeg.blogspot.com/2008/07/jruby-113-performance.html

Show
Michael Galpin added a comment - I confirmed the bug fix on the J9 JVM. JRuby on J9 now handily outperforms CRuby for the algorithm included in the bug. I put some more details on my blog: http://fupeg.blogspot.com/2008/07/jruby-113-performance.html

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.