First draft of translation document

[Brian Goetz]

> So for the JSR292 expert group, we have to correctly specifies
> asSam() and provides a polymorphic bindTo/insertArguments.

Well, I'd say its a "kind request" to the JSR-292 expert group rather than a 
"demand" :)

But yes, this specific translation strategy would benefit from some specific 
help from MethodHandle.

> Now the not agree part:
> Local variables can also be accessed by reference (with "shared"),

Let's set aside the question of how we refer to captured mutable variables for 
now -- this is a language issue which we will surely return to.  Let's just 
assume for this discussion that the translation approach needs to accomodate 
this use case (and we later choose to disallow it, then the type 1/2/3 
distinction becomes merely type 1/2.)

> in that case the compiler needs to construct a frame object to store the
> local variables,
> bind the frame to the method handle and retrieve the value after the call.
>
> I don't like it because:
>    - there is no support offered by the VM for that, so each compiler
> (version of compilers)
>      will choose a different ways to optimize or worst "perhaps optimize".

I don't like the Frame class either, but without additional VM support (which 
is unlikely to come from JSR-292 in the JDK 7 time frame) I'm not sure what 
the alternatives are.

In an example like:

   int total = 0;
   list.forEach(#(Person p) { total += p.getFoo(); });

There are really two cases:
  - The closure may escape from forEach(), and be saved for later or called 
from another thread;
  - The closure will not escape from forEach()

In the escaping case, I don't see how we can avoid the Frame even with VM 
support -- we need to use the Frame to extend the dynamic scope of the 
captured variables beyond their lexical scope.

In the non-escaping case, I think what you are appealing to is that total 
should live on the stack.  I think what happens here comes down to whether the 
VM can inline all the way through from the caller to forEach() and back 
through the closure.  If it can, then escape analysis eliminates the frame, 
and the locals can be hoisted into registers, and all the mechanics of 
capturing the closure are folded away.

>    - the proposed scheme introduces a hidden allocation (perhaps !)

I'm OK with that.

>    - the impact on the memory model is far from clear, one day shared
> vars will have to
>      be specified in term of happen-before.

For sure.  The JLS describes seven types of variables (though the distinction 
between two of them is pretty tenuous).  A "shared" local variable is 
definitely an eighth kind of variable.  I am in favor of making this 
distinction explicit so that the memory model semantics are clear.