known synchronized() failures?

Mon May 2 16:27:00 GMT 2005

Thomas Aeby wrote:
>In the meantime I have built gcc 4.0.0 and confirmed that the problem
>still exists, but now at least I have libraries with symbols .... a
>typical stack trace of the process consuming all the CPU (and is the
>one who is trying to get a lock) looks like
>>/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-20.test2/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/linuxthreads/restart.h:24
>/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-20.test2/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/linuxthreads/mutex.c:199
>../../../gcc-4.0.0/libjava/posix-threads.cc:192
>../../../gcc-4.0.0/libjava/java/lang/natObject.cc:929
>sfi/director/schedule/ParallelScheduler.java:539
>sfi/director/schedule/ParallelScheduler.java:471
>sfi/director/util/DirectorThread.java:105
>>and (at some other moment in time)
>>/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-20.test2/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/linuxthreads/spinlock.c:405
>/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-20.test2/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/linuxthreads/mutex.c:123
>../../../gcc-4.0.0/libjava/posix-threads.cc:112
>../../../gcc-4.0.0/libjava/java/lang/natObject.cc:929
>sfi/director/schedule/ParallelScheduler.java:539
>sfi/director/schedule/ParallelScheduler.java:471
>sfi/director/util/DirectorThread.java:105
>>
OK, if I'm not mistaken, based on the stack traces you posted, it looks 
like the thread is spinning in this loop:
 while ((he -> address & ~FLAGS) == (address & ~FLAGS))
 {
 // Once converted, the lock has to retain heavyweight
 // status, since heavy_count > 0 .
 _Jv_CondWait (&(hl->si.condition), &(hl->si.mutex), 0, 0);
 }
It doesn't make a lot of sense for this to be using 100% CPU, unless 
perhaps the arguments being passed to _Jv_CondWait are invalid and it is 
not actually waiting. Did you mean that this thread using all the CPU, 
or is the load split between this and other threads?
Another thing you could try is disabling hash synchronization in 
configure.host (you will need to also rebuild gcj and your application 
after changing this setting). This will the simpler, non-hash based 
synchronization code which should help determine if the bug is in libgcj 
or elsewhere.
Finally, I can't emphasize enough how useful a test case would be in 
tracking this down ;-)
Regards
Bryce