RE: Implementation details of VMStackWalker

[Jeroen Frijters]

Andrew Haley wrote:
> However, as for overhead -- I don't believe it.  I doubt that not
> having this parameter saves anything much on any VM.

That's just your lack of imagination ;-) I was concerned with two
aspects wrt performance:
1) Class literals are inefficient -- this is no longer an issue to me,
since I now use ecj (in 1.5 mode) to compile GNU Classpath
2) I have to do multiple (partial) stack walks to retrieve multiple
frames

Remember, IKVM is built on top of another VM, so I have to use another
stack walking abstraction to walk the stack. Having to fetch multiple
frames is obviously more expensive than having to fetch a single frame.

*BUT* I have much stronger objections against this model:
1) Like Archie points out, there is no need for this additional
functionality (at least not in the common case)
2) It is very easy to introduce subtle bugs (like the one with the
override I showed)
3) It is tempting to do (either on purpose or accidentally):
  class Foo
  {
    somemethod()
    {
       // "we know we're always being called by Bar and we need its
caller"
       GetCaller(Bar.class);
    }
  }
4) It makes "advanced" optimizations by the JIT harder (the current
interface is very easy for the JIT to special case)

Regards,
Jeroen