[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Implementation details of VMStackWalker

From: Ingo Prötel
Subject: RE: Implementation details of VMStackWalker
Date: Mon, 25 Jul 2005 11:49:29 +0200

Am Montag, den 25.07.2005, 10:16 +0200 schrieb Jeroen Frijters:
> Ingo Prötel wrote:
> > 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.
> I'm *very* strongly opposed to this. It makes auditing the code for 
> correctness of VMStackWalker *much* harder and it adds no value.
I really like the idea of having a stack walker so I would like to use
it wherever possible. For example in java.util.logging.Logger. If a
class calls 'logger.warning("some warning")' this call will be forwarded
through a couple of calls until it will call 'Logger.log(Level level,
String message, Throwable thrown)' there the stack will be inspected to
get the calling class and calling method. The current implementation of
VMStackWalker would require the generation of the full class context to
get the class that called 'Logger.warning(String)' since
'VMStackWalker.getCallingClass()' would always return 'Logger'. But
creating the whole class context is expensive. 

And yes our AOT compiler can simply inline the methods but not the
simple interpreter that we use to run dynamically loaded classes.

No I'm not sure if checking for assignability really is useful. But if
somebody wants to create their own Logger subclass it would just work as
I would expect when a call is forwarded to the Logger. But I admit I
have not yet checked what happens on a Sun VM in such a case.

> > The next thing I would like to have is a method to get the calling
> > method name. This would be good for logging. 
> Yeah, we should probably add a method to get the calling method and maybe 
> another one to get the entire stack trace (as a java.lang.reflect.Method[]).
> > For the security part: Is it enough to check if the class loader of
> > context[0] is the boot classloader?
> You don't need to enforce that, the documentation is just intended to point 
> out that this is a privileged call that is not available to untrusted code. 
> The security model will be used to enforce that untrusted code cannot call 
> code in the gnu.classpath.* package.

Does this mean the VM must check for every call if it is a call into 
the gnu.classpath.* package and if so check the classloader of the calling 

Ingo Prötel                                          address@hidden
aicas GmbH                              
Haid-und-Neu-Str. 18                        phone   +49 721 663 968-32
76131 Karlsruhe                             fax     +49 721 663 968-93

reply via email to

[Prev in Thread] Current Thread [Next in Thread]