[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implementation details of VMStackWalker

From: Mark Wielaard
Subject: Re: Implementation details of VMStackWalker
Date: Fri, 22 Jul 2005 23:59:19 +0200


On Fri, 2005-07-22 at 18:01 +0100, Andrew Haley wrote:
> Ingo Prötel writes:
>  > I just implemented VMStackWalker for our VM and have some questions.
>  > 
>  > The reference implementation of 'getCallingClass()' and
>  > 'getCallingClassLoader()' just look at the third entry in the class
>  > context. Would it not be better to return the first class that is not
>  > assignable to the class in context[0] ? That way we could cope with
>  > classes that first call some private or protected classes an then ends
>  > up calling the stack walker. 
> In gcj, we have a method called GetCallingClass(Class c).  It searches
> firstly for a method declared in class c, then for a method not
> declared in c.  We have found, after a certain amount of trouble, that
> this is the right way to do things; it means that an arbitrary number
> of stack frames can be between the direct caller of GetCallingClass
> and the user code, and it also means that you don't have to check for
> assignability, but for an exact match.

I proposed something similar a while ago:

Jeroen did object strongly to this approach though since he felt that
having (and constructing) an extra argument for this function was too
much overhead for runtimes that didn't need it to begin with.
It might be good to review that thread and see how/if we can have some
solution/compromise here since it seems that gcj actually needs this
functionality. For the other runtimes we did find some workarounds back
then (how fragile those are I don't actually know).



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]