Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 10:34 UTC (Tue) by eru (subscriber, #2753)
In reply to: Security of Java takes a dangerous turn for the worse, experts say (ars technica) by peter-b
Parent article: Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Makes it literally impossible to implement a Scheme on top of the JVM, for example (the Scheme spec *requires* tail call optimization).

Now I'm curious: How can the JVM prevent tail call optimization? After all, it is just a matter of updating the variables that correspond to the parameters of the function, and then executing a goto to its start. And the JVM (being a low level language) has a goto.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 11:50 UTC (Tue) by peter-b (guest, #66996) [Link]

There's an interesting question on Stack Overflow that covers this:

http://stackoverflow.com/questions/105834/does-the-jvm-pr...

Don't forget that "true" tail call optimization implies that *any* tail call can be optimized, not just the self-recursion<->loop case.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 12:04 UTC (Tue) by HelloWorld (guest, #56129) [Link]

That's the kind of workaround I was referring to, it breaks for non-trivial cases, for example when it's not known at compile time which function implementation a call will end up in.

scala> import scala.annotation.tailrec
import scala.annotation.tailrec

scala> class Test {
     |   @tailrec def apply { apply }
     | }
<console>:9: warning: method apply in class Test does nothing other than call itself recursively
         @tailrec def apply { apply }
                              ^
<console>:9: error: could not optimize @tailrec annotated method apply: it is neither private nor final so can be overridden
         @tailrec def apply { apply }
                      ^

It fails even for simple mutually recursive definitions:

scala> @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)
<console>:10: error: @tailrec annotated method contains no recursive calls
       @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)
                    ^
<console>:10: error: @tailrec annotated method contains no recursive calls
       @tailrec def even(x: Int): Boolean = x == 0 || odd(x - 1); @tailrec def odd(x: Int): Boolean = x != 0 && even(x - 1)

It's not just about tail *recursion* optimization, it's about general tail *call* optimization. JVM modifications are needed to make this kind of thing work.

Security of Java takes a dangerous turn for the worse, experts say (ars technica)

Posted Sep 17, 2013 18:56 UTC (Tue) by jonabbey (guest, #2736) [Link]

The StackOverflow link does a good job talking about the problem. Clojure gets around this by having explicit loop and recur statements that the Clojure compiler uses to set up trampolines as needed for recursion.

Without having JVM-level support, though, you do lose some tooling support and flexibility. It would make a very nice addition to the JVM, albeit more work to do than the invokedynamic feature that was added in Java 7 to support dynamic languages on the JVM.