I'm still of the opinion that you shouldn't fix it, or at least shouldn't demote "noisy" call sites to never optimize. It's not common, but there are Ruby programs that may define a new class or method at runtime even at steady state. Not for every request, but occasionally. I don't like the thought that a "read mostly" call site that never completely settles down might get demoted and never optimized when it's still mostly steady.
The cost of updating call sites or switch points is part of the fun :) I consider that cost when I'm deciding how and when to update call sites, how and when to failover my own logic to a demoted version, and so on. I think it's my responsibility to deal with those costs, not yours... - Charlie On Mon, Dec 12, 2011 at 6:25 AM, Christian Thalinger <christian.thalin...@oracle.com> wrote: > 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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
