RE: [cp-patches] Some VMStackWalker cleanups/simplifications

[Mark Wielaard]

Hi,

On Mon, 2005-01-17 at 00:07 +0100, Jeroen Frijters wrote:
> Mark Wielaard wrote:
> > Right. It isn't needed for the Method.invoke() case, but the default
> > implementation got this wrong so this fix was also included. The Class
> > parameter is needed for those cases where the call stack depth is not
> > precisely know, either because the call was made through some other
> > method or class, the call was inlined by the compiler or runtime or
> > because the runtime actually implements these methods by calling other
> > classes written in java again (kaffe and jikesrvm do this for 
> > example).
> 
> There is nothing in the existing interface that prevents these VMs from
> working. I strongly object to making these incredibly lame changes, just
> to make it a little easier for them.

I think that is a little strong. I think it makes the interface a lot
easier, robust and hopefully more efficient to implement. But if no
runtime hacker likes it this way I will drop it. This was just done to
make it easier for some runtimes like jamvm, sablevm and kaffe that are
currently broken with the current default implementation or cannot adopt
the current interface easily.

> > The Class parameter is fixed at each callsite so shouldn't 
> > add any real overhead.
> 
> Of course it adds overhead, especially with a 1.4 compiler.

Aha. OK, I see where you are comming from. I assumed SomeClass.class
would be compiled efficiently, and I think at least jikes gets it right
by caching the result, but I see gcj doesn't do that and actually calls
Class.forName() each time (eep). So I should actually change the patch
so that it really is a fixed parameter at each callsite by
precalculating it. Will do that.

Thanks,

Mark

signature.asc
Description: This is a digitally signed message part