harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Naveen Neelakantam <neela...@uiuc.edu>
Subject Re: [drlvm][jit] replay compilation methodology
Date Thu, 24 Apr 2008 16:54:05 GMT

On Apr 24, 2008, at 3:18 AM, Egor Pasko wrote:

> On the 0x42F day of Apache Harmony Naveen Neelakantam wrote:
> > Hello all,
> Hello, Naveen, nice to see you again!

Thank you Egor.  BTW, I glanced at some of the refactoring/ 
improvements you made to ABCD.  Looks like very nice work!

> > 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

Sorry, I was referring the the description of "deterministic  
methodology" in Section 5.  For convenience I'll summarize the idea  

The problem is that a staged optimizing-compiler (e.g. server.emconf)  
can make it difficult to isolate the performance effects of a  
particular compiler optimization or GC algorithm because the compiler  
runs concurrently with the application/GC.

A reasonable solution to this problem is the following:
1) Run the application with the staged compiler enabled and collect a  
log of its actions.
2) When measuring performance, run the application twice in a row,  
within the same JVM instance.  During the first run the JVM consumes  
the log produced in (1) and uses it to optimize the code exactly the  
same as in (1).  During the second run the compiler is disabled and  
measurements are made.

> > 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  
> > when running in replay mode.
> hm, this approach looks like aims at determinism. Does it require
> thread manager logging/replay? I hope not.

Yep, I am trying to get closer to determinism.  True determinism  
isn't necessary for my work, so thankfully I don't need to make sure  
threads are created/executed in a deterministic order.

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

I'm not sure what you mean by "intrusive" or the "normal logging".   
Do you mean the "ct" and "irdump" logs?  If so, I agree that would be  
far too heavyweight in my opinion.

I think the minimal amount of information necessary to reproduce the  
optimizing compilers actions should be collected.  Logging the edge  
and value profiles seem like a reasonable starting point.

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

Yep, the devil is always in the detals...  :-)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message