-
Notifications
You must be signed in to change notification settings - Fork 89
Ruby Processing Internals and JRuby Tricks
Ruby-Processing uses regular Ruby for generating sketches, and exporting applications and applets, and uses Java via JRuby for running Processing. The main class, Processing::App, inherits from Processing’s PApplet, and has access to all of the PApplet’s methods and fields. When you call methods inside of your sketch, they may end up being called within JRuby-space, or out in Java-space, depending on whether the method is defined in the Processing::App or the processing.core.PApplet. For most methods defined in the Processing API, it entails calling into Java, with JRuby taking care of translating all the arguments and the return value. However, a handful of useful methods (like load_library, render_mode, and many of the math functions) are defined in JRuby.
For a fuller description of JRuby internals, take a look at JRuby Internal Design, but here’s a brief overview:
- JRuby uses a Java port of Ruby’s parser.
- Internally, Java can handle many different JRuby runtimes running in separate threads. All objects have a reference to the runtime that they belong to, and cannot be transported across runtimes without being serialized.
- JRuby threads map directly to Java threads, so you can use the full power of your multi-core or multi-processor machine to drive computationally intensive Ruby-Processing sketches, within a single process.
- Ruby can call methods defined in Java space via bytecode-generated adapter classes that directly invoke the methods. This avoids Java’s reflection capabilities, and provides better performance. There is still significant overhead when calling into Java, however, and as the JRuby team works on reducing this overhead, Ruby-Processing continues to speed up. Core Ruby classes have even further table-based method optimizations.
- JRuby runs with a JIT mode that will compile interpreted calls after 20 runs through the interpreter.