Re: [rvm-research] GSoC 2013 Call for Jikes RVM project proposals

On 3/20/2013 5:48 PM, Erik Brangs wrote:
> Hi,
>
> On 20.03.2013 18:30, Eliot Moss wrote:
>> I wonder whether we should pick up the thread on any of these
>> ideas:
>>
>> - A better register allocator (got bogged down in complex
>>     particulars, particularly for x86)
>
> Which approach do you envision for this project? Should the register
> allocator be replaced at one go or is the plan to refactor the subsystem
> to make the register allocator pluggable and switch at some later point?

Well, we worked some on one that was based on a journal paper that
allowed the "home" of a variable to shift from one register to another
in different regions -- basically breaking live ranges into smaller
units.  But the conceptually simple algorithm of the paper was totally
undermined by all the constraints on a platform like the x86.

So we would need first of all to determine a good algorithmic approach
that could be tailored to a range of machines.  Ideally I would like
something that works from a "machine description" and is thus easy to
retarget.  This would need a fairly capable person.  It might not be
the best for a GSoC project.

>> - A Quick Compiler that does simple optimization and some use
>>     of registers, possibly modeled after existing dynamic code
>>     generation systems such as that of QEMU
>
> Is this intended as a replacement of or a supplement to the baseline
> compilers?

Prior work suggested that it makes sense as a replacement since
the cost may be something like 4x the baseline compiler but the
speed of the resulting code is something like 10x.  It could also
be used only for methods run more than a few times.  (Clearly a
run-once method, such as a static initializer, is not worthy of
optimization effort unless it has a heavy loop or something.)

It remains useful to have the baseline compiler as a fall back
in case another compiler gives up.  However, in the long run one
would not want to maintain *three* compilers when two will do.

>> - Opt compiler for 64-bit x86
>>
>
> x64 support would certainly be a great addition if we can find a student
> with suitable skills. IMHO such a project should have a strong focus on
> regularly merging code to mainline. If that does not happen, we'll end
> up in the same situation that we're in right now: we have contributions
> for x64 support (e.g. DaFeng's patch set for RVM-977 and potentially
> additional code in MRP) but we're too short on time to merge it.

I am not sure exactly what you're referring to (a patch set number does
not connote as I write), but this is mostly about getting the opt compiler
rules (and support) written.  I was assuming an otherwise-working 64-bit
environment.

>> - Any steps that might bring us closer to easier / automated
>>     porting
>
> IMHO more tests are always helpful but I assume you had something
> different in mind. Could you please elaborate?

What I mean is component generation from machine descriptions.

>> - Java 7
>> - Java 8
>
> Adding support for later Java versions would definitively be useful.
> IMHO such projects should have a strong focus on testing. Our compliance
> with the JVM spec is bad enough as it is and we'll likely never get
> access to the JCK.

Indeed.

> Erik Brangs

Thanks for your comments ... Eliot

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar