JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Sergey Kuksenko]

Brian,
Could you share your benchmarks?

On 03/04/2014 04:14 AM, Brian Burkhalter wrote:
> 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<String>, 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
>

-- 
Best regards,
Sergey Kuksenko