FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) SE Runtime Environment (build 1.6.0-rc-b104)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b104, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
generic Linux 2.6.18.1 (readily reproducible on Windows XP)

A DESCRIPTION OF THE PROBLEM :
The program demonstrating OOM with supposedly fixed bug 6457123 (same as 6457125, 6236036) leads to 100% CPU use and extreme VM unresponsiveness after a short time, regardless of heap setting. It is not entirely clear whether this is related to the previous bug or if something else is triggering GC amok, HotSpot confusion or something else. I tried to take a peek via stackdump, attach etc. but came up empty. The only point I could gather is that according to top there seemed to be no heap runaway, rsize seemed to be constant.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Simply run the examples from 6457123. The polling interval does not seem to matter.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The timeout queue polling should succeed and obviously not cause memory leak or VM panic.

ACTUAL -
VM lockup, extreme CPU use

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
see 6457123
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None - this bug makes timeout-based polling on BlockingQueue a total showstopper. Working around the problem with Thread.sleep is not acceptable.