More Strange Behaviour in Tight Loops

In a previous article on the subject I pointed out the dangers of having code in tight loops especially their unintended affects on other threads running in the same JVM.

In this post I'll just point out a few interesting things I came across whilst testing the code in a tight loop.

Most Java developers, at some time, will have used the command line tools jps and jstack. jps is a command that let's you easily identify the Java processes running on your machine and their pids. When you have the pid of a Java process you can then use jstack to get a stack trace of that process. 

When I tried running running jstack on a process in a tight loop (see code here) I got this response:

Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding

I guess jstack needs the process to reach safepoint before being able to generate the stack trace.

Even more interestingly, when I tried opening the process in Flight Recorder (this is a really good profiler see here for a full write up) you get this dialog box:

Somewhat misleading - I have to say I spent quite a while puzzling over this before I realised that it was caused by trying to profile code in tight loop, and that all I had to do was add breathing space (see previous article) for Flight Recorder to start behaving again.

Summary 

I wonder whether having code in long running tight loops is actually a realistic scenario in which case my findings and issues will just be academic.  Or perhaps there might be scenarios, especially in failure cases, where this might actually be the case.  Certainly the behaviour of code in tight loops does shed some light on the way safepoints, GC, and monitoring tools interact with each other.