Re: Java Compilers and Tail Recursion

> Jason Karney <jkarney@netgenics.com> asked:
> | Is the current crop of Java compilers smart enough to optimize tail
> | recursion? I am specifically wondering about Symantec and Sun's JDK
> | compilers.


Mark Tillotson wrote:
> Tail-recursion elimination is prohibited by the implementation of the
> Java SecurityMangler. See definitions of getClassContext(),
> classDepth(), inClass(), classLoaderDepth() etc. (section 20.17.* in
> the language spec)


> So the answer is you can't do it _and_ support the ClassLoader/
> SecurityManager protocol. This is (in my opinion) because that
> protocol is an inelegant hack.


The spec explicitly allows "combining" of activation records in
15.11.4.6 (page 337) when they are known to have the same class loader
and the callee is not equal to or derived from SecurityManager. This
is not in direct conflict with the methods provided by
SecurityManager, but it does mean that some of them don't provide
exactly the function that a naive reader of the spec might imagine.
Unfortunately, most readers are naive readers, and some of those naive
readers also write code.


I agree that this is a clunky way to do security; stack-walking is
slow, and depending upon the order of caller's stack frames is very
fragile, either in the face of optimization, or simple code changes
over time. It-would-be-better to do something like what was tried in
the SPIN system, or to introduce capabilities (not to be confused with
"capabilities", which is some term introduced by Netscape to describe
some stack-frame-associated security item that also inhibits tail call
elimination). Note that because Java is type-safe, it is possible to
use capabilities very efficiently; this is not as true of the
sandboxing approach described by Lucco and Wahbe (that they turned
into a product at Colusa Software, which was in turn acquired by
Microsoft).


People do know what a "capability" is, right? It's a token possessed
by an applet (or an application, or a subroutine, or a thread of
control) that encodes the various security-related things that an
applet is allowed to do. The various potentially-dangerous operations
require that you pass them a capability, which they consult to see if
the operation is allowed. For instance, an applet might be handed a
capability that says "you may create files and directories in /tmp,
provided that their total size does not exceed 10mb and all the
directories in /tmp are prefixed with the string xyzzy0123, and you
may delete any files that you create, and rename within any
directories that you create". This capability would need to be passed
to any file system calls. Capabilities can also be manipulated to
create new capabilities; for instance, an applet might create a new
capability with further restrictions imposed and pass it to some
not-entirely- trusted piece of code whose services it requires ("1mb,
may create files in /tmp/xyzzy0123/asdfasdf").
--
David Chase, chase@world.std.com
--

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