JRuby

Dependency to compiler package from org.jruby.Ruby breaks Ruboto

Details

  • Number of attachments :
    0

Description

When packaging Ruboto, we remove the compiler packages since JIT compilation is not available on Dalvik, and we need to save space. The newly introduced dependency from org.jruby.Ruby to org.jruby.compiler.ir.IRManager breaks this. Is there a way to avoid this dependency?

    [echo] java.lang.NoClassDefFoundError: org.jruby.compiler.ir.IRManager
     [echo] 	at org.jruby.Ruby.init(Ruby.java:1117)
     [echo] 	at org.jruby.Ruby.newInstance(Ruby.java:249)
     [echo] 	at org.jruby.embed.internal.SingletonLocalContextProvider.getRuntime(SingletonLocalContextProvider.java:95)
     [echo] 	at org.jruby.embed.ScriptingContainer.put(ScriptingContainer.java:1126)
     [echo] 	at java.lang.reflect.Method.invokeNative(Native Method)
     [echo] 	at org.ruboto.Script.put(Script.java:267)
     [echo] 	at org.ruboto.Script.scriptsDirName(Script.java:393)
     [echo] 	at org.ruboto.Script.setUpJRuby(Script.java:177)
     [echo] 	at org.ruboto.Script.setUpJRuby(Script.java:73)
     [echo] 	at org.ruboto.test.InstrumentationTestRunner.getAllTests(InstrumentationTestRunner.java:37)
     [echo] 	at android.test.InstrumentationTestRunner.getTestSuite(InstrumentationTestRunner.java:555)
     [echo] 	at android.test.InstrumentationTestRunner.onCreate(InstrumentationTestRunner.java:354)
     [echo] 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3246)
     [echo] 	at android.app.ActivityThread.access$2200(ActivityThread.java:117)
     [echo] 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:969)
     [echo] 	at android.os.Handler.dispatchMessage(Handler.java:99)
     [echo] 	at android.os.Looper.loop(Looper.java:123)
     [echo] 	at android.app.ActivityThread.main(ActivityThread.java:3683)
     [echo] 	at java.lang.reflect.Method.invokeNative(Native Method)
     [echo] 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
     [echo] 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
     [echo] 	at dalvik.system.NativeStart.main(Native Method)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Thomas E Enebo added a comment -

IR subsystem will be used for new interpreter and for new JIT compiler, so IRManager will end up replacing our current interpreter.

Show
Thomas E Enebo added a comment - IR subsystem will be used for new interpreter and for new JIT compiler, so IRManager will end up replacing our current interpreter.
Hide
Permalink
Thomas E Enebo added a comment -

Err IR will...IRManager is just one class.

Show
Thomas E Enebo added a comment - Err IR will...IRManager is just one class.
Hide
Permalink
Uwe Kubosch added a comment -

So IRManager will be placed in a package outside org.jruby.compiler ?

Or we should keep org.jruby.compiler.ir in Ruboto since it will contain the interpreter?

Show
Uwe Kubosch added a comment - So IRManager will be placed in a package outside org.jruby.compiler ? Or we should keep org.jruby.compiler.ir in Ruboto since it will contain the interpreter?
Hide
Permalink
Thomas E Enebo added a comment -

yeah we will move org.jruby.compiler.ir -> org.jruby.ir.

Show
Thomas E Enebo added a comment - yeah we will move org.jruby.compiler.ir -> org.jruby.ir.
Hide
Permalink
Charles Oliver Nutter added a comment -

Part of Uwe's concern is size; IR is not used by default right now, and he's trying to get the JRuby runtime as small as possible. Since we'll never be able to eliminate the AST completely, it seems logical that there might always be an AST-based interpretation path, right? Modifying our calls to IRManager to be more isolated (probably via reflection) would allow stripping JRuby down to just the parser + AST for execution.

Show
Charles Oliver Nutter added a comment - Part of Uwe's concern is size; IR is not used by default right now, and he's trying to get the JRuby runtime as small as possible. Since we'll never be able to eliminate the AST completely, it seems logical that there might always be an AST-based interpretation path, right? Modifying our calls to IRManager to be more isolated (probably via reflection) would allow stripping JRuby down to just the parser + AST for execution.
Hide
Permalink
Thomas E Enebo added a comment -

