Currently, at least one test is timing out:

$ CONF=linux-x86-server-fastdebug make images run-test TEST=jdk/jfr/jvm/TestGetEventWriter.java

It times out only with C1 -Xcomp. It looks as if this loop is reduced to infinite one:

```
package jdk.jfr.internal;

...

public final class Utils {
    ...

    public static void verifyMirror(Class<?> mirror, Class<?> real) {
        Class<?> cMirror = Objects.requireNonNull(mirror);
        Class<?> cReal = Objects.requireNonNull(real);

        Map<String, Field> mirrorFields = new HashMap<>();
        while (cMirror != null) {
            for (Field f : cMirror.getDeclaredFields()) {
                if (isSupportedType(f.getType())) {
                    mirrorFields.put(f.getName(), f);
                }
            }
            cMirror = cMirror.getSuperclass();
        }
        ...
     }
  }
```

Unfortunately, that test is inconvenient to use as the bisection test, because it was only recently added. Luckily, other JFR tests fail as well with the same symptoms:

CONF=linux-x86-server-fastdebug make images run-test TEST=jdk/jfr/api/recording/misc/TestGetStream.java TEST_VM_OPTS="-Xcomp -XX:TieredStopAtLevel=1" JTREG="TIMEOUT_FACTOR=1"

That allows to bisect the hangup to JDK-8265711, which also makes some sense, as the code above calls `isSupportedType` -> `Class.getModifiers`.

While this reliably reproduces on x86_32, I believe the bug is actually generic.