RE: [Jikesrvm-researchers] Dynamic type checking... or retrieving, or otherwise resolving...

[Brian T. <bt...@cs...>]

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