[jboss-jira] [JBoss JIRA] (JASSIST-78) Provide a way to detect that an instrumented method's code length exceed the 64KB limit

Provide a way to detect that an instrumented method's code length exceed the 64KB limit --------------------------------------------------------------------------------------- Key: JASSIST-78 URL: https://issues.jboss.org/browse/JASSIST-78 Project: Javassist Issue Type: Bug Environment: latest javassist from cvs head Reporter: Yanic Inghelbrecht Assignee: Shigeru Chiba Priority: Minor When using call site instrumentation, for example with ExprEditor#edit(MethodCall), it is possible to produce a class definition with a method whose class definition exceed the allowed code length. When such a class is actually loaded, it results in a java.lang.VerifyError (Illegal target of jump or branch). I have encountered some (degenerate) parsing methods whose code length is around 7000 before instrumentation and grows to over 64KB+ after instrumentation. It all depends on the amount of instrumented code that gets added of course (which is pretty minimal in my case, a try/catch block and an extra call). But other people have run into the same issue when instrumenting code that was generated for JSP pages, so it isn't all that exotic to encounter this in the wild. The problem is that there is no way to detect that the resulting code will break the 64KB limit (afaik). I've tried using getMethodInfo().getCodeAttribute().length() for the instrumented CtBehavior, but that number can not be used for this purpose. For example, one method reported a length of 7169 before instrumentation, and 55317 after instrumentation which is < 64KB. Yet it fails with a VerifyError when loaded into the JVM. I've also tried getMethodInfo().getCodeAttribute().getCodeLength() but that method reports even smaller numbers (resp. 4861 and 47769 for the same case as above) and is not suited for this purpose either. --- So this RFE asks to add some way to detect that a method will break the 64KB limit after it has been instrumented but before it is loaded into the jvm. Because there is a (clumsy) work-around, I've given this a minor priority. But I do think it would be a useful addition to javassist's feature set and allow users to write more robust and efficient instrumentation code. Thanks in advance for considering it Chiba.