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
