> Archie Cobbs wrote:
> > Before I go and implement this, does this sound correct to everyone?
>
> I think we desperately need a VMClassLoader.getCallerClassLoader()
> method. That way we can simply modify the various load/loadLibrary
> methods to call that. It's also much more efficient to implement and
can
> be interacts better with method inlining.
In Jikes RVM we use an internal widget called VM_StackBrowser.
Think of it as an interator on the thread stack. It supports
the following primary functionality: (1) get the VMClass or java.lang.Classloader for the
current stackframe (2) move up one stackframe.
This is more flexible than getCallerClassLoader, but
also much more efficient in that it doesn't force the big nasty [] for
the entire stack to be created up-front when the caller almost never wants
more than the top few frames. The implementation works on the stack
directly and doesn't create useless objects/arrays of stuff that clients
don't actually need.
I'd suggest that something like this be adopted by
classpath as the low-level interface for walking stakframes. It can
be both efficient and flexible at the same time.