First draft of translation document

[Neal Gafter]

On Tue, May 18, 2010 at 4:40 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

> Now the not agree part:
> Local variables can also be accessed by reference (with "shared"),
> 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".
>    Remember how the scheme to compile inner-classes changes over the
> time in javac.
>

Language features are not to be defined by the features of the VM.  In this
case, the implementation strategy is a contract between the compiler and
itself.  There is no interoperability issue between languages and compilers
that may do it in ways that differ in detail.


>  - it's not Java, as far as I know, there is no pass by reference in Java
>

This is not proposing a pass-by-reference language feature.  It is
describing a way to compile code that references ordinary mutable
variables.  Mutable variables are definitely part of and in the spirit of
Java.

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

Indeed, that is already the case for local variables.  Final local variables
can already be shared among threads, and the current memory model does not
specify the behavior.  They happen to be implemented by Java compilers as
fields, which is the only available implementation strategy.  The behavior
for both final and non-final variables can be specified by reference to
existing specification text describing the behavior for fields.