Hi Tristan,
Thanks for looking into this test failure.
listenerInvoked is accessed by multiple threads but not volatile. That
is certainly an issue. The test was written long ago prior to
j.u.concurrent. Can you also replace wait_or_notify with j.u.concurrent
(I think Semaphore or Phaser should do it)?
This is probably out of scope of this bug. I suggest to remove the
LowMemoryTest*.sh tests and replace them by adding @run in
LowMemoryTest.java.
Mandy
On 12/12/2013 9:12 AM, Tristan Yan wrote:
Hi Everyone
I am working on bug https://bugs.openjdk.java.net/browse/JDK-8029346
Root cause for this bug is in CMS mode; gc could happen when
AllocatorThread is allocating spaces. in that case. objectPool won't
be added two object arrays as it's supposed to have. Also in that
case. no clear and gc will be invoked in SweepThread. Which means
memory used is still bigger than threshold. According the java doc.
Subsequent crossing of the usage threshold value does not cause
further notification until the memory usage has returned to become
less than the usage threshold value. That's the reason why next
notification will never comes.
Suggested fix is making below change in doTask, make sure in every
loop two object arrays are added objectPool and gc will be invoked in
SweepThread.
change
while (!listenerInvoked) {
into
while (!listenerInvoked || mpool.getUsage().getUsed() <
mpool.getUsageThreshold()) {
Please let me know if you have any comments or suggestions.
Thank you
Tristan
