On 02/24/2013 12:35 AM, David Holmes wrote:
On 24/02/2013 6:08 AM, Alan Bateman wrote:
On 23/02/2013 19:39, Peter Levart wrote:
Hi Nils,
If the counters are updated frequently from multiple threads, there
might be contention/scalability issues. Instead of synchronization on
updates, you might consider using atomic updates provided by
sun.misc.Unsafe, like for example:
Most of the jvmstat counters are in VM and we only update a small number
of counters in the libraries. Even so, I think your idea is good as
further usage could potentially to be an issue, particularly
add/increment (which involves a get at this). So irrespective of Nil's
patch (which I think is now just a proposal to add a counter, not
original patch that Jason was commenting on) then we should take your
patch.
Before we rush down this path. Atomic operations on 64-bit types are
not supported natively on all 32-bit platforms. Atomic updates on
those platforms will degenerate into locking - which is the barrier to
implementing frequently used counters in the first place.
David
It's true, yes. I tried replacing atomic add with a read/CAS loop (like
it is coded in Unsafe as a fall-back for platforms that don't support
atomic add) and even on Intel 64bit such add performs on-par with
synchronized method as scalability is concerned. It's raw speed when not
contended is 2x the synchronized variant.
I also found out the "compatibility" gotcha when using "null" as the 1st
argument to Unsafe "double-register" addressing mode methods. On
platforms, that don't support 64bit CAS natively, the argument is used
as an Object reference to synchronize on to emulate the CAS instruction.
On Raspery-PI (armv6) for example, the patch causes a crash for that reason:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x40659f80, pid=2450, tid=1086497904
#
# JRE version: Java(TM) SE Runtime Environment (8.0)
# Java VM: Java HotSpot(TM) Client VM (25.0-b04 mixed mode linux-arm )
# Problematic frame:
# V [libjvm.so+0x3d3f80] ObjectSynchronizer::slow_enter(Handle,
BasicLock*, Thread*)+0x4
Regards, Peter
-Alan
