

JDK7 to have escape analysis on by default...also back ported to JDK6 - suprgeek
http://weblogs.java.net/blog/forax/archive/2009/10/06/jdk7-do-escape-analysis-default

======
sadiq
Interestingly, this could really boost performance for languages on the JVM
like Scala as they tend to create an awful lot of temporary objects.

~~~
danh
Now, the only really big thing missing from the JVM seems to be proper tail
call optimisation. Does anyone know the status of that?

~~~
jacquesm
I'm confused here, isn't that something that is better handled at compile time
than in the JVM ?

~~~
slava_pestov
tl;dr: No, it has to be built-in to the JVM.

First of all, if a JVM were to attempt this optimization for tail calls using
the ordinary method call bytecodes, it would break existing programs that are
written to rely on stack frame inspection.

So the only solution is to add a new bytecode for tail calling methods, so
that this bytecode can be used from non-Java languages without impacting
existing code; however there's no such bytecode yet.

Self-tail calls (where a function calls itself in tail position) can be
compiled as a goto, however this is not as general as full tail call
elimination (you cannot implement a state machine consisting of several
functions this way, for insance).

Also, an arbitrary set of tail-recursive functions can be compiled into
something that fakes a call stack using a heap-allocated data structure, with
a top-level trampoline that drives an interpreter loop. However this incurs a
significant performance penalty, and requires a whole-program transform. When
you hear about Scheme implementations on the JVM that implement tail calls and
call/cc, they generally use this trick, and as a result as too slow to be
useful.

So, right now there's no good solution for tail calls on the JVM, and it would
require changes to the JVM to implement in full generality.

~~~
jacquesm
> Self-tail calls (where a function calls itself in tail position) can be
> compiled as a goto

Right, that's the example that I had in mind.

I can see that for more complicated situations something more would be
required, but I always figured that if the JVM is turing complete that it
should be possible to 'target' any language to it without having to invent
special bytecodes. Probably this is a direct consequence of the JVM and java
being developed in tandem, it is not as general as I thought it was.

Thanks!

~~~
sunkencity
This is why clojure has a special form for tail call where you can "recur" a
loop by re-binding the variables. When proper tail call comes to JVM, it'll be
possible to do write the loop as a function call instead of hiding it inside a
function.

    
    
      (def factorial
        (fn [n]
          (loop [cnt n acc 1]
             (if (zero? cnt)
                  acc
                (recur (dec cnt) (* acc cnt))))))

~~~
xtho
In java, you could use the "while" keyword for that.

Anyway, tail-calls aren't necessarily loops. If I'm not mistaken, tail-call
optimisation for looping constructs only (which the poster a few levels above
probably had in mind) wouldn't require a special byte code.

------
nuclear_eclipse
So, what exactly is escape analysis? Neither the article nor the comments here
even touch on it.

~~~
idlewords
<http://en.wikipedia.org/wiki/Escape_analysis>

In a nutshell, figuring out whether a variable or object is going to be
entirely confined to a single thread and scope and using that information to
perform optimizations (like sticking things into registers) or avoid
unnecessary locking.

~~~
sb
afair, the most important optimization there is that something can be
allocated on the stack instead of the heap, which is quite an optimization.
EDIT: it does not actually have anything to do what you can stick in registers
--at least nothing comes to my mind w/o thinking too hard about it...

relevant papers directly from the hotspot-jvm are:

-kotzmann, moessenboeck, "escape analysis in the context of dynamic compilation and deoptimization" [http://www.usenix.org/events/vee05/full_papers/p111-kotzmann...](http://www.usenix.org/events/vee05/full_papers/p111-kotzmann.pdf)

-kotzmann, moessenboeck: "run-time support for optimizations based on escape analysis" <http://ftp.ssw.uni-linz.ac.at/Research/Papers/Ko07/Ko07.pdf>

~~~
slava_pestov
Actually, once you've figured out that you can stack allocate an object, you
can stick its instance variables in registers. This can be a huge win.

------
imd
Does this mean that simple accessors (or at least getters) effectively have no
method call overhead?

Also, the linked article's linked article mentions (in 2005) that Java 6 would
have had this. What happened?

~~~
slava_pestov
> Does this mean that simple accessors (or at least getters) effectively have
> no method call overhead?

Method inlining has nothing to do with escape analysis (other than enabling it
in more cases) and in any case getters and setters have had zero overhead
since HotSpot was first introduced in Java 1.3.

