RFR: 8142437: SafepointTest.java is occasionally failing in JPRT (original) (raw)

David Holmes david.holmes at oracle.com
Wed Nov 11 22:12:35 UTC 2015

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:

atpollsafepoint 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 hascalledback 0 atpollsafepoint 0 [0.272s][debug ][safepoint] JavaThread state: threadnew [0.272s][debug ][safepoint] Thread: 0x00002b953c234000 [0x4672] State: atsafepoint hascalledback 0 atpollsafepoint 0 [0.272s][debug ][safepoint] JavaThread state: threadblocked [0.272s][debug ][safepoint] Thread: 0x00002b953c21b800 [0x4671] State: atsafepoint hascalledback 0 atpollsafepoint 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("atpollsafepoint"); 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

More information about the hotspot-runtime-dev mailing list