> On May 19, 2021, at 6:43 AM, fo...@univ-mlv.fr wrote:
>
> . ..\ .
> This remember me something, tail call optimization is not the only
> optimization that avoid the stack to grow.
>
> If you have calls like
> g(a, () -> h(a, () -> f(a)))
>
> with 'a' being the same arguments, you can transform them to
> r1 = f(a)
> r2 = h(a, () -> r1)
> r3 = g(a, () -> r2)
>
> Here the calls can be at any location in the method, but the argument should
> not depend on the values computed by the function.
>
> The interceptors of Spring or CDI exhibit calls like this, they are using the
> same arguments so the result do not depend on the order of which the
> functions/interceptors are executed,
> but as far as i know, there is not implementation that do that transformation
> so when an exception occurs we see long stack traces.
>
> Asking for a friend, is this transformation have already a name ?
Interesting! No, I don’t recognize this transformation, and don’t have a name
for it. It reminds me a little bit of “code hoisting”, that is, moving code
earlier (typically so as to lift, or “hoist”, it out of a loop), because a
prerequisite for this transformation is that side effects in f, g, and h may be
reordered. In effect, f(a) is being computed earlier than normal, and
similarly for h. In fact, if g and h invoke their second arguments only
conditionally, then f(a) may be called even in situations where it might not
have been called in the original code.
—Guy