This seems to be a one-off but I found jtreg looping on my system. The looping thread seems to be ReadAheadIterator0 with this call stack:

"ReadAheadIterator0" #17 prio=4 os_prio=0 tid=0x00007fd09c001000 nid=0x3e09 runnable [0x00007fd0fdd52000]
   java.lang.Thread.State: RUNNABLE
        at java.util.WeakHashMap.get(WeakHashMap.java:403)
        at com.sun.javatest.regtest.TestProperties$Cache.getEntryInternal(TestProperties.java:348)
        at com.sun.javatest.regtest.TestProperties$Cache.getEntry(TestProperties.java:343)
        at com.sun.javatest.regtest.TestProperties.getTestNGRoot(TestProperties.java:106)
        at com.sun.javatest.regtest.RegressionTestFinder.scanFile(RegressionTestFinder.java:118)
        at com.sun.javatest.finder.TagTestFinder.scan(TagTestFinder.java:98)
        at com.sun.javatest.TestFinder.read(TestFinder.java:439)
        - locked <0x00000006c560a480> (a com.sun.javatest.regtest.RegressionTestFinder)
        at com.sun.javatest.TRT_TreeNode.processFile(TRT_TreeNode.java:1085)
        - locked <0x00000006c560a480> (a com.sun.javatest.regtest.RegressionTestFinder)
        at com.sun.javatest.TRT_TreeNode.scanIfNeeded(TRT_TreeNode.java:651)
        - locked <0x00000006c5c698f8> (a com.sun.javatest.TRT_TreeNode)
        at com.sun.javatest.TRT_TreeNode.getChildCount(TRT_TreeNode.java:125)
        at com.sun.javatest.TRT_Iterator$PseudoFrame.nextIndex(TRT_Iterator.java:918)
        at com.sun.javatest.TRT_Iterator.findNext(TRT_Iterator.java:613)
        - locked <0x00000006c57590f0> (a com.sun.javatest.TRT_Iterator)
        at com.sun.javatest.TRT_Iterator.nextElement(TRT_Iterator.java:183)
        at com.sun.javatest.TRT_Iterator.next(TRT_Iterator.java:205)
        at com.sun.javatest.util.ReadAheadIterator.readAhead(ReadAheadIterator.java:259)
        at com.sun.javatest.util.ReadAheadIterator.access$000(ReadAheadIterator.java:36)
        at com.sun.javatest.util.ReadAheadIterator$1.run(ReadAheadIterator.java:193)

Note that this is a personal build of jtreg (hg tip is 8d18f5093acf, so Nov 12, 2013, no changes). So not quite up to date but hopefully close enough that it doesn't matter.

The JDK running jtreg when this happened was the JDK under test (jdk8/tl) so latest jdk8 bits. The jtreg command used was:

jtreg \
      -jdk:$LAST_BUILD \
      -dir:$TOP/jdk/test \
      -exclude:$EXCLUDE \
      -a -v -ignore:quiet \
      -retain:fail -xml:verify \
      -ea -esa -timeoutFactor:3 \
      -agentvm -concurrency:4 \
      -vmoption:-Xmx256m \
      -vmoption:-DCompatibilityTest.disableNetwork=true \
      -vmoption:-XX:-UseLargePages \
:jdk_core :jdk_svc

On reflection then I probably should have captured more information before killing the job, next time I will grab a heap dump as this might reveal more. I have attached the full thread dump although this isn't too interesting as all other thread appear to be idle and just connected to agent VMs.