Per quanto riguarda DebugNonSafepoints che non hanno nemmeno bisogno di impostare questo flag. Guardate 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;
}
Se il flag non è impostato, informazioni di debug è ancora registrato quando JVMTI CompiledMethodLoad notifiche sono abilitate. Devi solo richiedere la funzionalità can_generate_compiled_method_load_events e attivare le notifiche JVMTI_EVENT_COMPILED_METHOD_LOAD.
che è esattamente come gestire nel mio progetto async-profiler.
Non esiste un modo sicuro per modificare i flag JVM non gestibili in fase di esecuzione. Tuttavia, c'è un brutto trucco per farlo su Linux.
- Leggere
/proc/self/maps per trovare l'indirizzo di base di libjvm.so.
- Utilizzare ELF format reader per scoprire un offset del simbolo desiderato nella libreria dinamica.
- Scrivere direttamente all'indirizzo di questo simbolo.
Ecco a sample code per questo trucco.
Se non hai trovato una soluzione legale, c'è un approccio cruento da @apangin: https://github.com/odnoklassniki/one-elf/blob/master/test/one/jvm/HotspotFlags.java che stabilisce l'indirizzo di ha caricato libjvm.so e calcola l'indirizzo flag dall'indirizzo .so + .symtab offset costante (ma non sempre funziona, dipende dall'utilizzo concreto di flag nel codice VM) – qwwdfsad