Possible compiler bug: continue is skipped after or-condition

[B. Blaser]

On Mon, 17 Feb 2020 at 18:35, Roland Illig <roland.illig at gmx.de> wrote:
>
> On 17.02.2020 15:45, B. Blaser wrote:
> > Roland,
> >
> > I believe the current behavior to skip line 7, as you described below,
> > looks correct.
>
> Why do you think so? I disagree with you. I think a breakpoint in line 7
> should be reached 2 times in this example. Once for the string "1a" and
> once for "1b". It's surprising that the breakpoint is skipped for all
> but the last term of the || expression.

By "looks correct", I meant "runs correctly"; debuggers and
breakpoints being another issue for which we have potential solutions,
as anticipated.

The problem is that javac massively optimizes branches (which
sometimes causes strong headache, see [1] for example) probably as
relic from before JVM bytecode compilers (JITs). So, I wouldn't be
surprised if you came across similar examples where unreachable
breakpoints can occur "here or there".

If Andrew is right (and I guess we can trust him) that JITs fully
optimize all branches (arguably starting at level 2, inducing then a
small latency since it takes effect), better would be to address this
as part of a holistic refactoring in this area as Maurizio explained,
probably reverting all the jump elision.

> > Maybe someone else could comment on this but I'm not sure the gain
> > would worth the pain as you could certainly put a breakpoint on line
> > 5.
>
> Not with the same effect. The breakpoint in line 5 is visited 7 times in
> this program, while the breakpoint in line 7 is only visited in the
> cases "1a" and "1b". Therefore, setting a breakpoint in line 5 is
> impractical.

Most debuggers support conditional breakpoints which is undoubtedly a
"practical" temporary workaround.

Bernard

[1] http://mail.openjdk.java.net/pipermail/compiler-dev/2019-March/013128.html