@SlowPath renaming discussion

[Andreas Woess]

I like @CompilationBoundary since "Compilation" is what we call it in other places, too: @CompilationFinal, neverPartOfCompilation, compilationConstant. We should be consistent here.
@RuntimeCall would be a good fit if it would mean always call, never inline -- which is not the case with @SlowPath. I think we should have both options anyway (maybe inline, don't inline), although that could simply be a boolean parameter to the annotation ("forced").

- andreas

On 2014-09-29 19:03, Thomas Wuerthinger wrote:

> I think we should avoid abbreviations if possible. While I agree that a Truffle language implementor needs to understand how the compilation actually works, I’m still unsure whether the term “partial evaluation” is the right one. It is well understood in an academic context, but it is not very intuitive.
>
> I’d like to propose two additional options:
> @CompilationBoundary
> @RuntimeCall
>
> The latter based on similar reasonings to @SlowPath. When implementing a language without Truffle, the equivalent effect to this annotation is achieved by emitting a call to the language runtime (either via bytecodes or via machine code) as opposed to emitting the logic inline. It should also make clear to language implementors the trade-off between using a runtime call (small code size, faster startup, slower peak) as opposed to emitting the logic inline (larger code size, slower startup, faster peak).
>
> Maybe we should collect all suggestions and make a majority vote ;).
>
> - thomas
>
>
> On 29 Sep 2014, at 02:46, Christian Wirth <christian.wirth at oracle.com> wrote:
>
>> Hi,
>>
>> Michael, I agree. We will have to give a good description of e.g. partial evaluation. Truffle developers need to understand the basic concepts to achieve high performance. Every Truffle developer should know what "PE" means and understand that concept.
>>
>> I vote for @PEBoundary.
>>
>> -- Christian Wirth
>>
>>
>>
>> Am 29.09.2014 11:29, schrieb Michael Haupt:
>>> Hi,
>>>
>>> @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly.
>>>
>>> Best,
>>>
>>> Michael
>>>
>>> Am 29.09.2014 um 10:39 schrieb Laurent Daynes <laurent.daynes at oracle.com>:
>>>
>>>> Alright, I'm sold.
>>>> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which
>>>> doesn't reflect the subtleties hidden behind it.
>>>>
>>>> Laurent
>>>> On 9/29/2014 10:30 AM, Lukas Stadler wrote:
>>>>> I’m a big fan of @PEBoundary - because:
>>>>> - it’s concise
>>>>> - it says exactly what it is (entry into this method is a boundary for partial evaluation)
>>>>> - it’s non-threatening (as opposed to stop, cut or exit)
>>>>> - “inlining” and “interpreted” are overloaded with too many different meanings, so I think we should avoid these terms
>>>>>
>>>>> - Lukas
>>>>>
>>>>> On 26 Sep 2014, at 18:01, Bernhard Urban <bernhard.urban at jku.at> wrote:
>>>>>
>>>>>> @ExitPartialEvaluator / @ExitPE
>>>>>>
>>>>>> fwiw, in pypy there's a @jit.dont_look_inside annotation.
>>>>>>
>>>>>> -Bernhard
>>>>>> On Sep 26, 2014 5:30 PM, "Christian Humer" <christian.humer at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I also agree not to use inline. I usually use "guest language inlining" for
>>>>>>> 1), "expansion" for 2) and "host language inlining" for 3).
>>>>>>>
>>>>>>> Will keep the suggestions flowing and will wrap up a vote later on.
>>>>>>>