@SlowPath renaming discussion

[Christian Humer]

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