As of jdk6, per-thread read holds are tracked by ReentrantReadWriteLock.
While very useful for catching coding errors where read lock unlock actions
are not matched by a lock action in the same thread, the cost of 
maintaining such counts was surprisingly high in runtime space and/or time.
See:
6625723 Excessive ThreadLocal storage used by ReentrantReadWriteLock
for our best attempt to mitigate this cost.

For most users, the extra safety of tracking read holds is not worth the
extra overhead.  The maintainers of ReentrantReadWriteLock now regret
having added this extra overhead.  Unfortunately, we cannot withdraw support
for this, since we added the public getReadHoldCount method.

But we can add a constructor that explicitly disclaims support for tracking
read hold counts.