internal class synchronization may lead to deadlock

The VM should not lock classes using the same monitor that is used for synchronizing static methods. Doing so may lead to deadlock. The 1.0.2
VM handled this correctly by using two monitors for each class: one was
associated with the handle and the other with the ClassClass structure.
The ClassClass monitor was used for internal synchronization and the
handle monitor was used for static synchronization methods. In 1.1 the
class structure is in the Java heap and may be relocated so that it's
address cannot be used as a monitor key. Consequently, in the current
(i.e. 1.1.1) VM there is only a single monitor associated with the class
handle. There needs to be two. I've attached a test case to illustrate
the problem (I got this from a Usenet posting but Tim Lindholm said he's not
aware of the problem).