Running GST in deamon thread in a loop in an agent on the renaissance benchmark leads to a segfault with the following stack trace:

```
V [libjvm.so+0xb2fb09] Klass::is_subclass_of(Klass const*) const+0x9 (klass.hpp:212)
V [libjvm.so+0xae1188] JvmtiEnv::GetStackTrace(_jobject*, int, int, jvmtiFrameInfo*, int*)+0xa8 (jvmtiEnv.cpp:1718)
V [libjvm.so+0xa95493] jvmti_GetStackTrace+0x113 (jvmtiEnter.cpp:1221)
C [libSmallProfiler.so+0x1486a] _jvmtiEnv::GetStackTrace(_jobject*, int, int, jvmtiFrameInfo*, int*)+0x52
C [libSmallProfiler.so+0x137ce] sampleThread(_jobject*)+0x78
C [libSmallProfiler.so+0x1388b] sampleThreads()+0x7b
C [libSmallProfiler.so+0x13950] sampleLoop()+0x5c
C)
```

A small reproducer can be found at https://github.com/parttimenerd/writing-a-profiler/tree/gst_bug , which can easily be turned into JTREG test.

The bug also happens when using GetAllStackTraces instead of GetStackTrace, but not in a Java agent calling `Thread.getAllStackTraces()`.

I reproduced the bug on x86_64 and Mac M1.