RFR for JDK-8029346 LowMemoryTestConcMarkSweepGC.sh fails intermittently with timeout

Mandy Chung mandy.chung at oracle.com
Mon Dec 16 11:20:05 PST 2013


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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131216/e74cef50/attachment-0001.html 


More information about the serviceability-dev mailing list