[concurrency-interest] LockSupport.park() still broken in Java 6u21?

David Holmes davidcholmes at aapt.net.au
Tue Sep 7 07:47:47 EDT 2010

Having threads pile up in await() is not the typical symptom of 6822370 -
which is certainly fixed in 6u18 and 6u21.

What we need to establish in this case is whether the blocking queue is
actually empty or not. Can you (relatively) easily reproduce this? On what
kind of system (CPU arch, number of CPUs, OS). Can you add a thread that
polls the queue size and so would report the queue's state when the other
threads have hung?

+UseMembar might help but won't in itself help identify the root cause.

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Attila
  Sent: Tuesday, 7 September 2010 9:25 PM
  To: concurrency-interest at cs.oswego.edu
  Subject: [concurrency-interest] LockSupport.park() still broken in Java

  Hi folks,

  at Twitter, we recently swapped out the Scala actor library's usage of
private copies of JUC LinkedBlockingQueue from our Kestrel message-queueing
system with proper JUC LinkedBlockingQueue[1]. This solved our immediate
problem, but now we seem to be experiencing what eerily resembles
"ReentrantReadWriteLock: threads hung when there are no threads holding onto
the lock". That is, our JVMs sometime hang, and we have all of our threads

    java.lang.Thread.State: WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x00002aaaeca02e20> (a
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)

  The bug 6822370 is claimed to have been fixed for Java 6u18; we're running
6u21 and still see this. The amount of traffic whizzing through these
systems is, as you can imagine, quite staggering, so we're bound to trigger
some very low probability race condition sooner or later.

  I was wondering - before I dig in deeper - if anyone else had a similar
problem on a JVM that has the 6822370 fixed (6u18 or later). We'll probably
proceed with trying running with -XX:+UseMembar to see if it takes the
problem away, but are worried about the throughput decrease it might incur.

  Thanks in advance for any information,


  [1] We did this 'cause the private copy in Scala 2.7.x was so old it still
had the <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805775> bug,
"LinkedBlockingQueue Nodes should unlink themselves before becoming garbage"
and it was killing GC performance in our VMs.

  twitter: http://twitter.com/szegedi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100907/30f8e87a/attachment-0001.html>

More information about the Concurrency-interest mailing list