I just expanded the method to block instrumentation to the entire runtime, and unfortunately I’m getting an java.lang.IllegalMonitorStateException at sun.misc.URLClassPath.getLoader(Unknown Source). So something’s still wrong… 
Fortunately, the source code in question has been released under the JRL, so now I’m doing a “Java source” vs. “uninstrumented” vs. “instrumented synchronized blocks” vs. “synchronized methods converted to blocks and instrumented synchronized blocks” comparison… that’ll be fun.
Update
By stepping through the bytecode of the fully instrumented getLoader method I’ve found at least one thing that’s wrong. Since the actual code is released under the JRL, I’ll show simplified code here. The method contains a while loop that begins at line 1, and a continue statement:
1 2 3 4 5 6 7 8 | synchronized void getLoader() { while(<1st condition>) { ... if (<2nd condition>) continue; ... } ... } |
In bytecode, it looks roughly like this:
GeSHi Error: GeSHi could not find the language jvm (using path /home/dh_8dhf9b/concurrentaffair.org/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
This got instrumented and turned into bytecode similar to this:
GeSHi Error: GeSHi could not find the language jvm (using path /home/dh_8dhf9b/concurrentaffair.org/wp-content/plugins/codecolorer/lib/geshi/) (code 2)
The problem is the goto 1. When the code loops, the aload\_0; invokestatic; aload_0; monitorenter; aload\_0 invokestatic code is executed again. I don’t know if that’s what’s causing the exception, but it’s definitely wrong. It’s quite clear that the goto must be to the line after this code. It’s not clear to me yet if that’s always the case, though.
