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

[David Holmes]

On 12/11/2015 7:43 AM, Rachel Protacio wrote:
> Yeah, it comes out even with java -verison. But thank you for
> clarifying! Good otherwise?

Yes thanks Coleen - I was making an assumption about the intent there.

David

> 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
>>>>
>>
>