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

Tobias Hartmann tobias.hartmann at oracle.com
Mon Jun 2 06:04:02 UTC 2014

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

More information about the core-libs-dev mailing list