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

[Vladimir Ivanov]

Tobias, I'll take care of it.

Best regards,
Vladimir Ivanov

On 6/2/14 10:04 AM, Tobias Hartmann wrote:
>
> 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
>>>
>