JDK-8225756 : [testbug] compiler/loopstripmining/CheckLoopStripMining.java sets too short a SafepointTimeoutDelay
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,13,14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-06-13
  • Updated: 2021-04-22
  • Resolved: 2019-11-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 14
11.0.12Fixed 14 b24Fixed
Related Reports
Relates :  
JDK-8220374 - C2: LoopStripMining doesn't strip as expected
Relates :  
JDK-8249890 - CheckLoopStripMining.java "fatal error: Safepoint sync time longer than 1200ms detected when executing SafepointALot."
Relates :  
JDK-8220761 - compiler/loopstripmining/CheckLoopStripMining.java crashed
Description
CompileCommand: compileonly CheckLoopStripMining.test_loop
[5.487s][warning][safepoint] 
[5.487s][warning][safepoint] # SafepointSynchronize::begin: Timeout detected:
[5.487s][warning][safepoint] # SafepointSynchronize::begin: Timed out while spinning to reach a safepoint.
[5.487s][warning][safepoint] # SafepointSynchronize::begin: Threads which did not reach the safepoint:
[5.488s][warning][safepoint] # "MainThread" #12 prio=5 os_prio=0 cpu=1750.00ms elapsed=2.77s tid=0x00000038ffd8d800 nid=0x8e3c runnable  [0x000000388ef0d000]
[5.488s][warning][safepoint]    java.lang.Thread.State: RUNNABLE
[5.488s][warning][safepoint] Thread: 0x00000038ffd8d800  [0x8e3c] State: _running _at_poll_safepoint 1
[5.488s][warning][safepoint]    JavaThread state: _thread_blocked
[5.488s][warning][safepoint] 
[5.488s][warning][safepoint] # SafepointSynchronize::begin: (End of list)
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=t:/workspace/open/src/hotspot/share/runtime/safepoint.cpp:927
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (t:/workspace/open/src/hotspot/share/runtime/safepoint.cpp:927), pid=11472, tid=45292
#  fatal error: Safepoint sync time longer than 500ms detected when executing SafepointALot.
#

The test sets a fixed SafepointTimeoutDelay of 500ms but that may be too short depending on the runtime environment. The thread being waited upon has actually reached the safepoint but we've processed the timeout code before checking again.

We have slow Windows machines where this can crop up.
Comments
Fix request (11u) I would like to downport this because the test is noisy on slow or loaded machines where it sometimes violates the SafepointTimeout. Applies cleanly.
20-04-2021
URL: https://hg.openjdk.java.net/jdk/jdk/rev/058d299b22b6 User: iignatyev Date: 2019-11-13 19:30:23 +0000
13-11-2019
http://cr.openjdk.java.net/~iignatyev//8225756/webrev.00 modifies the test to multiple SafepointTimeoutDelay and GuaranteedSafepointInterval by timeout factor, which should make the test more robust and, hopefully, solve the failures we see in our test environment.
13-11-2019
[~dcubed] Yes I saw that too, but as it specifically involves a crash there is obviously more going wrong in that case than just the safepoint timeout. I think any fix for this bug is just a simple test adjustment to account for "timeout factor" when setting the SafepointTimeoutDelay.
15-06-2019
[~dholmes] I also found this bug: JDK-8220761 compiler/loopstripmining/CheckLoopStripMining.java crashed
14-06-2019