A DESCRIPTION OF THE REQUEST :
We have a custom built ETL application that uses highly concurrent model.  All of our data are in test files and are read into double precision variables/arrays.  We often see that our VMs are spending time blocked in sun.misc.FloatingDecimal.big5pow().

pool-66-thread-125" prio=10 tid=0x00002ac880015800 nid=0x6eec waiting for monitor entry [0x000000004880f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at sun.misc.FloatingDecimal.big5pow(FloatingDecimal.java:111)
    - waiting to lock <0x00002ac7fa9b4d90> (a java.lang.Class for sun.misc.FloatingDecimal)
    at sun.misc.FloatingDecimal.multPow52(FloatingDecimal.java:158)
    at sun.misc.FloatingDecimal.doubleValue(FloatingDecimal.java:1510)
    at java.lang.Double.parseDouble(Double.java:510)
...


Apparently, sun.misc.FloatingDecimal.big5pow() caches powers of 5 in

     private static FDBigInt b5p[];

and accesses it via

private static synchronized FDBigInt big5pow( int p )

which is synchronized on the class itself.

  To increase parallel throughput of this method, I suggest to change b5p into a thread variable.  The price paid for this would be duplication of power of 5 caches, which is miniscule for today's large memory models.  Another solution would be to initialize b5p in a static block up to the full extent required for double precision numbers.  Please let me know if you want me to submit a tested fix for this issue and what solution you would prefer.


JUSTIFICATION :
Performance of applications that require highly concurrent high frequency access to  java.lang.Double.parseDouble() would greatly benefit from this change.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No synchronized locks on

private static FDBigInt big5pow( int p )
ACTUAL -
See description.