1

I am trying to build a system that takes periodic thread dumps on JVM processes so that they can be analyzed later in case of issues. I intent to cause minimum overhead to JVM while taking thread dumps. There are multiple ways for taking thread dumps and I have finally shortlisted 2 options - Either building a custom JVMTI agent or using ThreadMXBean. I was wondering is somebody has done an analysis on which approach would result in least JVM overhead? Or do they cause the same overhead?

Aniket
  • 21
  • 4
  • `ThreadMXBean` is the worst way to get thread dumps. It builds Java-level representation of stack traces, that's why it is slow and creates lots of garbage in the heap. JVMTI is a way better. However, even better is to ask JVM to make stack traces for you (see the linked answer). – apangin Dec 15 '16 at 23:32
  • Thanks for linking the question. Asking the JVM means waitibg for safe point, which in my (profiling) use case, not required. I have actually started looking at using perf tools or DTrace. – Aniket Dec 17 '16 at 09:20
  • If the primary purpose of stack traces is CPU profiling, than you might want to paraphrase the question. In the current form the question is indeed already answered. – apangin Dec 18 '16 at 01:56
  • As to profiling, I can recommend [this post](http://techblog.netflix.com/2015/07/java-in-flames.html). – apangin Dec 18 '16 at 01:56
  • Thanks. Really useful. – Aniket Dec 19 '16 at 14:55

1 Answers1

1

Depends a bit on your desired frequency of sampling, but in most cases it will have some impact and results will be biased. If you're up for JVMTI though, definitely take a look at Honest Profiler: https://github.com/RichardWarburton/honest-profiler

Nicholas
  • 15,916
  • 4
  • 42
  • 66
  • Thanks. It's good to know about safe points and AsyncGetCallTrace. This will be very useful for my research. – Aniket Dec 11 '16 at 12:29
  • `AsyncGetCallTrace` is good for profiling. However, it does not create thread dumps. I.e. `AsyncGetCallTrace` can get you a nice trace of an **active** thread, but it won't give a picture of all threads. – apangin Dec 15 '16 at 23:34
  • Agreed. My use case is mostly for profiling needs rather than getting a view of what all threads are doing at a particular instant. – Aniket Dec 17 '16 at 09:16