Java（hotspot）verbose：gc输出在运行时在应用程序和进程中的使用

Question

Any way to hook on stdout of JVM currently running process or redirect stdout of JVM process to non file location?

I need verbose:gc output of JVM for my application, currently i can see this output in console but unable to store it in database or process it by any means, it invisible to running java application.

System.err System.out

Both are wrappers over natives, internal JVM output not passes here. Both can't see this output (ever if redirected or set to null, gc output shows in console).

Writing verbose:gc to file and then reading file not valid option due performance reasons and filesystem locks, checking hotspot sources not given any way to redirect output to nonfile location via JVM launch flags.

Also i was unable to get Process object of running JVM, there are no methods for this, also i was unable to find native that expose Process object, soo still no valid way to read this data.

Any clues about howto read verbose:gc in runtime?

Answer 1

Writing verbose:gc to file and then reading file not valid option due performance reasons and filesystem locks,

The cost of doing this is trivial compared to the cost of actually GCing. Unless you have a system which should never GC normally, I wouldn't worry about it. If you concern is that you can't read the file due to windows locks, you may have a problem (or you could use an OS like Linux which doesn't do this)

You should note that the GC output to a file is buffered, so it is not real time (but close enough for most use cases)

Reading the output programmatically is very difficult esp as it is written by a multi-threaded GC ie you get strange re-ordering of information.

I would consider getting the output of jstat which is designed to be read by a program though doesn't get as much detail.

Answer 2

You can get information GC pause information via JMX. It is not as full as GC logs, but will safe you from parsing. SJK tool is a CLI tool which could track GC events of JVM running processes. You could use it or use its code to build customized solution.

jstat is another option, but it exposes less information compared to JMX and its formatting rather misleading in case of CMS collector.

Problematically using PerfCounter API is third option ( jstat is using this internally). See sun.management.counter.perf.PerfInstrumentation class for details.