The last day has been frustrating again. Whenever I instrument the runtime for synchronized blocks, I’m getting the VM error I’ve mentioned earlier, but only when the thread monitor is attached. If I let the program run unmonitored, it works. If a runtime is used without instrumentation for synchronized blocks, it works even with monitor attached.
That seems to indicate that there’s some interaction between the synchronized blocks and the way JPDA attaches to the slave VM that I don’t understand and that’s not documented. I’ve spent hours commenting out one thing or another, experimenting with the order of things to figure out what exactly makes the slave VM hiccup.
I still haven’t been able to figure it out, but it has something to do with suspending and resuming the execution of the slave VM. Grr.
Apparently the problem is caused by reading out the stack frames of the threads. Why this happens is a mysterium to me. It used to work before, when the runtime was not instrumented for synchronized blocks.
This might give me a chance to continue working, though. The stack frames aren’t necessary for the concurrent unit testing project, they would have been neat for a thread monitor, though.
All the work today made me realize that all the variables I am accessing from the thread monitor should probably be
volatile. I am worried that the HotSpot VM decides to optimize and drop fields that I need. That also means writing my own data structure implementation for the synchronization point list, something that makes sense anyway. An automatically resizing ring buffer could be useful.
Also, my new PC should be ready for pickup tomorrow. Unfortunately, I haven’t found anyone who can take me there tomorrow afternoon yet. A trusted friend volunteered her lunch break on Friday already, though. Thank you