JDK 1.3.1_06 hangs/deadlocks on Windows2000 SP3 server. This problem
is specific to server VM, and does not happen using -classic option.
Problem happens using jdk 1.3.1_02 through 1.3.1_06 (not yet sure
about jdk 1.3.1_08), and also happens with jdk 1.4.1_01 (primarily in
Weblogic environment).

Also problem does not happen excluding a particular method using
.hotspot_compiler file:
exclude weblogic/socket/NTSocketMuxer processSockets

Attached are multiple complete thread dumps:
threaddump_13106
threaddump_14101

From 1.4.1_01 thread dump:
One can see that "ExecuteThread-23" and "ExecuteThread-19" are
both waiting for a lock on <05536D98> (a weblogic.socket.IORecord),
which none of the threads are holding. Disabling hotspot optimization
for weblogic.socket.NTSocketMuxer.processSockets() prevented this hang.

"ExecuteThread-19" daemon prio=5 tid=0x17648900 nid=0x428 waiting for
monitor entry [17f0f000..17f0fdc0]
        at weblogic.socket.NTSocketMuxer.trigger(NTSocketMuxer.java:293)
        - waiting to lock <05536D98> (a weblogic.socket.IORecord)
        at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:209)
        at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:203)
        at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:60)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)

"ExecuteThread-23" daemon prio=5 tid=0x176F0BF0 nid=0x63c waiting for
monitor entry [1800f000..1800fdc0]
        at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:586)
        - waiting to lock <05536D98> (a weblogic.socket.IORecord)
        at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:42)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)


From 1.3.1_06 thread dump:
Concern is for the threads (0-14) in thread group called 'default',
other thread groups are unrelated and appear to be fine. For example,
  threads 7 and 8 are waiting on a monitor, and threads 6,5,2 appear to
be waiting on the same monitor, and we don't know who is holding the
  monitor. Disabling hotspot optimization for
weblogic.socket.NTSocketMuxer.processSockets() prevented this hang.


We are in process of procuring more troubleshooting information, to augment
above info, using WinDbg/VC++/etc.