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 IuorioStudent in Computer Science, Università degli Studi di
milanoandreafrancesco.iuo...@outlook.com - GPG Key
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.
