[External] : Re: Translation musings (was: Are templated string embedded expressions "method parameters" or "lambdas"?)

[Brian Goetz]

I am all for an easy-to-understand performance model.  But it is merely 
one quality of many that we are optimizing for, and it is absolutely, 
positively, *not* the high-order bit for how we expose the feature.  
There will be room for outlining the tradeoffs, but there is not room 
for "we can't allow case X strictly because it would be slower than case 
Y."  That's performance myopia, and even to the degree it would be 
acceptable, it is surely premature.  So let's move on.




On 11/2/2021 2:25 PM, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Brian Goetz" <brian.goetz at oracle.com>
>     *To: *"John Rose" <john.r.rose at oracle.com>
>     *Cc: *"amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>     *Sent: *Mardi 2 Novembre 2021 18:43:29
>     *Subject: *Translation musings (was: Are templated string embedded
>     expressions "method parameters" or "lambdas"?)
>
>     I think we need to redirect a bit.
>
>         I’m pointing out a different proposition:  *If* you need
>         static validation of a string, *then* you need something
>         constant about the receiver.  By constant I mean, very
>         specifically, “fixed no later than just before the first
>         execution of of the string template expression”.  The
>         “something constant” might be the type (some subtype of a
>         known “ST-Handler”), or it might be a constant value (e.g., a
>         static final field value).
>
>
>     And I'm saying something different:
>
>      - We never *need* static validation of the string.
>      - We never *need* an indy-based, multi-step translation.
>
>     Both of these are nice to haves, not must-haves; the goal is to
>     extract these when we can have them, not to restrict the feature
>     so that we can't use the feature if we can't produce them.
>
>     We are in deep danger of way over-rotating towards the
>     translation.  I would go as far as to say that if we always, now
>     and for the forever future, just translated with
>     "invokeinterface", it would *still* be a successful and popular
>     feature.  Do we want to do better when we can?  Of course.  Are we
>     willing to restrict the feature to the cases where can do so? 
>     Absolutely not.
>
>     It's really easy to get wrapped around the axle over cases like
>     String::format, and convince ourselves that this is the 99% use
>     case.  But this represents only a slice (yes, an important slice)
>     of the benefits we get from this feature. In many cases, the work
>     we'll do to translate the template (e.g., a CLASS."public class
>     Foo { ... }" policy) or after we translate the template (execute a
>     SQL query) completely dominates the performance profile.
>
>     So yes, let's optimize for the best-case translation when we can,
>     but let's not let that constrain what feature we deliver. 
>
>
> Templated strings can have a awful performance model if we are not 
> careful, and i don't think that relying on the user being careful aka 
> the C++ strategy is a good strategy.
>
> They have been enough lengthy discussions about the performance of 
> String.format() vs StringBuilder, i think it's reasonable to avoid to 
> create new performance pot holes when designing this feature.
>
> So static validation and being indy-based are a little more than just 
> nice to have, they are here to provide an easy to understand 
> performance model.
>
> regards,
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20211102/15787282/attachment-0001.htm>