How "evil" is GetPrimitiveArrayCritical?

[Y Srinivas Ramakrishna]

> * Clemens Eisserer:
> 
> > How problematic is the use of GetPrimitiveArrayCritical, and what
> > should be seen as a worst-case time for blocking? Does
> > GetPrimitiveArrayCritical has any negative effects except delaying
> > garbage collection for some time? Are there problems when many threads
> > do a lot of GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical,
> > even if they are short.

Yes, it may potentially stall GC by as long as it might take the threads
to release the critical section (although in all honesty, this could be
dynamically improved). Basically, the way things work now is that once
Eden fills up, and a JNI critical section is in use, further entries into
the critical section are delayed -- thus there is not a danger of starvation
or lock out. Thus, for example, in your case, GC
may be delayed by as much as 2 ms. During this time, allocation requests
may either go slow path (allocating out of the old generation), or in
extreme cases, get stalled until the JNI CS releases.

> > Can it disturb the CMS GC?
>

At least in current JVM's (i have not checked to see how far back this was
backported), CMS GC, since it's non-moving is not affected by JNI critical
sections (modulo that non stop-worl compaction can occur if there is a
concurrent mode failure -- in that case the allocating thread must stall
until the critical section is cleared -- this latter kind of stall is likely to be
much rarer than the slow-path direct allocation in old gen pathology that you might see
more frequently). Note that direct allocation in old gen is not only slow
in and of itself (a first-order performance impact) but can in turn cause
more tenuring (because of so-called nepotism), as well as slower subsequent
scavenges because of more direty cards needing scanning (both of the latter
being second-rder effects).


> It used to be pretty evil:
> 
> <
> <
> 
> But this bug has supposedly been fixed.  How is not clear from the
> public part.

Allocating threads (which are not themselves in JNI critical sections)
are stalled until the JNI critical section clears. If you want a
pointer to actual code, let me know and i can send a pointer.

-- ramki