First draft of translation document
Rémi Forax
forax at univ-mlv.fr
Wed May 19 02:35:11 PDT 2010
Le 19/05/2010 05:31, Neal Gafter a écrit :
> On Tue, May 18, 2010 at 6:02 PM, Rémi Forax<forax at univ-mlv.fr> wrote:
>
>>> 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.
>>
> These frame objects are not stack allocated. They must be managed by
> the GC. Thus, an object header is required.
>
The whole point of asSam() is to try to avoid the static footprint that
you currently have with anonymous classes.
If the frame object is not know by the VM, the compiler have to generate
a specific class for each frame object
thus we are falling in the same trap as anonymous classes.
>
>>> 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.
>>>
>> Threse aren't that ordinary because you have to create a new keyword or if
>> you prefer a new semantics
>> for those kind of variables.
>>
> Neither is needed. While project lambda may elect to have a new
> keyword for other reasons, it is not necessary. Neither are new
> semantics required.
>
The problem with shared variables is that you break the assumption
that you have sequential ordering of local variables.
I don't see why we should offer a feature with such semantics.
void f() {
shared String s = "hello";
Utils.perhapsRunInAnotherThread(#() {
System.out.println(s); // may or may not prints null
});
}
The Java memory model is sufficiently complicated to not add more
subtilities.
[...]
Rémi
More information about the lambda-dev
mailing list