From: AJ S. <aj@EECS.berkeley.EDU> - 2003-11-19 22:43:15
|
I've had to do a similar thing: insert instrumentation that had to be able to do pretty much anything. The solution I implemented, and one you may like to consider, allows me to insert a counter instruction with arbitraty arguments; this instruction behaves just like a normal counter instruction for sampling purposes, etc., but when lowered to LIR, it gets converted to a function call to the function of my choice, with the appropriate arguments. So all I have to do is write a function in Java to do whatever data collecting I want, and insert one of my counters into the HIR stream that passes it the arguments it needs. In your case, you would write a function that takes different Objects, and stores their actual runtime types (along with, certainly, the bytecode line the counter occurs on). Then you'd insert a bunch of these counters in the appropriate places, with the Objects in question as arguments. The way I did it was to create a new instruction type (instead of INSTRUMENTED_EVENT_COUNTER, SUPER_INSTRUMENTED_EVENT, or something). This instruction takes a variable number of arguments. I also added a new counter manager, VM_CounterFunctionManager (as opposed to the existing VM_CounterArrayManager) that dealt with this new instruction and lowered it to a function call. I had to patch up some other code, such as Matt Arnold's sampling code, to recognize the super counter as instrumentation code, but there's not much to do other than that. If you do like this solution, hopefully this is a good enough start for you, or I'd be happy to provide more information or code. AJ On Tue, 18 Nov 2003, Brian Tanner wrote: > I see where you're coming from, let's explore this a little further. > > I think this isn't quite going to do what I need, but it may. You see, > I'd like to do this instrumentation without having to know ahead of time > what the actual potential classes are. IE, if a class that I don't know > about (a subclass of C maybe) is loaded after I've been executing for a > while, I'd still like to be able to profile this. > > This is why I was thinking that it would make sense to actually lookup > the type at runtime. I figured there would be a quick instruction I > could throw in that would have the affect of: > Void Foo(A someParam){ > String Key="Foo:"+someParam->getTib()->getType(); > } > Of course this would have to be HIR code... > > The end goal of this is to create a dynamic profile at runtime that an > optimization phase my colleague is writing can make intelligent > decisions when optimizing the method. > > The class loading issue is not the most important thing though, I can > live without it. If I was to do this instrumentation at the bytecode > level, would I just update the BC2IR code to add the code you mentioned? > If so, I guess I'd have to peek at the class hierarchy to look up the > currently loaded subclasses of A? > > My intuition also tells me (and I could be wrong here) that a byte code > level instrumentation would store the information at the program level. > Would there be a decent way for an optimization pass to get at these > values at dynamic recompilation time? > > Thanks in advance for your help here! > > Brian Tanner > University of Alberta > bt...@cs... > > ==== Original Message ==== > If that's only information you need, I would say instrumentation at > bytecode level is much easier. For exmaple, at the beginning of your foo > > method, you can add: > if (someParam instanceof A) > Acount ++; > else if (someParam instanceof B) > Bcount ++; > else > Ccount ++; > > Cheers, > Feng > > > > > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@os... > http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikesrvm-researchers > |