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

[Mark Wielaard]

Hi,

On Sun, 2005-01-16 at 19:56 +0100, Jeroen Frijters wrote:
> Mark Wielaard wrote:
> > This way it is much easier to
> > generically check for skipping this class and the Method.invoke() call
> > on the stack without depending on the actual stack depth.
> 
> Adding the Class parameter to getCallingClass[Loader] doesn't solve the
> Method.invoke() scenario and adds way too much performance overhead to
> be acceptable to me. This is optimizing for the wrong thing. If a VM
> doesn't provide a custom VMStackWalker it's OK to be a little less
> efficient, but the interface design shouldn't force the inefficiency on
> every VM.

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).
The Class parameter is fixed at each callsite so shouldn't add any real
overhead. A runtime is encouraged to implement all three VMStackWalker
methods as efficiently as possible. Using the Class parameter should
help in making it more efficient and robust since you don't have to
depend on the current call stack depth. I'll add this to the
documentation.

Cheers,

Mark

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