Safepointing & Locking issue

[Nicolas Michael]

Am 12.07.2010 20:31, schrieb Tom Rodriguez:
> On Jul 9, 2010, at 3:02 AM, Nicolas Michael wrote:
>
>
>> I have just moved this application to server (with JDK7), and wow: We now see about 20x the throughput for this application than before! No needless safepointing any more! :-) And that also matches about our expectations we've had for running this app on this HW. So, this solves our problem!
>>
> For my own curiosity can you compare server but without the fix for the 6902182, so 6u20 or 7b82?  You've changed two things at once and I'm curious how much came from the fix itself.
>
Generally we see something as a 40% performance gain when going from 
Client to Server (for Java 6) for most of our applications. This 
particular application is a bit different and might have slightly 
different numbers, but "most" (almost all) of the performance gain is 
definitely due to the fix. Without that fix (and using Client), the 
application was spending 82% of the elapsed time in a safepoint 
(sun.rt.safepointTime) and 15% coming to a safepoint 
(sun.rt.safepointSyncTime) -- if I interprete those correctly. If I add 
those two up, there isn't much remaining time for doing useful work ... 
With the fix, this time is down to close to zero.

I also had a testrun with 6u20 and Server, which was slightly better 
than with Client, but not much (about 25% - 33%). It's a bit difficult 
to really compare those to the one with the fix, as for the testruns 
without the fix, it's not only the throughput that's bad, but also the 
response times -- and due to the resulting lock contention, the CPU load 
was rather spiky and unstable. Therefore, I would say, the throughput 
gain (for Server) was in the range of 10x to 15x comparing 6u20 and the 
latest JDK 7 (HS 19), plus improved response times as well.

I guess this huge performance increase might be something special for 
this particular application (lots of threads, lots of locks being 
accessed rather frequently and by multiple threads), so that 
safepointing became very expensive since it had to deflate "idle 
monitors" (that weren't that idle at all and were shortly after inflated 
again).

>> Just out of curiosity, are you going to fix that "slight penalty for the use of an agent" for client as well? ;-)
>>
> There are two issues.  We need to fix the places in client where it's still using VM_DeoptimizeFrame which is probably the major source of your slowdown.  I filed 6968367 for that issue.  The issue I was actually referring to is that even in server we still need to deopt in some cases to make jvmti exception notification work correctly.  Basically during the exception dispatch itself we may force a deopt to avoid double notifies.  I had intended to file a bug for that before and forgot so I've done it now.  It's 6968383.  I don't think anyone will be fixing that issue any time soon since it's lower in our priority than other things.  I'll fix the DeoptimizeFrame issue soon though.  Thanks!
>

Great, thanks!

Nick.