ReentrantLock performance regression between JDK5 and 6/7?

[Tom Rodriguez]

On Aug 12, 2011, at 12:57 AM, Florian Weimer wrote:

> * Tom Rodriguez:
> 
>> I believe this was caused by the switch to using lock addl[esp], 0
>> instead of mfence for volatile membars, 6822204.  My review request
>> for that said that at the time I didn't measure any performance change
>> for Intel, http://cr.openjdk.java.net/~never/6822204.  On your
>> microbenchmark I can measure the difference though so I'm going to
>> remeasure derby which previously showed the big difference.  We may
>> want to make the lock addl be AMD specific.
> 
> Couldn't the relative speed of the two instructions also depend on the
> type of benchmark?

These are primarily being emitted for volatile fences so many programs won't care about their speed at all.  If you look at my other email it suggests that the difference is that Intel chips prior to Nehalem had heavier weight implementation of lock addl than was required.  mfence stayed approximately the same between processor versions with it's speed pretty much tracking the relative clock speeds, 2.4 for the Tigerton and 2.8 for Nehalem.  The original data suggested no performance change on Nehalem when switching instructions so it probably doesn't care either way.

tom

> 
> -- 
> Florian Weimer                <fweimer at bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstraße 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99