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