![]() It would make sense to perhaps bias towards sampling threads that are actually doing something as opposed to threads which spend all their time blocked. The JVMTI functionality allows you to query the list of current threads, you could sample all if there's less than a 100 and otherwise pick a random subset of 100 to sample. ![]() If you are building your own profiler it would seem sensible to set a limit on either quantities so that you can box your overheads. ![]() AFAIK, current profilers do nothing to help you here. This was clearly demonstrated in the previous post. ![]() The more threads your application has (think application server, SEDA architecture, lots of thread pools.), and the deeper your stack traces (think Spring and Co.) the longer your application will wait for a single thread to go round taking names and filling forms. Gathering full stack traces from all the threads means your safepoint operation cost is open ended.You can usually control the damage here by setting the interval longer, but this also means you will need a longer profiling period to get a meaningful sample count. A 5ms pause every 100ms will mean a 5% overhead (actual damage is likely worse than that) introduced by your profiler. It's not unusual to see a few milliseconds pause, but YMMV(depending on number of threads, stack depth, TTSP etc). It's instructive to set the -XX:+PrintGCApplicationStoppedTime and see what sort of pause time this introduces. Sampling profilers need samples, so it is common to set sampling frequency is quite high (usually 10 times a second, or every 100ms).This is bad for several reasons, some of which are avoidable: So this adds up to: setup a timer thread which triggers at 'sampling_interval' and gathers all stack traces.This amounts to the following JVMTI call: JvmtiEnv::GetAllStackTraces(0, &stack_info, &thread_count) AFAIK they also do not limit the depth of the stack collected. All profilers I looked into go for sampling all threads. You hit a global safepoint whether you are sampling a single thread or all threads (at least on OpenJDK, Zing is slightly different but as a profiler vendor OpenJDK is your assumption.).It follows that vendors who want their tools to work on ALL JVMs are limited to safepoint sampling. On Zing GetStackTrace to another thread will bring only that thread to a safepoint.). JVMTI offers only safepoint sampling stack trace collection options (GetStackTrace for the calling thread doesn't require a safepoint, but that is not very useful to a profiler.Generic profilers rely on the JVMTI spec, which all JVMs must meet: Well, I can sort of reverse engineer here from different solutions, or read through open source code bases, but instead I'll offer unsupported conjecture and you are free to call me out on it if you know better. How Do Generic Commercial Java Sampling Execution Profilers Work? They may account for much of the program’s execution time." - from Evaluating the Accuracy of Java Profilers, we'll get back to this article in a bit No execution time to methods that do not contain calls even though For example, let’s suppose our profiler can If a profiler does not do so, it will end up with bias in its profile. Second, the profiler should sample all points in a program run The program execution time to the code in which it took its sample Sample in the entire program run, the profiler will assign 100% of For example, if a profiler collects only a single To produce results that are comparable to a full (unsampled) profile,įirst, we must have a large number of samples to get statistically What do we need to hold for sampling to work? The data can be collected for a single thread or all threads at each sample.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |