Document interaction of profiler with DebugNonSafepoints about async-profiler

[Valloric]

This just bit me today. Please update the README to mention that -XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints is necessary if attaching to a running process.

[calvin1978]

@apangin , the README hadn't updated for -XX:+DebugNonSafepoints yet :)

[nitsanw]

For Honest Profiler there is no need to add the option as the presence of the agent on JVM load will auto enable it (the agent is loaded with VM not attached to running process). For Async-Profiler the parameter is required if the agent is attaching to an already running process.

[retronym]

Thanks for the clarification.

[lic9]

@nitsanw is '-XX:+DebugNonSafepoints' required? Async Profiler has alread enabled JvmtiExport::should_post_compiled_method_load(), which should be good enough to make the jvm to record non-safepoints:

./src/share/vm/code/debugInfoRec.cpp-82-static inline bool compute_recording_non_safepoints() {
./src/share/vm/code/debugInfoRec.cpp-83- if (JvmtiExport::should_post_compiled_method_load()
./src/share/vm/code/debugInfoRec.cpp:84: && FLAG_IS_DEFAULT(DebugNonSafepoints)) {
./src/share/vm/code/debugInfoRec.cpp-85- // The default value of this flag is taken to be true,
./src/share/vm/code/debugInfoRec.cpp-86- // if JVMTI is looking at nmethod codes.
./src/share/vm/code/debugInfoRec.cpp-87- // We anticipate that JVMTI may wish to participate in profiling.
./src/share/vm/code/debugInfoRec.cpp-88- return true;
./src/share/vm/code/debugInfoRec.cpp-89- }
./src/share/vm/code/debugInfoRec.cpp-90-
./src/share/vm/code/debugInfoRec.cpp-91- // If the flag is set manually, use it, whether true or false.
./src/share/vm/code/debugInfoRec.cpp-92- // Otherwise, if JVMTI is not in the picture, use the default setting.
./src/share/vm/code/debugInfoRec.cpp-93- // (This is true in debug, just for the exercise, false in product mode.)
./src/share/vm/code/debugInfoRec.cpp:94: return DebugNonSafepoints;
./src/share/vm/code/debugInfoRec.cpp-95-}

I think this is how Honest Profile works as well.

[apangin]

@lic9 The option is not needed if the agent is loaded at JVM startup (by using -agentpath option), but it is desired (though not required) if the agent is attached at run time. CompiledMethodLoad JVMTI event enables debug info, but only for methods compiled after the event is turned on.

[lic9]

@apangin Thanks for confirmation! That makes sense.

BTW, since Async Profiler does not have line number, '-XX:+DebugNonSafepoints' would only affect inlined method right? For example, method_A inlined method_B, and the hottest code is in method_B. Because method_B is inlined and the safepoint on method exit is omitted, Async Profiler will only show stack trace 'root/method_A' instead of 'root/method_A/method_B'.

[apangin]

@lic9 You're right: without DebugNonSafepoints there is a high chance that simple inlined methods will not appear in the profile.

[lic9]

@apangin would that also bias the results? Skimming the code, it seems like async profiler will drop samples whose _asyncGetCallTrace() returns negative num_frames and could not pop off top frame. This could happen to all Java stacktraces that have no decipherable compiled frame (no associated PcDesc at the specific pc or nearby pc due to missing _recording_non_safepoints option). In other words, only pc at safepoint or before safepoint could be recorded. Is that correct? If so it is better to show them as unknown or unwalkable instead of dropping them? Thanks!

[apangin]

@lic9 The absense of DebugNonSafepoints should not cause omission of samples. At least the enclosing Java frame can be recovered.
Even when something goes wrong, the samples with incomplete stack traces are counted and reported in summary.

[lic9]

@apangin I see. Those failed cases are recorded as 'Unknown (native/Java)' in plain text result but not shown on flamegraph. Thanks for the explanation!
But I think in that case, flamegraph is skewed. I built a jdk8 by making 'find_initial_Java_frame()' in src/share/vm/prims/forte.cpp always return false so no Java frame would be available from the async api. Flamegraph does not show anything about those unknown or unwalkable java stacks, and might mislead users to think that all time was spent in those native methods. Is it better to add those unknown/unwalkable counts to root and make a rectangle on top of it?

[apangin]

@lic9 Sounds reasonable. Can you please open a separate issue for this?

[lic9]

@apangin Sure I will open a new issue and create a patch. Thanks!

[apangin]

@calvin1978 Would you like to update it?

[jodzga]

How about this?
#152

[apangin]

@jodzga Thank you! I've merged the proposed addition.