RFR: 8142437: SafepointTest.java is occasionally failing in JPRT

[David Holmes]

Hi Rachel,

On 12/11/2015 6:24 AM, Rachel Protacio wrote:
> As it turned out, there continued to be problems with how JPRT was
> running the tests.

Nothing to do with JPRT! :)

> I have deleted a bit more of the test, again not
> compromising its testing of the logging but allowing it to pass in
> inconsistent environments. Updated webrev:
> http://cr.openjdk.java.net/~rprotacio/8142437.01/

This removed condition:

-         output.shouldContain(" thread(s) to block");

is an inherently racy one. Whether the safepoint has to wait for 
"threads to block" depends on exactly what all the threads were doing at 
the time.

Now that you have removed the busy-spinning thread, this is also suspect:

  output.shouldContain("_at_poll_safepoint");

as there is no guarantee it will hit the safepoint because of a 
safepoint page poll. (Actually it is probably not guaranteed even with 
the spinning thread as we don't know when compilation will kick in.)

David
-----

> Thanks,
> Rachel
>
> On 11/10/2015 8:45 PM, David Holmes wrote:
>> Looks good to me too! (Not sure if you already pushed as trivial fix :))
>>
>> Thanks,
>> David
>>
>> On 11/11/2015 7:10 AM, Rachel Protacio wrote:
>>> Hello,
>>>
>>> Please see this small fix, which removes the flaky code. We know the
>>> safepoint logging system works - this is a compilation timing issue - so
>>> this change does not damage the integrity of the test. I also improved
>>> the class name and some comments.
>>>
>>> Summary: A method compilation causing a specific log message to print,
>>> is not always being compiled. The log message is not central to testing
>>> the safepoint logging functionality, so it should be removed.
>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8142437/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142437
>>>
>>> Thank you,
>>> Rachel
>