@SlowPath renaming discussion

[Bernhard Urban]

let's make it with doodle: http://doodle.com/aszdcmw5v8avk7hv

-Bernhard

On Wed, Oct 8, 2014 at 6:30 PM, 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.
> > >>>>>>>
> >
> >
>
>