[9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache

[Tobias Hartmann]

On 28.05.2014 12:48, Vladimir Ivanov wrote:
> Looks good.
>
> It should be safe to sync on MTF instance since it's not accessible 
> outside (MTF and MT.form() are package-private).
>
> Best regards,
> Vladimir Ivanov

Thank you, Vladimir.

Could someone please push the patch?

Thanks,
Tobias

>
> On 5/28/14 1:49 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> thanks everyone for the feedback!
>>
>> @Remi: I agree with Paul. This is not a problem because if the normal
>> read sees an outdated null value, a new LambdaForm is created and
>> setCachedLambdaForm(...) is executed. This will guarantee that the
>> non-null value is seen and used. The unnecessary creation of a new
>> LamdaForm is not a problem either.
>>
>> @John: I added the code that you suggested to simulate CAS. Please find
>> the new webrev at:
>>
>> http://cr.openjdk.java.net/~anoll/8005873/webrev.02/
>>
>> Sorry for the delay, I was on vacation.
>>
>> Thanks,
>> Tobias
>>
>> On 19.05.2014 20:31, John Rose wrote:
>>> On May 16, 2014, at 4:56 AM, Tobias Hartmann
>>> <tobias.hartmann at oracle.com> wrote:
>>>
>>>> Is it sufficient then to use synchronized (lambdaForms) { ... } in
>>>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
>>> Yes, that is how I see it.  The fast path is a racy non-volatile read
>>> of a safely-published structure.
>>>
>>> (If safe publication via arrays were broken, java.lang.String would be
>>> broken.  But the JMM is carefully designed to support safe publication
>>> of array elements, and through array elements.)
>>>
>>> — John
>>