How to monitor SwitchPoint's impact?

[Charles Oliver Nutter]

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
<headius at 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.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