Re: [cp-patches] Re: Some VMStackWalker cleanups/simplifications

[Archie Cobbs]

Robert Lougher wrote:
> The change to getClassContext() when it was moved from VMSecurityManager to 
> VMStackWalker.  The old version was responsible for popping off TWO frames (in 
> addition to those for reflection).  The one for VMSecurityManager AND the one 
> for SecurityManager itself.  The new one only pops off the one for itself, i.e. 
> VMStackWalker.
>
> This is the kind of change that Marks' proposal was designed to fix.  Implicit 
> stack depth assumptions, which will break if the calling order changes.  And as 
> for efficiency, take a look at the implementation of 
> SecurityManager.getClassContext() using VMStackWalker.  Because 
> VMStackWalker.getClassContext() no longer pops off the frame for 
> SecurityManager it has to do an array copy into a new array.  Admittedly, this 
> method has mostly been replaced by the more efficient ones, but it indicates 
> the interface is not optimal.

I'm partly responsible for the current state of things.. however..
I'd just like to point out that the VMStackWalker patch, though maybe not
the optimal solution, was in fact an improvement on the previous situation.
Previously, there was no way to know how many stack frames to pop off.

E.g.: user code might call System.load(), which calls Runtime.load(), or
it might call Runtime.load() directly. But also, System.java might need to
load a native library itself (by calling Runtime.load()). So there was
simply no way to guarantee the right class was identified as the one whose
class loader the native library should be associated with.

The current way of doing things, even though it forces SecurityManager
to do a System.arraycopy(), at least guarantees correct semantics no matter
what the code that calls VMStackWalker does or how it may change in the
future.

> Any easy way to fix this problem is to replace the Class argument with a count, 
> 2 frames to pop for SecurityManager, 1 everywhere else.  This could be a stupid 
> suggestion, I haven't given it a lot of thought.

Is the problem you're referring to the System.arraycopy()? If so, then
the 'count' argument would be a nice way to avoid it, but IMHO one array
copy is not that big of a deal. Note also that most customers of the
VMStackWalker patch will invoke the optimized methods getCallingClass()
and getCallingClassLoader().

However, if this is really a problem, perhaps a stack iterator type
of implementation (as suggested) would be a better way to do things.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com