Please review this fix of a bug in the ReferenceEnqueuePending test. The original code assumes the pending list processor will stay ahead of the test thread, so that the test's polling of the reference queue won't find it empty while there are still references on the internal pending list. That might not always happen though, possibly in part because the test raises the priority of its own thread to better compete with the pending list processor.
The fix is to use queue.remove with a large timeout, rather than queue.poll, to pull references from the queue until we've obtained all we expect to get. Then switch to polling to verify nothing unexpected in the queue without making the test delay for an expected timeout. If all of the references are (eventually) queued as expected then the timeout will never come close to expiring. I also looked at uses of poll() by other tests in the same directory, and didn't find any that looked like they might have a similar problem of failing because the pending list processor had not yet gotten around to dealing with a reference. CR: https://bugs.openjdk.java.net/browse/JDK-8072777 Webrev: http://cr.openjdk.java.net/~kbarrett/8072777/webrev.00/ Testing: Local testing of before and after test code, with an occasional sleep inserted into the pending list processor's loop to simulate a scheduling delay. With that delay, the original test frequently fails, while the modified test consistently passes.
