Oh, and for closure on this thread... The benchmark I was looking at did indeed invalidate too frequently. In this particular case, it was creating a new "singleton" class at runtime for every iteration, and the subsequent method definitions inside that class *each* triggered a SwitchPoint invalidation. I'm looking at changes now that will only create (and invalidate) SPs for invalidation after the SP has been bound into a call site. In other words, during interpretation or early in execution, I should be able to eliminate all SP use, and SPs will only come into play for steady-state, JITed Ruby code.
- Charlie On Mon, Dec 12, 2011 at 10:38 AM, Charles Oliver Nutter <head...@headius.com> wrote: > 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