@SlowPath renaming discussion

[Christian Humer]

Hi folks,

It seems that that a majority is in favor of @TruffleBoundary.
I will push the change today. Documentation will follow up.


- Christian Humer

On Fri, Oct 10, 2014 at 1:08 PM, Christian Humer <christian.humer at gmail.com>
wrote:

> I do not agree.  @CompilationBoundary fits the current terminology very
> well.
> For example: CompilerAsserts.compilationConstant(...),
> CompilerDirectives.inCompiledCode(), ...
> For these APIs we already use compilation as a word for Truffle
> compilation and partial evaluation.
>
> And behind compilation boundaries the code is treated the same way as if
> it would be executed just in the interpreter (in Truffle terminology).
>
>
> - Christian Humer
>
> On Fri, Oct 10, 2014 at 11:36 AM, Benoit Daloze <eregontp at gmail.com>
> wrote:
>
>> Don't let @CompilationBoundary win!
>> For me, it sounds as negative as @SlowPath (that is "slow", like there is
>> no more compilation after the annotation)
>> and new Truffle users might just think the same.
>>
>> - Benoit
>>
>> On 8 October 2014 18:30, Christian Humer <christian.humer at gmail.com>
>> wrote:
>>
>> > Thanks for all the suggestions.
>> > The discussion seems to have stopped, so I think its time to take this
>> for
>> > a vote now. (I won't count votes that were already posted)
>> >
>> > Here are the suggestions in the order of their submission:
>> >
>> > @Boundary
>> > @TruffleBoundary
>> > @PEBoundary
>> > @PartialEvaluationBoundary
>> > @TruffleInterpreted
>> > @TruffleInterpretOnly
>> > @NoPE
>> > @StopInlining
>> > @NotInlined
>> > @DontInline
>> > @StopPE
>> > @StopPartialEvaluation
>> > @CutoffPartialEvaluator
>> > @PartialEvaluationInvisible
>> > @NotExpanded
>> > @ExitPartialEvaluator
>> > @ExitPE
>> > @JavaCode
>> > @PlatformCode
>> > @CompilationBoundary
>> > @RuntimeCall
>> >
>> >
>> > My Vote:
>> > @CompilationBoundary +1
>> >
>> >
>> > - Christian Humer
>> >
>> > On Tue, Sep 30, 2014 at 6:29 PM, Andreas Woess <andreas.woess at jku.at>
>> > wrote:
>> >
>> > > 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.
>> > > >>>>>>>
>> > >
>> > >
>> >
>>
>
>