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
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
additional libs). The IR also changed a lot since then. I would recommend
emitting Dalvik IR directly.
Post by Andrea Francesco IuorioI 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
------------------------------
Date: Wed, 12 Feb 2014 23:29:21 -0600
Subject: Re: [jruby-dev] GSoC 2014
Hi Andrea,
A quick overview of the Intermediate Representation for JRuby before
talking about possible projects.
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).
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.