When JRuby is accepted as a GSoC organization, you will be able to see us there with a template. In general, we just want to see a clear path through the summer, with periodic milestones, schedule, midterm and end goals, and overall implementation plan.
IR for Dalvik would be a great project. We had a student attempt it some years ago, but that work never completed and never functioned. It focused on emitting JVM bytecode which then translated to Dalvik IR on device...which ended up not being very effective (slow, required large additional libs). The IR also changed a lot since then. I would recommend emitting Dalvik IR directly. Looking forward to having you on the team! - Charlie (mobile) On Feb 14, 2014 12:10 PM, "Andrea Francesco Iuorio" < andreafrancesco.iuo...@outlook.com> wrote: > I took a quick look on your repository for understaing how IR generate > bytecode. In practice, you created an object that rappresent the JVM and, > using ASM, you implemented every single IR instruction with some other > implementation details: the compiler, calling the function rappresenting > that instruction, create the real bytecode. So, for a dalvik implementation > one should create this object and implements every IR instruction using dex > bytecode. > > I think i' ll try to apply for the ir-dalvik project. I worked on a > compiler for the jvm so i' m not completely new to this kind of project. > Just one last question: do you have some template for the proposal or i can > write it as i see fit ? > > *Andrea Francesco Iuorio* > Student in Computer Science, Università degli Studi di Milano > andreafrancesco.iuo...@outlook.com - GPG > Key<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB7CE867432B28197> > > > ------------------------------ > Date: Wed, 12 Feb 2014 23:29:21 -0600 > From: sss.li...@gmail.com > To: dev@jruby.codehaus.org > Subject: Re: [jruby-dev] GSoC 2014 > > 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. > >
