RFR: 8007806: Need a Throwables performance counter (original) (raw)

Peter Levart peter.levart at gmail.com
Sun Feb 24 10:31:46 UTC 2013

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

More information about the core-libs-dev mailing list