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
