JDK-6348370 : java.math.BigInteger is *not* thread-safe immutable
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.math
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-11-10
  • Updated: 2014-02-20
  • Resolved: 2009-02-03
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b58)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b58, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]


A DESCRIPTION OF THE PROBLEM :
java.math.BigInteger is supposed to be immutable.

Unfortunately, this is true only for single-threaded applications.

java.math.BigInteger is *not* thread-safe immutable. Given that its main fields are not declared as final, an instance constructed in one thread can be seen differently (not immutable) in another. This is true ven if the instance is fully constructed in the first thread before passing a reference to it to the second thread.

This is discussed in chapter 17 of the Java Language Specification, 3rd ed. about the Java memory model.

Because it is claimed that java.math.BigInteger is immutable, it is natural for programmers to use it without concerns about synchronizing access to instances. This can lead to security breaches in cryptographic software by accessing the same instance in more threads that see different values.




REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Short-term, for the clients of the API: use synchronization to make use of BigIntegers.

Long-term, for JDK developer: Rewrite BigInteger making the fields final and ensuring that it is fully thread-safe immutable.

Comments
EVALUATION I believe with the work of 6622432 which is going to be in 6u14 and jdk 7, the thread-safety issue will be gone. First of all, in BigDecimal class, intVal is defined as "volatile" and it has the synmantic of montorexit which essntially flushes all the previous store to memory so that visibility will be guaranteed based on the new Java memory model. Second of all, in BigInteger, signum & magnitude fields are now defined as "final" which makes them perfect thread safe.
2009-02-03

EVALUATION Responding to a JDC comment on reproducing this problem, we have not been able to demonstrate this problem with the shipped jvm implementations. The problem may arise in some potential jvm implementation that *could* exist but currently does not.
2006-01-09