review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale

[Tom Rodriguez]

On Jan 27, 2012, at 11:25 AM, Vladimir Kozlov wrote:

> I change alias to hotspot-dev since it affects everyone.

Thanks.  I meant to send it to hotspot-dev but my auto pilot had other ideas.

> 
> In GC_locker::check_active_before_gc() move wait_begin initialization under Print* check since it used only under such checks.

Done.

> Could method check_active_before_gc() be called  from different threads concurrently? Does it need lock? Note that other methods have lock.

check_active_before_gc is only called at a safepoint:

  assert(SafepointSynchronize::is_at_safepoint(), "only read at safepoint");

And it's normally only called at the beginning of the collection in the VMThread.  The existing one had no locking and I don't think this changes anything in regards to the safety of it.

tom

> 
> Thanks,
> Vladimir
> 
> Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/7129164
>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg
>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale
>> Summary:
>> Reviewed-by:
>> The machinery for GC_locker which supports GetPrimitiveArrayCritical
>> maintains a count of the number of threads that currently have raw
>> pointers exposed.  This is used to allow existing critical sections to
>> drain before creating new ones so that a GC can occur.  Currently
>> these counts are updated using atomic all the time, even if a GC isn't
>> being requested.  This creates scalability problem when a lot of
>> threads are hammering atomic operations on the jni_lock_count.  The
>> count only needs to be valid when checking if a critical section is
>> currently active and when draining the existing sections.  The fix is
>> to make the count be computed as part of the safepointing machinery
>> and to only decrement the counters when _needs_gc is true.  In debug
>> mode the old count is maintained and validated against the lazily
>> computed count.
>> On a microbenchmark that stresses GetPrimitiveArrayCritical with many
>> threads and relatively short critical section it can more than double
>> the throughput.  This also slightly speeds up the normal
>> GetPrimtiveArrayCritical calls.  Mostly it's not easily measurable
>> with larger scale programs.
>> Tested with microbenchmark that stresses GetPrimtiveArrayCritical and
>> the crypto benchmarks of specjvm2008 on x86 and sparc.  I also ran the
>> java.io regression tests from the JDK.