RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object
David Holmes
david.holmes at oracle.com
Tue Aug 16 08:02:10 UTC 2016
Hi Harsha,
On 16/08/2016 4:08 PM, Harsha Wardhana B wrote:
> Hello,
>
> Please review and provide comments for fix for issue,
>
> https://bugs.openjdk.java.net/browse/JDK-8152589
>
> having webrev located at
>
> http://cr.openjdk.java.net/~hb/8152589/webrev.00/
These changes look quite good (though I have to admit I struggle to read
the lambda and stream code :) ).
Note that like many of these kinds of tests there is an issue with
WaitingThread because it does not wait in a loop and so is susceptible
to spurious wakeups. The way to fix that is to add a "notified" variable
and then do:
while (!notified)
wait();
and set notified before the notify().
Thanks,
David
> Fix details:
>
> 1. From nightly failures we see that LockThreadB was blocked on wrong
> object. We now do a repeated check with timeout if any given thread is
> blocked on expected object. It is possible that LockThreadB might still
> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is invoked.
>
> 2. The logs from lock free logger was never printed. It is not being
> printed.
>
> 3. Any time we see failure, thread stack is being logged. This helps us
> ascertain if failure is in test case or in the component.
>
> 4. Even though we had lock free logger, several ex.printStackTrace() was
> used which could be responsible for failure. It is removed.
>
> 5. There were several places where tests continue to ran even after
> failure (testFailed flag). That is fixed.
>
> 6. Couple of other minor refactoring.
>
> Thanks
>
> Harsha
>
More information about the serviceability-dev
mailing list