How to monitor SwitchPoint's impact?
Tom Rodriguez
tom.rodriguez at oracle.com
Thu Dec 1 13:21:40 PST 2011
On Dec 1, 2011, at 1:34 AM, Charles Oliver Nutter wrote:
> My recent explorations into Stephen B's perf degradation on JRuby have
> led me to an unfortunate conclusion: something SwitchPoint-related is
> responsible for the remaining slowdown.
>
> I had bugs I fixed, like the awful PIC-causes-repeat-rebinding issue
> or the heavy-class-mutation-never-stabilizes issue, but the last "fix"
> I found was to disable SwitchPoint-based call site invalidation
> entirely.
The upside of the push based invalidation of SwitchPoint is that the executed code runs quickly but the downside is that invalidation is expensive, possibly requiring a deopt and recompilation. If you suspect that's happening, try running with -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:+PrintCompilation and look for dependency_failed messages where type='call_site_target_value'. Any following make_not_entrant messages are probably caused by the invalidation of the SwitchPoint.
tom
>
> Now I'm not (yet) saying this is a perf issue in SwitchPoint itself.
> My problem is that it's very difficult to get any visibility into how
> frequently SwitchPoints are being invalidated (though I could
> instrument my own code, of course), or more importantly how
> drastically those invalidations are affecting performance. Does a
> single SwitchPoint invalidation happening repeatedly completely tank
> performance across the entire system? Does it require SwitchPoint
> invalidation that affects a broader surface area?
>
> I will continue investigating on my side. I suspect the problem is
> that there's just a handful of SwitchPoint locations that are
> repeatedly invalidated, but that those invalidations are having a
> drastic global impact. I'm not yet sure how to work around such a
> situation, where one bad apple is spoiling the whole bunch...
>
> - Charlie
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
More information about the mlvm-dev
mailing list