Domanda

Come posso monitorare la memoria utilizzata da una DLL C nativa che viene chiamata da Java tramite JNI? Usando gli strumenti e le opzioni standard di monitoraggio Java posso vedere lo spazio di memoria Java, ma non riesco a visualizzare alcuna memoria utilizzata dalla DLL C. Java utilizza ~ 70 MB, ma l'attività in Task Manager mostra 200 MB + e, se possibile, mi piacerebbe vedere cosa c'è in quei 130 MB in più.

È stato utile?

Soluzione

Puoi monitorare l'heap nativo con i contatori nel montitor delle prestazioni. (perfmon32) tuttavia non verrà suddiviso per te in base alla DLL, anche jvm.dll verrà incluso qui.

La maggior parte degli strumenti di profilazione là fuori possono collegarsi a un processo e acquisire e tenere traccia delle allocazioni di memoria e delle deallocazioni. Ciò consente loro di speculare su dove siano le perdite. Uno abbastanza buono che ho trovato di recente quando ho cercato di rintracciare le perdite di memoria nel codice nativo che è stato chiamato da Java è Memory Validator

Altri suggerimenti

Hai provato a utilizzare Process Viewer per approfondire.

Se si ha l'origine della DLL, è possibile ricostruirla con le librerie di debug e possibilmente un tracker di allocazione mem - e eseguire il debug utilizzando il debugger Visual C ++ (è necessario indicarlo per utilizzare l'applicazione java).

Se non hai la fonte, le opzioni sono limitate.

Credo che farlo anche all'interno della DLL C non sarebbe molto semplice.

Per quanto ho capito, gli strumenti di monitoraggio Java standard raccolgono informazioni eseguendo una query sulla macchina virtuale, quindi anche se la memoria è nello stesso processo a meno che la macchina virtuale non sappia come ispezionare la libreria collegata dinamicamente, non sarà in grado per vedere qualcosa. Credo che dovresti utilizzare uno strumento esterno o apportare modifiche piuttosto massicce alla DLL per tenere traccia dell'utilizzo della memoria.

Bene, poiché la DLL non fa davvero parte dell'heap Java, penso che la lettura più accurata sarebbe quella di scrivere un piccolo programma di profiling (o un piccolo programma Java / JNI o ??C ++ / C #, ecc.) da importare e usa la DLL in un modo simile alla tua applicazione e non fare NULLA - usa semplicemente la DLL come fai tu - il profilo di memoria risultante di questa app di profiling dovrebbe essere una buona approssimazione al profilo di memoria della DLL.

Dovresti anche testare per vedere se esiste una forma di memoria statica o dinamica della DLL - prendi le misurazioni di memoria direttamente prima e dopo il caricamento della DLL per vedere se c'è un colpo una tantum di ~ 130 MB o se la memoria aumenta lentamente nel tempo.

Su Solaris / Linux, ho sentito che Sun Studio Collector / Analyzer è un ottimo strumento per questo, ma sei bloccato in DLL-land (o inferno DLL, per così dire)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top