JDK 9 RFR of 6375303: Review use of caching in BigDecimal (original) (raw)
Brian Burkhalter brian.burkhalter at oracle.com
Tue Mar 4 00:14:15 UTC 2014
- Previous message: JEP 193: Enhanced Volatiles
- Next message: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello all,
This review request concerns this issue and proposed patch:
issue https://bugs.openjdk.java.net/browse/JDK-6375303 patch http://cr.openjdk.java.net/~bpb/6375303/webrev.00/
A review of the current code did not reveal anything clearly amiss in the nature of the the problems which instigated the original filing of this issue. Examination of the code did however suggest some code style and aesthetic improvements as well as a change to how one lazy initialization was implemented (here we go again ...).
Summary:
- clean up imports section
- add AtomicReferenceFieldUpdater-type constant for stringCache initialization
- change some existing static final constants to conform to Java coding style
- change name of some local variables so as not to hide instance variables of the same name
- add missing @Override annotations
- modify lazy initialization of stringCache in toString() to use AtomicReferenceFieldUpdater constant
- various other minor cleanup
Note that the performance of initialization of stringCache was measured for the extant double-checked locking approach, an AtomicReference, and the AtomicReferenceFieldUpdater and no significant degradation was observed for either of the latter versus the baseline for 1 and 4 threads. The updater has the advantage of adding only one object per class as opposed to one per instance.
Thanks,
Brian
- Previous message: JEP 193: Enhanced Volatiles
- Next message: JDK 9 RFR of 6375303: Review use of caching in BigDecimal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]