JDK-6627612 : RFE: Remove unncessary volatile usages in java.math.BigDecimal and related classes
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.math
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2007-11-08
  • Updated: 2011-09-14
  • Resolved: 2011-09-14
Related Reports
Relates :  
JDK-7082971 - More performance tuning of BigDecimal and other java.math classes
Description
In java.lang.BigDecimal implementation, we seem to declare several memebers such as "precision, stringCache" as "volatile". Even though volatile read is only slightly slower than normal read, but volatile write is much slower than normal store/write. Intel folks found that by removing the volatile uses, they noticed some meaningful differences on some benchmarks such as derby inside SPECjvm2007.
Comments
EVALUATION After the changes to BigDecimal done under 7013110/7082971, many more of the variables in BigDecial were made final and thus were no longer volatile. The remaining uses of volatile are: In BigInteger: private static volatile Random staticRandom; private static Random getSecureRandom() { if (staticRandom == null) { staticRandom = new java.security.SecureRandom(); } return staticRandom; } In BigDecimal: private static volatile BigInteger BIG_TEN_POWERS_TABLE[] ... The array pointer is actually mutated and thus should be volatile for correctness. Closing as not reproducible against the current version of the code.
14-09-2011
EVALUATION I think more consideration needs to be given before removing volatile for these variables. These variables should be written at most once.
29-01-2008