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

Tobias Hartmann tobias.hartmann at oracle.com
Wed May 28 09:49:45 UTC 2014


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




More information about the core-libs-dev mailing list