hash synchronization on linux

Jacob Gladish jake@gladish.info
Thu Jul 8 21:32:00 GMT 2004


I've suspected a problem with the hash synchronization for some time now
and decided that I might be able to reproduce the problem with a unit
test, and think that I have stumbled onto something. 

I've attached two classes that can be run against gcc-3.1 and very
quickly deadlock. To make this happen you must rebuild with a changed
hash_entry table size of 2. I suspected a race with bucket access (heavy
lock chain) so reducing the size increased the likelihood that I would
be able to reproduce this easily. This is being run on Linux SMP 2.4.18
(machine has two procs).

I've also included the backtrace of all the threads in this state. No
threads ever return from _Jv_MonitorEnter. I know the 3.1 release is
pretty old at this point, but I'm in the middle of building 3.4.1 with
the hash_entry table size shrunk to 2 and am going to see if it behaves
the same. I was also under the impression that the hash_synchronization
code has basically been untouched for a while.


Thanks
Jake

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: deadlock_stack.txt
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040708/c8b9ec66/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VectorThrasher.java
Type: application/octet-stream
Size: 1353 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040708/c8b9ec66/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HashSyncMadness.java
Type: application/octet-stream
Size: 915 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20040708/c8b9ec66/attachment-0001.obj>


More information about the Java mailing list