- A Concurrent Affair - https://www.concurrentaffair.org -

Towards a Compact Deadlock Detector

On the way to a version of the deadlock detector that uses the compact representation, there are a few things I have to do:

  1. 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.
  2. Right now, there are only sync points generated just after a monitorenter and just before a monitorexit. 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 the monitorenter instruction.

This information is enough to recussitate the deadlock detector. There are a few more issues.

  1. I should probably check that the PC value that is reported is still correct, now that I have inserted code before the monitorenter instruction.
  2. 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.
  3. 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.

[1] [2]Share [3]