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.