@SlowPath renaming discussion

Tue Sep 30 09:19:37 UTC 2014

The term “partial evaluation” is not widely used, which makes it a good fit - because all widely-used terms have lots of other meanings.
Truffle is a one-of-a-kind technology, so it can afford to introduce its own terminology.

The naming question is connected to the question of what this annotation is supposed to achieve and how it is supposed to be used.
IMO, the “skeleton” that is derived via partial evaluation needs to contain the parts that make certain things compile-time constant: node instances, (@Compilation)final node field values, profiles, loop counts (for @ExplodeLoop), call targets, types.
It also needs to include all places that use Truffle-specific intrinsics (invalidating compiled code, assertions, …).
This hard hard to do automatically, since asking the reverse question (what needs to be inlined to make this value constant?) is difficult.

So everything that can be @SlowPath should be - and Graal’s inlining should figure out the rest. But maybe I’m too optimistic :-)

- Lukas

On 29 Sep 2014, at 19:03, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> 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.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> - Christian Humer
>>>>>>> 
>>>>>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann <gero.leinemann at oracle.com
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd
>>>>>>>> recommend not to use the word "inline", as this is highly overloaded in
>>>>>>> the
>>>>>>>> Truffle/Graal context:
>>>>>>>> 1. inlining by AST rewriting (language level)
>>>>>>>> 2. inlining during/for PE (Truffle level)
>>>>>>>> 3. inlining done by the compiler (Graal/compiler level)
>>>>>>>> This confused - at least - me quite a bit when I started working at
>>>>>>> FastR.
>>>>>>>> What about @StopPE?
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> Gero
>>>>>>>> 
>>>>>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton:
>>>>>>>> 
>>>>>>>> What about something less Truffle specific? What about @StopInlining,
>>>>>>>>> @NotInlined or @DontInline?
>>>>>>>>> 
>>>>>>>>> On 26 Sep 2014, at 15:28, Michael Haupt <michael.haupt at oracle.com>
>>>>>>> wrote:
>>>>>>>>> Hi Christian,
>>>>>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer <
>>>>>>>>>> christian.humer at gmail.com>:
>>>>>>>>>> I would suggest these names:
>>>>>>>>>> @Boundary
>>>>>>>>>> @TruffleBoundary
>>>>>>>>>> @PartialEvaluationBoundary (or @PEBoundary)
>>>>>>>>>> 
>>>>>>>>>> Please add more suggestions and vote for whatever you think is best.
>>>>>>>>>> 
>>>>>>>>>> I'll try to first give my rationale for how I try to come up with a
>>>>>>>>>> name. It should express the intent of the annotation with regard to the
>>>>>>>>>> method it is attached to, at a level that is understandable by a
>>>>>>> Truffle
>>>>>>>>>> user.
>>>>>>>>>> 
>>>>>>>>>> Applying this, and note that this is purely my personal view, @Boundary
>>>>>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a
>>>>>>> method as
>>>>>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not
>>>>>>> focused
>>>>>>>>>> on the user).
>>>>>>>>>> 
>>>>>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted,
>>>>>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the
>>>>>>>>>> method is not exempt from compilation.)
>>>>>>>>>> 
>>>>>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but
>>>>>>>>>> the name is too long, how about @NoPE? ;-)
>>>>>>>>>> 
>>>>>>>>>> Best,
>>>>>>>>>> 
>>>>>>>>>> Michael
>>> 
>> 
> 