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

[Coleen Phillimore]

_at_poll_safepoint 1/0 is part of the message that comes out whether the 
thread is at the poll safepoint or not.

[0.272s][debug  ][safepoint] Thread: 0x00002b953c257000  [0x4674] State: _running _has_called_back 0 _at_poll_safepoint 0
[0.272s][debug  ][safepoint]    JavaThread state: _thread_new
[0.272s][debug  ][safepoint] Thread: 0x00002b953c234000  [0x4672] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
[0.272s][debug  ][safepoint]    JavaThread state: _thread_blocked
[0.272s][debug  ][safepoint] Thread: 0x00002b953c21b800  [0x4671] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0

I think that output is okay to check.

Coleen

On 11/11/15 4:37 PM, David Holmes wrote:
> 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
>>