Hi Andrea, A quick overview of the Intermediate Representation for JRuby before talking about possible projects.
This IR has been designed with the following goals in mind: 1. Capture Ruby semantics as accurately as possible without losing information. 2. Expose primitive operations (ex: a constant lookup involves search-of-lexical-scope + search-of-class-inheritancy-hierarchy). 3. Be suitable for interpretation and replace the current AST-based interpreter. 4. Perform optimizations that the JVM itself will not be able to do directly (ex: lowering Ruby Floats to Java primitive floats, inline blocks alongwith caller) 5. Generate readable serialized output (kind of like Ruby assembly) that could be useful outside JRuby itself (something that we've been talking more recently). 6. Ability to do safe offline optimizations and persist IR that can be directly interpreted or JIT-ted without going through ruby source. 7. Be JITtable to other targets besides JVM bytecode: Dalvik for Rubuto and more recently, Chris brought up the idea of possibly targeting Graal directly without going through Truffle. In this IR-based approach, all analyses and optimizations are done at the level of individual scopes (mostly methods and blocks), and the goal is not to do all the standard compiler optimizations but only those that will reduce the semantic gap between Ruby and Java and make the generated code look as much Java-like as possible so that the JVM (or other targets) can then take it the rest of the way. We are doing fairly well with goals 1. and 2. and are still continuing to tweak our IR. We are trying to capture more of the JRuby runtime work into IR primitives which can then be exposed for additional analysis and optimizations either as part of 4. or something that the JVM itself can do. Given that background, here are some possible specific project ideas depending on what area you want to focus on. Some of these are more experimental / open-ended and others are more concrete without any surprises. Ideas 2, 4, 7 below are fairly well-defined. Ideas 3, 5 are somewhat well-defined, but have some open-ended unresolved bits. We have talked about idea 6 in various forms over time but never sat down to work through details, but might not be too hard. Idea 1 may not fit in well with the timeline, but Tom may have some sub-projects here. These are just some initial project ideas as I tried to collate some of the many things we've talked about over the last couple years. 1. Interpreter: Over the last 6 months, we've improved the performance of the IR-based interpreter quite a bit, but it still lags the performance of the AST-based interpreter (because there is a lot more state twiddling happening with temporary variables and the like). Understanding this better and plugging the holes would be one project. But, this is fairly open-ended and this may not necessarily fit in with the GSoC timeline since we want to get most of the gap narrowed in the next 3-4 months. 2. Compile IR to Dalvik: Right now, a JIT is in progress to compile the IR to JDK 7. Testing this on Dalvik and compiling to it is an obvious self-contained project. Lower priority (compared to Dalvik) is to compile to other targets like Graal IR. 3. Profiling: JIT-ting and optimizations only make sense on hot code, and some require additional information to be gathered (types). Designing profiles and collecting them with low-overhead is the goal of this project. In addition, some applications mutate code heavily (especially Rails). If aggressive optimizations are done too early, they can be wasteful as classes mutate. Profiling can also help with this by monitoring code mutations, rate of change of code mutations, and use some metrics to figure out when it is safe to do additional optimizations. 4. Method and closure inlining: Some basic code for inlining methods and closures already exists in JRuby. But, this is just the inlining transformation. There is no strategy yet as to when to inline, what to inline, how much to inline, etc. This is somewhat tied to profiling (4. above). 5. Exposing JRuby-native implementations of core classes for optimization: For example, attr_reader, attr_writer, attr_accessor methods are implemented as native Java classes. By exposing them as Ruby or IR methods, JRuby can then potentially them inline them (and expose them as native java object field load/stores). Similarly, with looping, iterator, enumeration methods implemented as Java code. 6. Optimizing placement of guards. JRuby opts that reduce the semantic gap between Ruby and Java and make Ruby look Java-like (which the JVM can opt fairly well) will involve speculative optimizations (unboxing Ruby objects to Java primitives, inlining of closures) based on assumptions about types and unmutability of classes. JRuby will have to insert guards in the code to protect against violations. Inserting these guards willy-nilly everywhere is not the best way to handle this. Coarsening guards (on method-entry) and combining guards (2 methods from same class get inlined) and exploring other techniques would be the goal of this project. 7. SSA: So far, I have not implemented SSA since I figured it was not important to do all the standard compiler opts. on the IR since the JVM (or whatever target) will do a fairly good job of it as long as there isn't anything that gets in the way (ex: objects instead of floats or fixnums, calls to closures instead of method calls). But a SSA form could potentially simplify some analyses currently implemented or might be implemented later. So, in this project, you will build an SSA form and and port some of our analyses to work on that. Subbu. On Wed, Feb 12, 2014 at 2:59 PM, Charles Oliver Nutter <head...@headius.com>wrote: > It's largely up to you which of the two projects sounds more > interesting, but Chris (already replied) or Subbu (probably will reply > soon) are your contacts for Truffle and IR, respectively. I would say > that from a compiler perspective, IR probably has more work and > subprojects for you to help with, but Truffle is a very different and > interesting approach to language optimization too. > > I'm also happy to answer questions here, on IRC, on Twitter (headius), > or via IM (head...@headius.com on google talk). > > - Charlie > > On Wed, Feb 12, 2014 at 4:56 AM, Andrea Francesco Iuorio > <andreafrancesco.iuo...@outlook.com> wrote: > > Good morning, i' m a student in Computer Science and i could be > interested > > in one of your projects for the Google Summer of Code. I have some > > experience with compilers and virtual machines since my thesis project > > involved the creation of a compiler for the JVM and i want to improve my > > skills partecipating with the Truffle project or the IR project. How can > i > > contact these projects' mentors for more details ? > > > > Andrea Francesco Iuorio > > Student in Computer Science, Università degli Studi di Milano > > andreafrancesco.iuo...@outlook.com - GPG Key > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
