Safepoint timeout in scimark?

[Roman Kennke]

I noticed that it sometimes takes up to 20 seconds to reach a safepoint
when running the scimark benchmark of SPECjvm2008.

It looks to me like scimark is just triple nested loops with finite
bounds, which translates to a CountedLoop, and safepoints are removed
unconditionally from counted loops if no outer loops needs them (which
doesn't seem to be the case). Therefore, a Java thread inside such a
loop can only reach a safepoint when it exits the outermost loop, and
this can take a while.

This seems like a rather serious bug to me. This prevents GC from
kicking in, deoptimizations, biased locking and probably some other
things from responding in a timely manner. Even just killing the app
with CTRL+C seems to be affected.

Is this a known issue? Any ideas how a proper fix looks like?

It can be reproduced with SPECjvm2008 like this:

java -XX:+SafepointTimeout -jar SPECjvm2008.jar -ict -ikv scimark

(If you have a very fast machine, you probably have to pass
-XX:SafepointTimeoutDelay with a value lower than 10000, I think
10seconds is much too generous anyway)


BTW, I tried -XX:+UseCountedLoopSafepoints, and it does indeed solve
the problem, but ran into other problems in SPECjvm2008's compiler
benchmarks:

java -XX:+UseCountedLoopSafepoints -XX:+SafepointTimeout
-XX:SafepointTimeoutDelay=2000 -jar SPECjvm2008.jar -ict -ikv compiler

.. fails with:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7adff09814, pid=23268, tid=23296
#
# JRE version: OpenJDK Runtime Environment (9.0) (fastdebug build 9-
internal+0-2016-07-11-184003.rkennke.jdk9)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 9-internal+0-2016-07-11-
184003.rkennke.jdk9, mixed mode, tiered, compressed oops, g1 gc, linux-
amd64)
# Problematic frame:
# V  [libjvm.so+0xfb0814]  PhaseIdealLoop::get_ctrl(Node*)+0x64



Best regards, Roman