Re: Implementation details of VMStackWalker

[Andrew Haley]

Mark Wielaard writes:
 > 
 > 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.

Well, that's up to the VM implementer.  IMO trying to unify low-level
stack walker code is unnecessary and leads to too many compromises;
it's a merge too far.

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

Andrew.