[External] : Re: JEP 411, removal of finalizers, a path forward.
Andrew Dinn
adinn at redhat.com
Tue Aug 3 09:11:12 UTC 2021
On 03/08/2021 02:30, Peter Firmstone wrote:
> Just curious, when using Agents, what are the recommendations for line
> numbers in code, for exceptions etc, how are these affected when
> instrumenting?
For Byteman I use ASM to inject bytecode sequences into methods without
any (significant) modification to existing bytecodes. ASM successfully
adjusts line number info to allow for the injected code without the need
for my agent to take any action.
I also add extra exception handling around injected regions and
propagate exceptions through enclosing regions to an outer handler. ASM
updates the exception table according to where the method visitor
notifies new try and catch region boundaries while retaining the regions
determined by existing notifications.
ASM provides mechanism for more complex cases. If you are rewriting
existing bytecodes or exception regions then you can use the ASM visitor
pattern to process and then renotify both line numbers and try catch
boundaries as you visit the bytecode stream. Of course, the logic of how
to do that can be as complex as (or more so than) the rewrite logic.
n.b. Remapping exception regions at load time is tricky for two reasons.
Firstly, you cannot afford to load exception classes to investigate the
exception class hierarchy without losing the opportunity to transform
the exception class's bytecode. So, you have to identify exception
shadowing by parsing the bytecode as a resource to establish exception
super relationships. Secondly, if you tinker with or inject extra try
regions you need to a) ensure they are properly nested inside containing
try regions b) make sure that new exception exit paths out of
synchronized regions include monitorexits.
regards,
Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
More information about the jdk-dev
mailing list