JDK6 locks use a LOT more memory then JDK5

Question

I'm happy user of java 5 concurrency utilities - especially read/write locks. We have a system with hundreds of thousands of objects (each protected by read/write lock) and hundreds of threads. I have tried to upgrade system to jdk6 today and to my surprise, most of the memory reported by jmap -histo was used by thread locals and locks internal objects...
As it turns out, in java 5 every lock had just a counter of readers and writers. In java 6, it seems that every lock has a separate thread local for itself - which means that there are 2 objects allocated for each lock for each thread which ever tries to touch it... In our case, memory usage has gone up by 600MB just because of that.
I have attached small test program below. Running it under jdk5 gives following results:
Memory at startup 114
After init 4214
One thread 4214
Ten threads 4216With jdk6 it is
Memory at startup 124
After init 5398
One thread 8638
Ten threads 39450This problem alone makes jdk6 completly unusable for us. What I'm considering is taking ReentranceReadWriteLock implementation from JDK5 and using it with rest of JDK6. There are two basic choices - either renaming it and changing our code to allocate the other class (cleanest from deployment point of view) or putting different version in bootclasspath. Will renaming the class (and moving it to different package) work correctly with jstack/deadlock detection tools, or they are expecting only JDK implementation of Lock ? Is there any code in new jdk depending on particular implementation of RRWL ?
Why this change was made btw ? Only reason I can see is to not allow threads to release read lock taken by another threads. This is a nice feature, but is it worth wasting gigabyte of heap ? How this would scale to really big number of threads ?
Test program
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.*;
public class LockTest {
  static AtomicInteger counter = new AtomicInteger(0);
  static Object foreverLock = new Object();
  public static void main(String[] args) throws Exception {
    dumpMemory("Memory at startup ");
    final ReadWriteLock[] locks = new ReadWriteLock[50000];
    for ( int i =0; i < locks.length; i++ ) {
      locks[i] = new ReentrantReadWriteLock();
    dumpMemory("After init ");
    Runnable run = new Runnable() {
      public void run() {
        for ( int i =0; i< locks.length; i++ ) {
          locks.readLock().lock();
locks[i].readLock().unlock();
counter.incrementAndGet();
synchronized(foreverLock) {
try {
foreverLock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
new Thread(run).start();
while ( counter.get() != 1 ) {
Thread.sleep(1000);
dumpMemory("One thread ");
for ( int i =0; i < 9; i++ ) {
new Thread(run).start();
while ( counter.get() != 10 ) {
Thread.sleep(1000);
dumpMemory("Ten threads ");
System.exit(0);
private static void dumpMemory(String txt ) {
System.gc();
System.gc();
System.gc();
System.out.println(txt + (Runtime.getRuntime().totalMemory()-Runtime.getRuntime().freeMemory())/1024);

Answer 1

Controlling access/update to data is what DBMS are
all about.And our framework is more or less DBMS.
Imagine that you need a SQL database with following extensions:
If any row you have ever requested is modified, you should get a new version transparently plus get notified about the change (what fields have changed)
If any query you have ever done would return different rows then previously, the result collection should be modified and you should be notified about the change (delta to previous contents).
It is distributed-cache-meets-DBMS framework.
Some of the entities are backed by actual database for persistence, but others are not (they are in transient memory only, or views to data managed by completly different systems).
We could stay with R/W locks for the lists and plain locks for objects - but even the number of lists in the system (5-10k) could already have some effect when multiplied by the number of threads - and originally the cost for having R/W lock per object was relatively small and it seems cleaner and more scalable.
Just from top of my head I can give the example where I was searching the list of the objects for the index to insert a new one in write lock, but I have switched to searching this list in read lock, then changing to a write lock and searching area around previously found place (as list could be modified in the moment lock is upgraded, but in most cases I have to search only 1-2 indices around). This change had incredible perceived performance impact (as rendering code for a JTable was using model based on the same list with a readlock). For single object locking it is not so obvious, but still there are objects which can locked for reading from many threads concurrently.