You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Naveen Neelakantam <ne...@uiuc.edu> on 2008/04/23 01:49:48 UTC

[drlvm][jit] replay compilation methodology

Hello all,

For my own research purposes I'm starting to implement support in  
DRLVM for what the JikesRVM folks call "replay compilation  
methodology" (see: http://jikesrvm.org/Experimental+Guidelines and  
Section 5 of http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/oor-oopsla-2004.pdf) 
.

I've thought a bit about it and I know I would need at least the  
following:
1) Mechanism for logging edge profiles (I actually already have a  
quick and dirty way of doing this).
2) Mechanism for logging call profiles.
3) Mechanism for reading in both profiles and feeding them to the JIT  
when running in replay mode.

I also suspect I need to keep track of which classes have been loaded  
and when.  Basically my thinking here is that the "replay" compiler  
may want to inline a method that hasn't even been loaded yet so I'd  
need to postpone compilation in such a case.

Right now I'm using a relatively old (ancient?) version of the DRLVM  
tree (r510344), but would consider updating to a newer tree if there  
is sufficient interest.  Is this something that others would want  
contributed back to Harmony?

Thanks,
Naveen

Re: [drlvm][jit] replay compilation methodology

Posted by Egor Pasko <eg...@gmail.com>.
On the 0x42F day of Apache Harmony Naveen Neelakantam wrote:
> Hello all,

Hello, Naveen, nice to see you again!

> For my own research purposes I'm starting to implement support in
> DRLVM for what the JikesRVM folks call "replay compilation
> methodology" (see: http://jikesrvm.org/Experimental+Guidelines and
> Section 5 of
> http://cs.anu.edu.au/~Steve.Blackburn/pubs/papers/oor-oopsla-2004.pdf)
> .

at the first glance I did not find anything useful in the Section 5


> I've thought a bit about it and I know I would need at least the
> following:
> 1) Mechanism for logging edge profiles (I actually already have a
> quick and dirty way of doing this).
> 2) Mechanism for logging call profiles.
> 3) Mechanism for reading in both profiles and feeding them to the JIT
> when running in replay mode.

hm, this approach looks like aims at determinism. Does it require
thread manager logging/replay? I hope not.

Logging should probably be not the normal logging, but something least
intruisive possible, right?

for me it seems like a useful feature, probably can grow into
something bigger.. but need to discuss a lot of details, of course

> I also suspect I need to keep track of which classes have been loaded
> and when.  Basically my thinking here is that the "replay" compiler
> may want to inline a method that hasn't even been loaded yet so I'd
> need to postpone compilation in such a case.
> 
> Right now I'm using a relatively old (ancient?) version of the DRLVM
> tree (r510344), but would consider updating to a newer tree if there
> is sufficient interest.  Is this something that others would want
> contributed back to Harmony?

-- 
Egor Pasko