harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][jit] replay compilation methodology
Date Fri, 25 Apr 2008 13:35:18 GMT
On the 0x430 day of Apache Harmony Naveen Neelakantam wrote:
> 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!

I actually wanted to improve it even more, but all my experiment did
not produce any difference on benchmarks :)

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

then just dump profile at EdgeProfilerAnnotationPass and then reload
in (2). Should solve the problem, IMHO.

> > > 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.
> 
> 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...  :-)
> 
> Naveen

-- 
Egor Pasko


Mime
View raw message