Actually, I am not sure there will always be an AST interp path. It is my hope IR will completely replace AST for interp (which means removing all the interp methods...which might make the change a smaller delta).

The big win for IR on Android is the new interpreter can do lots of optimizations like method inlining which should be a perf win on Android. Code size is a concern of course.

IRManager can be made reflective for now as well since it is not the default (and certainly won't be for 1.7.x). We need to figure out better ways of stripping unneeded pieces as part of our modularization strategy. So just doing it as a way of playing with the concept of stripping out classes would be useful.

Show
Thomas E Enebo added a comment - Actually, I am not sure there will always be an AST interp path. It is my hope IR will completely replace AST for interp (which means removing all the interp methods...which might make the change a smaller delta). The big win for IR on Android is the new interpreter can do lots of optimizations like method inlining which should be a perf win on Android. Code size is a concern of course. IRManager can be made reflective for now as well since it is not the default (and certainly won't be for 1.7.x). We need to figure out better ways of stripping unneeded pieces as part of our modularization strategy. So just doing it as a way of playing with the concept of stripping out classes would be useful.
Hide
Permalink
Charles Oliver Nutter added a comment -

That sounds fair. I'll make a change to reflectively access IR from outside the package, for now, and we'll remove that in the future when IR takes over.

Show
Charles Oliver Nutter added a comment - That sounds fair. I'll make a change to reflectively access IR from outside the package, for now, and we'll remove that in the future when IR takes over.
Hide
Permalink
Charles Oliver Nutter added a comment -

After looking this over a bit, I'm not sure it will be easy or valuable enough to make the ir package removable.

I was able to make a simple change to let JRuby boot without the IR package present, by lazily allocating IRManager. Having done that, I removed everything under org.jruby.compiler.ir, annd the jruby.jar file only shrank by about 360k, from 10174515 to 9813649. That's nontrivial, but it's not a huge reduction either.

Unfortunately, making it so that the dx tool would not want to compile IR stuff is more complicated. IRStaticScope is referenced in several places, and it references topmost classes in the IR package. We could go through the effort of creating some utilities that could either produce normal runtime structures or IR runtime structures, but it's a bit of work.

Also, once the dx tool is finished compiling JRuby, it's likely to be less than 360k size reduction. If we use pack200 as an example, the normal jruby.jar compresses to 2268272, and the version without IR compresses to 2196262, a whopping 72k reduction.

I think a better direction would be for us to strip out libraries like unused YAML backend, JNR packages we don't need, ASM, and any Ruby extensions we don't need.

Show
Charles Oliver Nutter added a comment - After looking this over a bit, I'm not sure it will be easy or valuable enough to make the ir package removable. I was able to make a simple change to let JRuby boot without the IR package present, by lazily allocating IRManager. Having done that, I removed everything under org.jruby.compiler.ir, annd the jruby.jar file only shrank by about 360k, from 10174515 to 9813649. That's nontrivial, but it's not a huge reduction either. Unfortunately, making it so that the dx tool would not want to compile IR stuff is more complicated. IRStaticScope is referenced in several places, and it references topmost classes in the IR package. We could go through the effort of creating some utilities that could either produce normal runtime structures or IR runtime structures, but it's a bit of work. Also, once the dx tool is finished compiling JRuby, it's likely to be less than 360k size reduction. If we use pack200 as an example, the normal jruby.jar compresses to 2268272, and the version without IR compresses to 2196262, a whopping 72k reduction. I think a better direction would be for us to strip out libraries like unused YAML backend, JNR packages we don't need, ASM, and any Ruby extensions we don't need.
Hide
Permalink
Uwe Kubosch added a comment -

Sounds fair. Also, Enebo's comment about IR being beneficial to Ruboto means we will want to keep it. I'll close this issue now.

Show
Uwe Kubosch added a comment - Sounds fair. Also, Enebo's comment about IR being beneficial to Ruboto means we will want to keep it. I'll close this issue now.

People

  • Assignee:
    Unassigned
    Reporter:
    Uwe Kubosch
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: