need to focus on java performance?

[Casey Marshall]

On May 22, 2006, at 9:38 AM, Per Bothner wrote:

> David Daney wrote:
>> I imagine that most of the stack traces are needed for security  
>> checks, and not exceptions.
>
> Excuse me for asking probably a dumb question, since my knowledge of
> Java security is pretty thin:
>
> Why do we need to walk the stack for security checks, in the normal
> case of code not using deprecated methods?
>

In principle you don't need to walk the stack. What you need is a set  
of *code sources* representing what code was present in the calling  
stack, and those code sources are matched to permissions. Running  
through the whole stack and fetching these code sources is just one  
way of doing it, and it obviously isn't the fastest way. GNU  
Classpath's implementation of AccessController does this, because I  
assumed that any VM could walk up the stack easily enough. The  
default implementation just grabs this stack and builds a context  
from it, but if you had a more direct context than that available,  
getContext can just return that.

Using a thread local to store this set as you call methods would  
work, but (like aph says) this would imply some real overhead. Then  
again, you only have to detect when your method call crosses a code  
source boundary, so it might be possible to optimize that. I guess  
depending on the ABI (and forgive any of my naivete in this) you  
could make the method call do different things, so calling between BC- 
compiled modules you would always have this context overhead, but  
direct calls don't; that implies that you weaken the security model  
for "C++-compiled" stuff, but that may be OK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 478 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20060522/b027dd7f/attachment.sig>