[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