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