ReentrantLock performance regression between JDK5 and 6/7?

[Tom Rodriguez]

This is version I made from the snippet below.

mport java.util.concurrent.locks.*;

public class re {
  public static void test() {
 ReentrantLock lock = new ReentrantLock();
        long start = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
        lock.lock();
        lock.unlock();
        }
        System.out.println("Lock bench: " + (System.currentTimeMillis() - start));
  }

  public static void main(String[] args) {
    test();
    test();
    test();
    test();
  }

}

tom

On Aug 14, 2011, at 11:00 AM, Charles K Pepperdine wrote:

> Underlying TSC supporting nanoTime has it's own issues.
> 
> May I ask where for the code for this benchmark?
> 
> Regards,
> Kirk
> 
> On Aug 11, 2011, at 5:26 PM, Vitaly Davidovich wrote:
> 
>> Which OS are you using?
>> 
>> Also, you should use System.nanoTime() for this type of timing as it gives you a more precise timer.
>> 
>> On Aug 11, 2011 10:49 AM, "Clemens Eisserer" <linuxhippy at gmail.com> wrote:
>> > Hi,
>> > 
>> > Recently I played a bit with wait/notify as well as await/signal, to see
>> > which solution handles the case of few calls to wait/await but a lot
>> > notify/signal calls better.
>> > ReentrantLock/Condition came out far ahead and in general both results where
>> > quite good :)
>> > 
>> > I noticed however a performance degradation between jre5u22 and
>> > openjdk6/jdk7b147.
>> > The following micro-benchmark executes in 41ms with jre5u22 but takes 53ms
>> > on jdk6/7 on my Core2Duo/Conroe:
>> > 
>> > ReentrantLock lock = new ReentrantLock();
>> > while (true) {
>> > long start = System.currentTimeMillis();
>> > for (int i = 0; i < 1000000; i++) {
>> > lock.lock();
>> > lock.unlock();
>> > }
>> > System.out.println("Lock bench: " + (System.currentTimeMillis() -
>> > start));
>> > }
>> > 
>> > Is this a tradeoff of some kind, or a regression?
>> > 
>> > Thanks, Clemens
>