How to monitor SwitchPoint's impact?

[Charles Oliver Nutter]

Perfect, Tom, thanks.

On Thu, Dec 1, 2011 at 3:21 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>
> 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
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev