On Dec 13, 2011, at 12:31 AM, Rémi Forax wrote: > On 12/12/2011 05:38 PM, Charles Oliver Nutter 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 > > I agree. > > In my opinion, it's up to the language runtime designer to estimate > if it's a good idea to invalidate something at some point or not > because the runtime has more information than the VM. > > Moreover any throttle logic just make the API less predictable, > the throttle logic should be removed to help the designers > to easily predict the behaviour of their runtimes.
I'm fine with that. Currently there is no such logic. -- Chris > > Rémi > >> >> 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 > > _______________________________________________ > 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
