How to monitor SwitchPoint's impact?

[Rémi Forax]

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.

Rémi

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