DebugNonSafepoints
については、このフラグを設定する必要はありません。 debugInfoRec.cppを見てください:
static inline bool compute_recording_non_safepoints() {
if (JvmtiExport::should_post_compiled_method_load()
&& FLAG_IS_DEFAULT(DebugNonSafepoints)) {
// The default value of this flag is taken to be true,
// if JVMTI is looking at nmethod codes.
// We anticipate that JVMTI may wish to participate in profiling.
return true;
}
// If the flag is set manually, use it, whether true or false.
// Otherwise, if JVMTI is not in the picture, use the default setting.
// (This is true in debug, just for the exercise, false in product mode.)
return DebugNonSafepoints;
}
フラグが設定されていない場合はJVMTI CompiledMethodLoad通知が有効になっているとき、デバッグ情報がまだ記録されています。 can_generate_compiled_method_load_events
の機能をリクエストして、JVMTI_EVENT_COMPILED_METHOD_LOAD
の通知をオンにするだけです。
これは私のasync-profiler
プロジェクトでの処理方法とまったく同じです。
実行時に管理不能なJVMフラグを変更する安全な方法はありません。しかし、Linux上でこれを行うには醜いハックがあります。
libjvm.so
のベースアドレスを見つけるには/proc/self/maps
を読んでください。
- ELF format readerを使用して、ダイナミックライブラリ内の希望するシンボルのオフセットを検出します。
- このシンボルのアドレスに直接書き込んでください。
ここでは、このトリックではa sample codeです。
法的な解決策が見つからない場合は、@ apanginからの厳しいアプローチがあります。https://github.com/odnoklassniki/one-elf/blob/master/test/one/jvm/HotspotFlags.java libjvm.soをロードし、.so address + .symtab定数オフセットからフラグアドレスを計算します(ただし、VMコードの具体的なフラグの使用方法によって異なります) – qwwdfsad