feature request: instance independent lock detection

[DrScott]

Hello,

First of all thank you very much for this usefull tool.

I need to check a self made Job scheduler. Each job has assigned a
individual "JobInfo" object instance. The system needs to lock on
different monitor objects. Some are singletons, some are job specific.
There are also synchronizations on those singleton and JobInfo
instances.

With the current implementation of JCarder it is hard to check for all
potential deadlock szenarios. An example:

Thread 1:
lock on "Singleton@00001"
lock on "JobInfo@00001"

Thread 2:
lock on "JobInfo@00002"
lock on "Singleton@00001"

For the current detection algorithm this is not a potential deadlock
situation. In my case, the above szenario whould be a perfect example
for this situation:

Thread 1:
lock on "Singleton@00001"
lock on "JobInfo@00001"

Thread 2:
lock on "JobInfo@00001" <--
lock on "Singleton@00001"

(But this situation is very hard to achieve)
Now my request is, to be able to specify a list of classes which
should be checked not on instance level but on class level. Example
(with "JobInfo" specified in that list):

Thread 1:
lock on "Singleton@00001"
lock on "JobInfo" (in reallity @00001, but ignored)

Thread 2:
lock on "JobInfo" (in reallity @00002, but ignored)
lock on "Singleton@00001"

I experimented a little bit with modifications on

com.enea.jcarder.util.IdentityWeakHashMap.StrongKey
com.enea.jcarder.util.IdentityWeakHashMap.WeakKey

but i doesn't work very well. Sometimes it crashed in the analyzing
step, sometimes this step seems to be in an endless loop.

Now i hope on your knowledge.

Kind regards
Henning

[Ulrik Svensson]

Hello Henning!

I'm glad that you find JCarder useful and it is an interesting feature
that you suggest.

I don't have time to implement it right now and I think we would have
to find a convenient way for the user to configure which classes to
check on instance level and which to check on class level. Do you have
any ideas about that?

However, if you would like to make some small modifications to JCarder
for your special case, you might look at the method beforeMonitorEnter
in com.enea.jcarder.agent.StaticEventListener and maybe replace the
call to:

listener.beforeMonitorEnter(monitor, lockingContext);

with something like:

listener.beforeMonitorEnter(monitor.getClass(), lockingContext);

I have not tried it, but think it would work. The monitor parameter is
the object that is being synchronized on.

It should be possible to use instanceof, getClass().getName() or
checking the lockReference or the methodWithClass string variables in
order to have special cases for some specific classes.

You might also have to check that monitor is not null.

Good luck and please tell if it works or not!

/Ulrik