Built-in vs. 5.0 Locking

[Rob Eden]

Hello Glaziers -

I've put together a test application to test locking performance in  
GlazedLists using the built-in locking vs. Java 5's locking. The  
results are pretty surprising.


Bottom line first: 5.0 locks CRUSH the built-in locks. The build-in  
locks take almost 3 times as much time.


Ok, now the details...

My test apps does the following:
     - 2 writer threads, waiting between 0 and 10 ms between writes
       add a single Long per write
     - 20 reader threads, running as fast as they can
       get the size of the list & get a random item per read
It runs for one minute and then reports how many read/writes we done  
and how much time the operations* took.

*: Note, the timing for the operation includes acquiring the lock,  
doing the add or read, and releasing the lock. So, it tests more than  
the locking, but the access time should be constant since the only  
variable is the lock implementation.

This timing was done on the following system:
     PowerMac G5 - 2x2.5 GHz
     Mac OS X 10.4.2
     1.5 GB RAM
VM was tuned with these options:
     -Dglazedlists.lockfactory.debug
     -verbose:gc
     -Xmx50m
     -Xms50m

"Default Locks" is using the built-in Doug Lea-derived lock.
"5.0 Locks" uses java.util.concurrent.locks.ReentrantReadWriteLock
"5.0 Single Lock" uses java.util.concurrent.locks.ReentrantLock (same  
lock returned for read & write lock)

Conclusions:
     - There's a significant performance gain to using Java 5's
       locking in thread-intensive environments.
     - The overhead of ReadWriteLocks appears to have been
       mostly removed in Java 5.

I also the 1.4 equivalient of "5.0 Single Lock" where I ported Doug  
Lea's ReentrantLock class and used a single lock for reads and  
writes. Due to the heavy thread usage in this test case it performed  
horribly. I sort of expected that result with the "5.0 Single Lock"  
case too. No idea why it worked so much better.

I'll check the test application in soon.

Rob


--

"Let your heart soar as high as it will.
  Refuse to be average."
                            - A. W. Tozer



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jesse Wilson]

Yo Rob ---

Great work on the PDF, it looks like going to Java 5 locks
will be quite compelling. Could you resend that jpg as a PDF -
the resolution of the jpg makes it completely unreadable.

As for my ongoing effort, building a Java parse tree is easy.
But I'm having a hell of a time writing that tree back to disk.
I really need something like DOM but for Java!

Cheers,
Jesse


On 26-Jul-05, at 9:31 PM, Rob Eden wrote:

> Hello Glaziers -
>
> I've put together a test application to test locking performance in  
> GlazedLists using the built-in locking vs. Java 5's locking. The  
> results are pretty surprising.
>
>
> Bottom line first: 5.0 locks CRUSH the built-in locks. The build-in  
> locks take almost 3 times as much time.
>
>
> Ok, now the details...
>
> My test apps does the following:
>     - 2 writer threads, waiting between 0 and 10 ms between writes
>       add a single Long per write
>     - 20 reader threads, running as fast as they can
>       get the size of the list & get a random item per read
> It runs for one minute and then reports how many read/writes we  
> done and how much time the operations* took.
>
> *: Note, the timing for the operation includes acquiring the lock,  
> doing the add or read, and releasing the lock. So, it tests more  
> than the locking, but the access time should be constant since the  
> only variable is the lock implementation.
>
> This timing was done on the following system:
>     PowerMac G5 - 2x2.5 GHz
>     Mac OS X 10.4.2
>     1.5 GB RAM
> VM was tuned with these options:
>     -Dglazedlists.lockfactory.debug
>     -verbose:gc
>     -Xmx50m
>     -Xms50m
>
> "Default Locks" is using the built-in Doug Lea-derived lock.
> "5.0 Locks" uses java.util.concurrent.locks.ReentrantReadWriteLock
> "5.0 Single Lock" uses java.util.concurrent.locks.ReentrantLock  
> (same lock returned for read & write lock)
>
> Conclusions:
>     - There's a significant performance gain to using Java 5's
>       locking in thread-intensive environments.
>     - The overhead of ReadWriteLocks appears to have been
>       mostly removed in Java 5.
>
> I also the 1.4 equivalient of "5.0 Single Lock" where I ported Doug  
> Lea's ReentrantLock class and used a single lock for reads and  
> writes. Due to the heavy thread usage in this test case it  
> performed horribly. I sort of expected that result with the "5.0  
> Single Lock" case too. No idea why it worked so much better.
>
> I'll check the test application in soon.
>
> Rob
>
> <Locking.jpg>
>
> --
>
> "Let your heart soar as high as it will.
>  Refuse to be average."
>                            - A. W. Tozer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

[Rob Eden]

Oh sorry 'bout that. It was supposed to be a PDF. I don't know why it  
was converted to a jpg. :-(

The times are in nanoseconds, BTW.


Rob


On Jul 27, 2005, at 3:14 AM, Jesse Wilson wrote:

>
> Yo Rob ---
>
> Great work on the PDF, it looks like going to Java 5 locks
> will be quite compelling. Could you resend that jpg as a PDF -
> the resolution of the jpg makes it completely unreadable.
>


--

"Let your heart soar as high as it will.
  Refuse to be average."
                            - A. W. Tozer



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]