Dispatch an exception backward?

[Liu, Xin]

Hi,

From Parse::merge_exception(int target_bci), I found that it is possible
to have 'target_bci < bci()'. It suggests that C2 may dispatch the
exception backward to an matched exception handler. Is it paranoid or
legitimate case?

void Parse::merge_exception(int target_bci) {
#ifdef ASSERT
  if (target_bci < bci()) {
    C->set_exception_backedge();
  }
#endif

I am not familiar with javac codegen. My intuition is that the exception
handler should come after the place it throws an exception. The class
files I read so far confirm this impression. From perspective of a
programming language, they are causal relationship. Fire alarm goes off
first (exception), call 911 later(exception handler). I feel that an
exception should always dispatch forward.

The reason I ask this because we would simplify ideal graph if we ensure
no exception is dispatched through backedge. First of all, an exception
handler is a block. C2 parser won't create phi node for the map anymore
after it has parsed the block. I think that's why we see
ensure_phis_everywhere() right before do_one_block().  It's the last
chance parser can create the phi node for the current map().

if (block->is_loop_head() || block->is_handler() || (has_irreducible &&
!block->is_ready())) {
        // Not all preds have been parsed.  We must build phis everywhere.
        // (Note that dead locals do not get phis built, ever.)
        ensure_phis_everywhere();

I understand the loopback case, but not exception case. I observe a phi
node as follows for an exception handler's map.

 1378  Phi  === 708 _ 42 42  [[ 706 1380 ]]
Oop:Example3$ConfinedScope:BotPTR * !jvms: Example3::confined_close @
bci:30 (line 51)

The EX handler is depicted as
B4(https://gist.github.com/navyxliu/1ded3fcd2f1563f290362cf03c9d13dc?permalink_comment_id=4440463#gistcomment-4440463
). Two exceptions are thrown from bci 13 and bci 17 of B1 respectively.
There is a dash line. It's the speculative exceptional edge generated in
typeflow analysis. We leave it empty after parser. I think 1378 Phi is
useless in this case. If my hypothesis that we don't have any exception
dispatches through back-edge is right, we can skip
ensure_phi_everywhere() for B4. Is it correct? I understand that C2 has
to deal with bycodecode from all languages. Maybe I am too
narrow-minded, but I am not aware of a programming language that writes
the exception handler first.

I am also curious about the constraint. Why do we refrain from creating
new phi node if the block has been parsed?  We insert a lot of nodes in
late inlining anyway.

thanks,
--lx

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB9D934C61E047B0D.asc
Type: application/pgp-keys
Size: 3675 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20230117/82d2fdcc/OpenPGP_0xB9D934C61E047B0D.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20230117/82d2fdcc/OpenPGP_signature.sig>