@SlowPath renaming discussion

[Christian Humer]

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.
> > > >>>>>>>
> > >
> > >
> >
>