Perfect, Tom, thanks.

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

Reply via email to