FULL PRODUCT VERSION :
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
SunOS x2001 5.10 Generic_127128-11 i86pc i386 i86pc

EXTRA RELEVANT SYSTEM CONFIGURATION :
Solaris 10, AMD Opteron 2356 (2 CPU quad-core 2312 MHz)

A DESCRIPTION OF THE PROBLEM :
during an execution of
java.util.concurrent.locks.Condition.await(timeout,
TimeUnit.MILLISECONDS) a thread hangs on Solaris/AMD x64 instead of being resumed after timeout is gone.

The environment is:
Java 1.6.0_12
Solaris 10
AMD Opteron 2356 2 CPU x Quad-Core 2312 MHz

The bug is NOT reproduced on the platforms:
Solaris / UltraSPARC T1
Solaris / UltraSPARC T2+
Solaris / UltraSPARC IV+
Linux / Xeon


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached test application on Solaris/AMD x64 platform.
In 2-20 minutes the bug should be reproduced with the message "JVM Bug found in 8 threads !!!!" in the log

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
after inocation of java.util.concurrent.locks.Condition.await(timeout,
TimeUnit.MILLISECONDS) a thread should resume
ACTUAL -
a thread hangs forever on java.util.concurrent.locks.Condition.await(timeout,
TimeUnit.MILLISECONDS)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
// one thread:

                        lock.lock();
                        try {
                            try {
                                while (queueSize == 0) {
                                    if (condition.await(AWAIT, TimeUnit.MILLISECONDS)) {
                                        conditionCount++;
                                    }
                                }
                                awaitCount++;
                            } catch (InterruptedException e) {
                                e.printStackTrace();
                            }
                        } finally {
                            lock.unlock();
                        }

// another thread:

            lock.lock();
            try {
                bufferPos = (int) (eventsCount % LONG_DATA_COUNT);
                if (queueSize == 0 && Math.random() > SIGNAL_PROBABILITY) {
                    condition.signal();
                }
                eventsCount++;
                queueSize++;
            } finally {
                lock.unlock();
            }

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
there is no workaround
Posted Date : 2009-03-24 07:28:28.0

N/A

The originator reports that the problem disappeared after updating to Solaris 10 update 7. The previously used Solaris version was S10u5. It is possible that this was caused by 6600939, which was fixed in S10u6.
Posted Date : 2009-06-09 05:16:00.0

The originator has clarified that the initial version was S10u6 so while 6600939 seemed a likely cause, that would appear not to be the case.
Posted Date : 2009-06-10 08:58:26.0

Reproduced on 
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)

This bug makes most of the java.util.concurrent package unusable in x86 production environments.

I dont know why this bug does not have a higher priority considering that the concurrent package was a major feature of java 5 and 6. 

I have reverted back to using backport-util-concurrent package.

What platform (OS, CPU) do you see the problem ?

I don't really understand why the state of this bug is "2-Incomplete, Need More Info" and why the priority is "4-Low".

What kind of information is not provided?

> Submitted On 21-APR-2009
> Michael_C_McMahon
> What platform (OS, CPU) do you see the problem ?

ok, one more time: the issue is still reproducible in the following environment:
Solaris 10 10/08 s10x_u6wos_07b X86
x2200 M2, AMD Opteron 2356 2 CPU x Quad-Core 2312 MHz, 16 GB RAM
Java 1.6.0_13 64bit

The source code of reproducible test, detailed environment , logs, jstack/pstack dumps are provided here:
http://forums.java.net/jive/thread.jspa?messageID=348291

About the priority: it is really a serious issue, always reproducible; the threads are blocked forever, hence the whole production system becomes out of service.

After applying the latest Solaris release from May 2009 "Kernel version: SunOS 5.10 Generic_139556-08, Solaris 10 5/09 s10x_u7wos_08 X86", the bug is not reproduced any longer.