The build process on Red Hat 9/Sun Fire V65x (2 cpu) always causes infinite loop in javac with the b42 VM or later. The same build succeeds on the same machine with setting the VM to b41.

Installing gcc 3.2.1-7a (J2SE release) didn't affect the symptom.

The build log file is in Attachments.

Here's gdb output with the running javac process.

javasoft> gdb /net/darkwing/export/ws/tiger.i18n/build/linux-i586/bin/javac 24829
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386- customer -linux-gnu"...(no debugging symbols found)...
Attaching to program: /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/bin/javac, process 24829
Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done.
[New Thread 1073972384 (LWP 24829)]
[New Thread 1096607424 (LWP 24842)]
[New Thread 1096083264 (LWP 24841)]
[New Thread 1095296960 (LWP 24840)]
[New Thread 1093199936 (LWP 24839)]
[New Thread 1091102912 (LWP 24838)]
[New Thread 1089005888 (LWP 24837)]
[New Thread 1088219584 (LWP 24836)]
[New Thread 1087433280 (LWP 24835)]
[New Thread 1086646976 (LWP 24834)]
[New Thread 1086593856 (LWP 24833)]
[New Thread 1086540736 (LWP 24832)]
[New Thread 1086487616 (LWP 24831)]
[New Thread 1086434496 (LWP 24830)]
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so...
(no debugging symbols found)...done.
Loaded symbols for /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/native_threads/libhpi.so...
(no debugging symbols found)...done.
Loaded symbols for /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/native_threads/libhpi.so
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/libverify.so...
(no debugging symbols found)...done.
Loaded symbols for /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/libverify.so
Reading symbols from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/libjava.so...
(no debugging symbols found)...done.
Loaded symbols for /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/libjava.so
Reading symbols from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/libzip.so...
(no debugging symbols found)...done.
Loaded symbols for /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/libzip.so
0xffffe002 in ?? ()
(gdb) where
#0  0xffffe002 in ?? ()
#1  0x40404c68 in os::Linux::safe_mutex_lock(pthread_mutex_t*) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#2  0x403ebea4 in Mutex::lock_without_safepoint_check() ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#3  0x4045e447 in SafepointSynchronize::block(JavaThread*) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#4  0x403edc9c in Monitor::wait(int, long) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#5  0x404d0d07 in VMThread::execute(VM_Operation*) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#6  0x40411954 in ParallelScavengeHeap::mem_allocate(unsigned, int, int) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#7  0x4014fd58 in CollectedHeap::common_mem_allocate_noinit(unsigned, int, Thread*) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#8  0x40258f17 in instanceKlass::allocate_instance(Thread*) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#9  0x4026b27a in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#10 0x4214388b in ?? ()
#11 0x42135a14 in ?? ()
#12 0x42135a14 in ?? ()
#13 0x42135aeb in ?? ()
#14 0x42135aeb in ?? ()
#15 0x42135a14 in ?? ()
#16 0x42135a14 in ?? ()
#17 0x42135aeb in ?? ()
#18 0x42135aeb in ?? ()
#19 0x42135a14 in ?? ()
#20 0x42135a14 in ?? ()
#21 0x42135aeb in ?? ()
#22 0x42135aeb in ?? ()
#23 0x42135aeb in ?? ()
#24 0x42135a14 in ?? ()
#25 0x42135a14 in ?? ()
#26 0x42135aeb in ?? ()
#27 0x42135aeb in ?? ()
#28 0x42135a14 in ?? ()
#29 0x42135a14 in ?? ()
#30 0x42135aeb in ?? ()
#31 0x42135aeb in ?? ()
#32 0x42135aeb in ?? ()
#33 0x42135aeb in ?? ()
#34 0x42135a14 in ?? ()
#35 0x42135a3f in ?? ()
#36 0x42135a3f in ?? ()
#37 0x42135a3f in ?? ()
#38 0x42133194 in ?? ()
#39 0x4027907c in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#40 0x40405128 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#41 0x40278eaf in JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
---Type <return> to continue, or q <return> to quit---
#42 0x4029a602 in jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#43 0x4028f788 in jni_CallStaticVoidMethod ()
   from /.a/darkwing/root/export/ws/tiger.i18n/build/linux-i586/lib/i386/server/libjvm.so
#44 0x08049b43 in strcpy ()
#45 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) 

set LD_ASSUME_KERNEL=2.4.1 to disable futex support in Linux kernel. 

  xxxxx@xxxxx   2004-04-27
----------------------------------------------------------------

b42 is the first Linux/x86 VM with ergonomics change (4962463). As mentioned 
in the description, JDK build can finish by using b41 (server) VM, or with
-client. It seems the problem is related to parallel GC. See comments for
details.

  xxxxx@xxxxx   2004-04-12
----------------------------------------------------------------
It looks like we have three workers (threads 11, 12, and 13) busily trying 
to steal and one worker waiting to get something to do (thread 14).  I've 
put thread stacks from all the threads in the attachments: ThreadStacks.text.

By mistake, I ran with -XX:+UseParNewGC, and it also hung.  I didn't get 
thread dumps on it, but it uses the same work stealing code.

I'm rerunning with -XX:+UseParallelGC -XX:ParallelGCThreads=2, to try 
to reduce the contention (or confusion!).  So far it seems to be working.  
Fewer threads may just be avoiding the problem.

I'm building a fastdebug build, so I can run with -XX:+TraceGCTaskManager 
and friends to see I can see a pattern.

It's weird that this happens only on Linux, or only on multprocessor 
hyperthreaded P4's, but this is the first one of these I've seen.  I 
know I've built the J2SE workspace on a dual processor hyperthreaded P4 
running Solaris (rather than Linux).  There could be a difference in the 
monitor code.  Also, the C++ compilers are different (e.g., volatiles).  
Or it could be a race that we just haven't seen on slower machines.

  xxxxx@xxxxx   2004-04-26
----------------------------------------------------------------
I can reproduce this bug with JDK-1.4.2 if I run with -XX:+UseParallelGC.  
So, as suspected, it's a problem with the work stealing, not anything 
that got introduced in JDK-1.5.0.  See the attached file
JDK_1.4.2-ThreadStack.text.

  xxxxx@xxxxx   2004-04-27
----------------------------------------------------------------
Hui says that missed nofications are a known symptom of RedHat 9.
There are no patches or fixes for it (since RH9 is EOL).  The only 
choice is to upgrade to RedHat Advanced Server 3.  Hui says he's 
successfully built the J2SE workspace on a dual processor hyperthreaded 
P4 running RedHat AS 3.0 (perf-v4.SFBay).

Hui notes (as I also observed) that if you grab one of these hung 
GC's with gdb and then release it, the collection finishes as it 
should.  (I see the process hanging shortly thereafter, but I haven't 
investigated it further.)

  xxxxx@xxxxx   2004-04-27
----------------------------------------------------------------