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

Brian Burkhalter brian.burkhalter at oracle.com
Sat Mar 22 01:01:17 UTC 2014

On Mar 20, 2014, at 12:49 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 03/20/2014 11:06 AM, Peter Levart wrote:
>> I was thinking about last night, for question: "Why is this
>> double-checked non-volatile-then-volatile trick not any faster than pure
>> volatile variant even on ARM platform where volatile read should have
>> some penalty compared to normal read?", might be in the fact that
>> Raspberry Pi is a single-core/single-thread "machine". Would anyone with
>> JVM JIT compiler expertise care to share some insight? I suspect that on
>> such platform, the compiler optimizes volatile accesses so that they are
>> performed without otherwise necessary memory fences...
> Yes, at least C2 is known to not emit memory fences on uniprocessor
> machines. You need to have a multicore ARM. If you are still interested,
> contact me privately and I can arrange the access to my personal
> quad-core Cortex-A9.

This is all very interesting but I would like to have closure so to speak on the patches that I posted. I think the questions still unresolved are:

1) Is a change of toString() necessary?
2) If #1 is “yes” then which version of the patch? (I think the most recent)
3) Are the other changes OK which are unrelated to toString()?



More information about the core-libs-dev mailing list