[concurrency-interest] Thread subclass check locking is a bottleneck

[Gregg Wonderly]

I have an old application that implements it's own thread pooling.  But, 
this is an issue simply related to the java.lang.Thread constructor 
locking on subclass construction.  I am seeing stuck threads of the form:

   java.lang.Thread.State: BLOCKED (on object monitor)
        at java.lang.Thread.isCCLOverridden(Thread.java:1521)
        - waiting to lock <0xaca0a778> (a sun.misc.SoftCache)
        at java.lang.Thread.init(Thread.java:338)
        at java.lang.Thread.<init>(Thread.java:419)

The global lock used there seems to be an unfortunate choice.  The code 
I see on the internet is:

 1615       private static boolean isCCLOverridden(Class cl) {
 1616           if (cl == Thread.class)
 1617               return false;
 1618           Boolean result = null;
 1619           synchronized (subclassAudits) {
 1620               result = (Boolean) subclassAudits.get(cl);
 1621               if (result == null) {
 1622                   /*
 1623                    * Note: only new Boolean instances (i.e., not Boolean.TRUE or
 1624                    * Boolean.FALSE) must be used as cache values, otherwise cache
 1625                    * entry will pin associated class.
 1626                    */
 1627                   result = new Boolean(auditSubclass(cl));
 1628                   subclassAudits.put(cl, result);
 1629               }
 1630           }
 1631           return result.booleanValue();
 1632       }

Wouldn't it be more prudent for the lock held during auditSubclass to be on cl and not the global table?

Gregg Wonderly