JDK 13 RFR of JDK-8220346: Refactor java.lang.Throwable to use Objects.requireNonNull

[Martin Buchholz]

We should stop discussing this here, but ...

On Sun, Mar 10, 2019 at 1:51 AM Peter Levart <peter.levart at gmail.com> wrote:

>
> In this particular case, this is not true. A lambda that captures no
> local or instance state is lazily constructed just once (when the lambda
> expression is 1st evaluated) and then it is used as a "local" constant.
>
> The performance model of this statement:
>
>      Objects.requireNonNullElements(defensiveCopy, i-> "stackTrace[" + i
> + "]");
>
> Is exactly the same as the performance model of this combo:
>
>      static class Holder {
>          static final IntFunction<String> messageSupplier = i->
> "stackTrace[" + i + "]";
>      }
>

I think that one is too expensive!
Initialization-on-demand holder idiom requires adding an entry to a jar
file and classload at runtime,
and causes some overhead in every single java program, even those that
don't load the class.
(one of the things improved by lambdas!)


> // ...and then in code:
>
>      Objects.requireNonNullElements(defensiveCopy, Holder.messageSupplier);
>
> The code in requireNonNullElements contains the same loop and the same
> "if" as the original loop and if statement, so the performance is the
> same as "that "if" statement". There's even a potential to introduce
> further optimization if such logic is extracted into a method as opposed
> to writing in-line loops with ifs (for example with some bulk comparison
> intrinsified logic) so there is even a potential to "beat" that "if"
> statement...
>

Users shouldn't have to extract code into methods ("outlining") to get the
JIT to optimize.
13 years later, the "easy" JIT bug
JDK-6445664
Eliminate remaining performance penalty for using assert
still isn't fixed.