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

[Peter Levart]

On 3/10/19 9:19 PM, Martin Buchholz wrote:
> We should stop discussing this here, but ...

... I think that we really should, but ...

>
> On Sun, Mar 10, 2019 at 1:51 AM Peter Levart <peter.levart at gmail.com 
> <mailto: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!)

Yes, I was trying to present the equivalence of performance models of 
warmed-up code. Inline lambda doesn't require any new entries in jar 
files, but it has some "initialization" overhead, that's true.

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

No, and this is not the goal here. The original  intent of Joe's patch 
is to reduce boilerplate while not worsening the (warmed-up?) 
performance at the same time. I think that the deciding factor about 
introducing such method should be the frequency of occurrence of such 
programming pattern in real code. Would introduction and use of such 
method be worth it on the global scale in the short run?

As it turns out, inspecting the code of java.base module, for example, 
shows that there are some places where such method could be of use, but 
not enough to warrant its introduction. There are quite a few places 
where an array or an Iterable is iterated and elements checked for 
non-nullness, but those loops usually contain other logic too, so It 
seems that this concrete "if" will stay where it is.

Regards, Peter

> 13 years later, the "easy" JIT bug
> JDK-6445664
> Eliminate remaining performance penalty for using assert
> still isn't fixed.