JNI-performance - Is it really that fast?
Dave.Dice at Sun.COM
Tue Mar 25 20:26:40 PDT 2008
Following up on the other part of the your email ...
> I was asking because I did some benchmarking and (on my dual-core
> machine, with an obscure microbenchmark) the grabbing the AWTLock for
> a 1x1 rectangle takes almost as much time as the whole Xlib-processing
> + JNI-overhead.
> The code looks like:
> long xgc = validate(sg2d); //simple, pure Java method
> XFillRect(sg2d.surfaceData.getNativeOps(), .....); // native method
> 10mio 1x1 rect:
> 600ms native method commented out
> 850ms locking commented out.
> 1400ms locking+native method
> The numbers include all the code-path from Graphics.fillRect() up to
> As you can see locking (at least on my machine) is almost as expensive
> as the JNI-Downcall and the real work together. I used the
> The AWTLock was a java-monitor till JDK5 (not 100% sure), but was a
> victim of contention because it was used also from native code and
> sometimes from multiple threads (but I guess it was not heavy
> contended in most cases).
> IN JDK6 it was replaced with a ReentrantLock, some features like
> tryLock() where used to implement the new OpenGL pipeline ...
> performance also improved.
I recall discussions with the 2d folks on that topic.
>> In your case if the lock is ever shared -- that is, locked by
>> threads during its lifetime -- then biased locking probably won't
>> provide the latency reduction benefit you're after. The object will
>> likely become unbiased at some point. I suspect that sharing will
>> ultimately occur in your case, but be infrequent, correct?
> Exactly, the most likely scenary is that there is one rendering-thread
> which does million of locks, and a few other calls from native code
> (currently they upcall from C to lock the ReentrantLock).
> It could also happen that there are two or more active rendering
> threads at the same time, but this is not really common and a fallback
> to unbiased would be totally ok.
> Wouldn't be a BiasedLock something worth to implement, maybe with the
> possibility how fast/likely the Lock can become unbiased?
Unbiasing a lock, or more properly revoking its bias, can be
exceptionally expensive. In the extreme case it might require a full
stop-the-world thread rendezvous to ensure there are no races between
the revoking thread and the bias holding thread. (Ken's oopsla paper
describes some ways to mitigate that cost). While it's not strictly
fundamental to biased locking, the mechanism today also makes good use
of the fact that we know that synchronization -- enter and exit
operations -- are typically balanced ("last locked is first unlocked")
allowing the JVM to hide additional locking information on the
stack. A BiasedLock in the vein of ReentrantLock wouldn't have that
property, making the implementation a bit more complicated.
Generally, though, BiasedLock seems like a bet in the wrong
direction. If you suspect that biased locking would be a win then
for the most part you'd be better off with synchronized instead of yet
another special construct. (I worry too that things like BiasedLock
don't necessarily age well. Biased locking is purely a response to
processor-local CAS/cmpxchg latency. As processor vendors have turned
their attention to the issue the latency has shown relative
improvement so today's good idea might be tomorrow's legacy baggage
that needs to be towed around in perpetuity).
> However this really has not a lot prioritry to me ... I really should
> care about other things ... somehow I entraped into this when deciding
> the design of my XRender-Java2d pipeline. Sorry for all the traffic...
> lg Clemens
More information about the discuss