@SlowPath renaming discussion

[Mario Wolczko]

Makes sense.  Let's talk when you're around.  I have some ideas, but you may have already tried them, and their usefulness depends on some answers.  When are you in the office?

On Sep 26, 2014, at 10:57 AM, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:

> This prioritisation of core node partial evaluation and later (optional) Java level inlining makes the achieved performance for guest language operations more predictable. For small guest language methods, the inlining can still extend deeper beyond the @SlowPath, because it is only a “need not inline” annotation as opposed to a “must not inline” annotation.
> 
> Our experiments to avoid @SlowPath were of short duration as at that point in time too many things in the runtime were moving simultaneously. I think it might be possible to develop an algorithm that finds out those points via a static analysis. However, even then the guest language implementor needs to fully understand the algorithm in any case to not get bad performance surprises. A middle ground would be to provide an automatic analysis that verifies obviously missing @SlowPath annotations.
> 
> Current compiler optimizations such as inlining bring variability to the performance model of the guest language programmer. Without @SlowPath, we would bring additional variability to the performance model of the guest language implementor.
> 
> - thomas
> 
> 
> On 26 Sep 2014, at 19:23, Mario Wolczko <mario.wolczko at oracle.com> wrote:
> 
>> That's too bad.  There's as much to be learned from failure as there is from success.
>> 
>> On Sep 26, 2014, at 10:01 AM, Christian Humer <christian.humer at gmail.com> wrote:
>> 
>>> 
>>> On Fri, Sep 26, 2014 at 6:58 PM, Mario Wolczko <mario.wolczko at oracle.com> wrote:
>>> Do you have anything written up about the heuristics you tried, and the results?
>>> 
>>> Not that I know of. Somebody may correct me.
>>> 
>>> 
>>> - Christian Humer
>> 
>