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

Martin Buchholz martinrb at google.com
Sun Mar 10 20:19:41 UTC 2019

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
Eliminate remaining performance penalty for using assert
still isn't fixed.

More information about the core-libs-dev mailing list