Wow, thanks Andrew,
There's certainly some complexity there, I appreciate your guidance.
Regards,
Peter.
On 3/08/2021 7:11 pm, Andrew Dinn wrote:
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
