Re: Tail recursion in Java, was Proper Tail Recursive C++

: The security manager which is part of the security API has a function
: that lets the SM figure out the call chain. Some of the current
: security mechanisms would conceivably break in the presence of tail
: call optimizations. I think this is the main reason Java is "stuck"
: with the stack model for now at least.


erik schnetter <erik.schnetter@student.uni-tuebingen.de> writes


> It is that bytecode that is then checked by the security mechanisms,
> not the source code. So while the elimination of tail recursion can
> possibly change the semantics of a program (if it has access to its
> own call chain), it can never break the security mechanisms. And
> this "change in semantics" might just be what you want.


This is wrong. For example consider the policy that only secure
methods can be invoked if every method in the *runtime* call chain is
also secure. This policy relies on having a stack frame for every
method invoked on the runtime stack.


Think of the situation when a secure method 'S1' calls an insecure
method 'I', and 'I' calls a secure method 'S2'.


S1() { I(); }
I() { S2();
            /* do insecure things */
          S1();}
S2() { ...};


Under the stated policy I should not be able to invoke 'S1' since
method 'I' is insecure, but if we perform a tail call optimization as
you suggest you get something like.


S1() { while(true){
              S2(); /* do insecure things */
            } }
S2() { ...};


With this optimization the call to 'S2' isn't prevented from happening
since the stack frame of method 'I' disappears and you can't enforce
at *runtime* the policy as stated. Perhaps there is a secure way to do
the tail call optimizations, but I don't think anyone's done enough
thinking to figure out how to get all the details right.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.