First draft of translation document
Rémi Forax
forax at univ-mlv.fr
Wed May 19 09:40:58 PDT 2010
Le 19/05/2010 17:05, Neal Gafter a écrit :
> On Wed, May 19, 2010 at 2:35 AM, Rémi Forax<forax at univ-mlv.fr> wrote:
>
>>> 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.
>>
> I don't know what you mean by "known by the VM", or how a separate VM
> feature could make any difference, since these frame object must be
> heap allocated. Perhaps you're advocating some kind of structural
> types at the VM level?
>
yes something like that.
>
>> 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 initialization of the variable s "happens before" the thread is
> even created, so there is no race condition. This program always
> prints "hello". This is no different than if s had been a field.
>
I am not a concurrency guru but I think you are wrong.
The field s of the Frame can be printed by another thread before it is
initialization.
The local variable s will be correctly initialized but not the
corresponding field in Frame.
Rémi
More information about the lambda-dev
mailing list