First draft of translation document

[Rémi Forax]

Le 19/05/2010 02:37, Neal Gafter a écrit :
> On Tue, May 18, 2010 at 4:40 PM, Rémi Forax <forax at univ-mlv.fr 
> <mailto: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.

Agree in general, but not in this specific case.
The frame object or any equivalent data structure should be managed by 
the VM,
it's a stack allocated data structure. There is no need of an object 
header or a vtable
for such data structure.

> 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.

There are always interop issues, some not so stupid tools crawle the 
bytecode,
or some not so stupid users use reflection. The frame object will appear 
as parameter
of the function that will be used to create the lambda.

>
>      - 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.

Threre aren't that ordinary because you have to create a new keyword or 
if you prefer a new semantics
for those kind of variables.

>
>     - 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.

final locals variables aren't translated to fields but final fields. 
Final fields haven't the same semantics
than ordinary fields hence the keyword "final".
I agree that final local variable aren't currently described in the spec 
and should but that doesn't solve the problem
of the semantics of shared local variables.


If the 1.8 VM comes with a way to declare a frame data structure or any 
equivalent stuff
and if someone comes with a clear semantics, I will be okay to introduce 
with shared vars.

Rémi