you are not doing anything wrong and JCarder is able to handle inner
classes as well as normal classes.
JCarder stores all graph edges in the database files. An edge
represents the acquiring of a lock while already holding one (or more)
other locks. The edge is directed, from the most recently taken lock,
to the new lock being acquired.
If a thread acquires a lock without already holding any other locks,
no edge will be created by JCarder. It is perfectly ok, since
acquiring only one lock at a time can never lead to a deadlock.
Nodes (locks) without any edges are not stored in the database files
for performance reasons.
In your example there is only a single lock (the Queue instance) that
is synchronized on, therefore no edges are created or stored.
I hope this is answering your question?
yes, maybe we should clarify exactly what information is included by
the "-outputmode all" parameter in the documentation.
Right now JCarder analyzes synchronized methods and synchronized
blocks, nothing else.
We have ideas about also analyzing the locks from
java.util.concurrent.locks and the synchronization performed in other
parts of the standard library.
I see two different approaches for that: Either instrument the
standard library itself or instrument the invocations from the user
code to the standard library. Both alternatives have different issues,
pros and cons.
We have also ideas about looking for data races, in addition to deadlocks.
I don't know when we will have time to work on this. Help is always welcome! :-)
On Feb 15, 2008 4:45 PM, Richard Achmatowicz