On the way to a version of the deadlock detector that uses the compact representation, there are a few things I have to do:
- Make sure that timed pulls still work. If the master application cannot pull data whenever it wants to, then the debugged application can go into deadlock and I cannot extract the last few sync points anymore.
- Right now, there are only sync points generated just after a
monitorenterand just before amonitorexit. In order to recognize a deadlock, I don’t only have to know what locks a thread is holding, I also have to know what locks a threadwants. That requires a sync point before themonitorenterinstruction.
This information is enough to recussitate the deadlock detector. There are a few more issues.
- I should probably check that the PC value that is reported is still correct, now that I have inserted code before the
monitorenterinstruction. - It might be nice to know where an object was created. I could add a special sync point that gets recorded when the object ID gets assigned. That may make it easier to identify what objects are involved in the deadlock.
- It would be nice to be able to get the line number from a PC value reported as part of a sync point, and in the case a deadlock is detected, a call stack for each thread would be nice. That was possible with the old deadlock detector with fat objects, but here it may be a little more complicated. We’ll see.
It seems like I have done tasks 1-3, and the code to report a sync point before a monitorenter instruction works, and the PC values are correct again now, too. Now I just have to rewrite the deadlock detector to work with the new compact data.
I also really need headless versions of all the apps so they can be run over X-less SSH.
