In production conditions, we often have lots of threads with deep stacks. When a user or automatic system asks for a thread dump, it may cause multi-second safepoints that induces long latencies.

Thread dump is a diagnostic feature, and it is expected it can cause ill effects. However, it would be good to investigate whether we have low-hanging fruits in code that can improve VM_ThreadDump performance without sacrificing a lot of readability and maintainability.

We have found an easy memory footprint improvement with JDK-8319876. This gives some confidence we might find easy things for throughput/latency of that op.

A simple reproducer (ManyStacks.java, attached) shows >1s safepoints on my Mac:

```
% build/macosx-aarch64-server-release/images/jdk/bin/java -Xlog:safepoint -Xmx2g -Xms2g ManyDeepStacks.java
1024 threads reached the depth
Ready
[0.502s][info][safepoint] Safepoint "ThreadDump", Time since last: 368845208 ns, Reaching safepoint: 28584 ns, At safepoint: 114393000 ns, Total: 114421584 ns
[1.769s][info][safepoint] Safepoint "ThreadDump", Time since last: 1124205708 ns, Reaching safepoint: 219708 ns, At safepoint: 141933417 ns, Total: 142153125 ns
[3.039s][info][safepoint] Safepoint "ThreadDump", Time since last: 1100251959 ns, Reaching safepoint: 235583 ns, At safepoint: 142219958 ns, Total: 142455541 ns
[4.342s][info][safepoint] Safepoint "ThreadDump", Time since last: 1047977334 ns, Reaching safepoint: 264166 ns, At safepoint: 134965834 ns, Total: 135230000 ns
[5.575s][info][safepoint] Safepoint "ThreadDump", Time since last: 1112830958 ns, Reaching safepoint: 94375 ns, At safepoint: 119930208 ns, Total: 120024583 ns
```