If the bugger here is a repeatedly invalidated SwitchPoint then we (reads: I) should fix:
7087838: JSR 292: add throttling logic for optimistic call site optimizations I just don't have a good frequency-based logic yet... -- Chris On Dec 1, 2011, at 10:55 PM, Charles Oliver Nutter wrote: > 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
