David P Grove 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.
That's a neat idea.. presumably it keeps some internal "pointer" to the current (or next) stack frame. So does this pointer become invalid if the method using the VM_StackBrowser returns? I.e., are you restricted to only using a VM_StackBrowser instance within the same method that created it? Guess so, because otherwise you'd have to copy all the pointers. This would be acceptable I think, because we could make this VM_StackBrowser class package private to java.lang and so ensure proper usage. (In JC it's easy to see how to implement this using a struct _jc_stack_crawl.) -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath