Re: Implementation details of VMStackWalker

[Ingo Prötel]

Am Freitag, den 22.07.2005, 23:59 +0200 schrieb Mark Wielaard:
> Hi,
> 
> 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:
> http://lists.gnu.org/archive/html/classpath-patches/2005-01/msg00138.html
> 
> 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).
> 
My proposal does not go that far and would not be as universal as adding
a parameter.

I would like to get the common case where private or protected methods
are called before the actual stack check happens. This changes the
current semantic but I feel that it would be more useful and less
fragile to changes of classes that want to use VMStackWalker. If there
is a real need for a method with the current semantic we could just add
a method to the interface for the new semantic.

ingo
-- 
Ingo Prötel                                          address@hidden
aicas GmbH                                        http://www.aicas.com
Haid-und-Neu-Str. 18                        phone   +49 721 663 968-32
76131 Karlsruhe                             fax     +49 721 663 968-93
Germany