Hi @pron, the exception handlers generated by ASM when a yield call is placed just before a catch block include one with size 0 (startpc = endpc and the latter is exclusive, https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.3, so ASM's checker and JVM's verifier complain about it).
I think this is triggered by the try/catch splitting but I couldn't fix it there (I think it's not yet possible to check for empty try/catch blocks at that point as the code is not freezed) so I'm preventing it by adding a NOP after the yield call itself.
I don't think there'll be any performance impact but I'm not 100% sure as I don't know how JVMs treat NOPs; I guess they might choose to optimize them out or to translate them to actual CPU NOPs, perhaps depending on arch. and circumstances.
If you can figure out a way that doesn't need to add bytecode, f.e. somehow actually removing try/catch blocks that would result empty after instrumentation, it would probably be better.
Apart from the empty handler ASM generates, the handlers table looks strange in other ways (as well as the ASM-generated bytecode itself that contains several NOPs in this case) but I haven't further investigated; anyway I think It might be well worth to invest some more time and try to build a minimal case exhibiting this strange behavior and then submit it to the ASM guys.
Hi @pron, the exception handlers generated by ASM when a yield call is placed just before a catch block include one with size 0 (
startpc=endpcand the latter is exclusive, https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.3, so ASM's checker and JVM's verifier complain about it).I think this is triggered by the
try/catchsplitting but I couldn't fix it there (I think it's not yet possible to check for emptytry/catchblocks at that point as the code is not freezed) so I'm preventing it by adding aNOPafter the yield call itself.I don't think there'll be any performance impact but I'm not 100% sure as I don't know how JVMs treat
NOPs; I guess they might choose to optimize them out or to translate them to actual CPUNOPs, perhaps depending on arch. and circumstances.If you can figure out a way that doesn't need to add bytecode, f.e. somehow actually removing
try/catchblocks that would result empty after instrumentation, it would probably be better.Apart from the empty handler ASM generates, the handlers table looks strange in other ways (as well as the ASM-generated bytecode itself that contains several
NOPs in this case) but I haven't further investigated; anyway I think It might be well worth to invest some more time and try to build a minimal case exhibiting this strange behavior and then submit it to the ASM guys.