@SlowPath renaming discussion
Andreas Woess
andreas.woess at jku.at
Mon Sep 29 10:09:31 UTC 2014
Isn't this more of a documentation issue than anything else? No matter
the name, someone who hasn't used Truffle before most likely doesn't
know the meaning of the annotation and when and where to put it. You
have to be aware of Truffle's partial evaluation and its entry and exit
points.
That said, I'm happy with a new name if it is free of misleading
connotations and concise.
- andreas
On 29/09/14 11:29, Michael Haupt wrote:
> 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
>
More information about the graal-dev
mailing list