> 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.
--dave
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
