RFR(S): 8146096: [TEST BUG] compiler/loopopts/UseCountedLoopSafepoints.java Timeouts

[Vladimir Kozlov]

Simple use timeout to check for generated safepoint is bad idea. It is very inaccurate. At least you need to check call 
stack to see if it stopped in compiled method.
I would prefer to see WB new interface which would check that loop SafePointNode is generated during compilation of 
method. It will be precise.

And we need such tests to make sure a feature is working - we can't remove them.

Thanks,
Vladimir

On 1/19/16 4:50 AM, Vladimir Ivanov wrote:
> As an idea to improve the test: spawn a thread which executes the counted loop and then use WhiteBox.forceSafepoint() to
> trigger a safepoint.
>
> If the test times out, it means there's no safepoint in the loop.
>
> Also, it also simplifies the implementation - no need to spawn a child process, the check can be done in-process.
>
> Best regards,
> Vladimir Ivanov
>
> On 1/19/16 3:32 PM, Andreas Eriksson wrote:
>> Hi,
>>
>> Can I please have a review for the removal of
>> hotspot/test/compiler/loopopts/UseCountedLoopSafepoints.java.
>>
>> The test needs to do a loop that takes more than two seconds to execute
>> fully without doing a safepointing call. For this expensive atomic
>> operations were used. The problem is that on certain embedded platforms
>> they are too expensive, and the test times out.
>> The loop length could probably be reduced, and it should still work on
>> faster machines. However, the test is not very useful, so I think it's
>> better to just remove it to avoid future problems.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146096
>> Test to be removed:
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/d84a55e7aaf8/test/compiler/loopopts/UseCountedLoopSafepoints.java
>>
>> (I can create a webrev if you think it necessary.)
>>
>> Thanks,
>> Andreas