David P Grove wrote: > > 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.
That's definitely a worthwhile improvement over the array approach, but I'd still like to see getCallerClassLoader special cased, because that allows the JIT to inline methods that use it (if you have a JIT that knows about getCallerClassLoader). Regards, Jeroen _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
