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

[Rachel Protacio]

Yeah, it comes out even with java -verison. But thank you for 
clarifying! Good otherwise?
Rachel

On 11/11/2015 4:42 PM, Coleen Phillimore wrote:
>
> _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
>>>
>