RFR: 8007806: Need a Throwables performance counter

[Peter Levart]

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
>>