Classfile API Synchronous Stack Tracking in CodeBuilder

Adam Sotona adam.sotona at oracle.com
Thu Aug 25 10:04:28 UTC 2022


Oops, I missed the other thread about keeping the original order of handlers, so I’m taking the idea of synchronous streaming of ExceptionCatch back.

Adam


From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of Adam Sotona <adam.sotona at oracle.com>
Date: Thursday, 25 August 2022 8:18
To: Paul Sandoz <paul.sandoz at oracle.com>
Cc: classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Subject: Re: Classfile API Synchronous Stack Tracking in CodeBuilder
Yes, it should be documented.
Or maybe we can consider removal of handler label from ExceptionCatch and stream and collect it synchronously at the handler start position. Practically it defines handler block start, where try start and try end labels are just additional information.

StackTracker is actually not verifying content nor merging stack at   branch targets, however it indicates lost track by returning empty Optional. Handler block start usually follows "no-flow" instruction (goto, return, athrow...) - and it represents a (temporary) dead code (as the handler has not been yet declared), so the stack tracking is lost and stack method indicates failure by returning empty Optional.

Thanks,
Adam
________________________________
From: Paul Sandoz <paul.sandoz at oracle.com>

Requiring ExceptionCatch (and ExceptionCatchAll, not suppported) be reported before the target label is bound is awkward, but it's clear why. I think that would require documentation, and perhaps it should fail since it will otherwise report incorrect stack data?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220825/2fe7b097/attachment-0001.htm>


More information about the classfile-api-dev mailing list