How to monitor SwitchPoint's impact?

[Charles Oliver Nutter]

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.thalinger at 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.rodriguez at 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 at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev