|Re: Proper Tail Recursive C++ email@example.com (1997-03-21)|
|Re: Tail recursion in Java, was Proper Tail Recursive C++ danwang@atomic.CS.Princeton.EDU (1997-03-22)|
|Re: Tail recursion in Java, was Proper Tail Recursive C++ Dave@occl-cam.demon.co.uk (Dave Lloyd) (1997-03-27)|
|Re: Tail recursion in Java, was Proper Tail Recursive C++ firstname.lastname@example.org (John D. Ramsdell) (1997-04-02)|
|Re: Tail recursion in Java, was Proper Tail Recursive C++ email@example.com (1997-04-03)|
|Re: Tail recursion in Java, was Proper Tail Recursive C++ firstname.lastname@example.org (1997-05-14)|
|From:||email@example.com (Mark Tillotson)|
|Date:||14 May 1997 23:57:53 -0400|
|Organization:||Harlequin Ltd, Longstanton House, Cambridge UK|
|References:||97-03-129 97-03-136 97-03-155 97-04-019|
> > Surely the compiler has to apply the same policy statically as would
> > be applied dynamically.
> How does a Java VM know that the code it is running is produced by a
Even more to the point, the same class (as compiled) could be secure
in one runtime, and insecure in another - it is a dynamic property of
class loading, not something that can be determined statically.
The solution is that at load time we can make a determination of which
method calls are potentially between trusted and untrusted classes,
and label them as not tail-eliminatable. You also have to do an
analysis for calls from synchronized methods, which are again not, in
[ firstname.lastname@example.org | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]
Return to the
Search the comp.compilers archives again.