Fragment van het helpbericht van jmap :
λ > jmap
Usage:
jmap [option]
(to connect to running process)
jmap [option]
(to connect to a core file)
jmap [option] [[email protected]]
(to connect to remote debug server)
where
to print same info as Solaris pmap
-heap to print java heap summary
... stuff ...
-J to pass directly to the runtime system
U ziet dus dat de vlag -J argumenten
rechtstreeks doorgeeft aan de JVM.
Bekijk het jvm -helpbericht:
λ > java
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available (implies -server, only for x86_64)
Dus jmap -J-d64 vertelt jmap echt om
java -d64 te starten, met een 64-bits model in plaats
van 32-bits.
Als het proces waarop u jmap gebruikt geen 64-bit
JVM is, geeft u het argument -J-d64 niet door.
bewerken omdat ik veel jmap /
jhat heb gedaan om problemen op te lossen
Als u gecorrumpeerd zegt, bedoelt u dan dat jhat
daadwerkelijk een beschadigde heap-dump meldt? Of is het omdat je
heap dump te groot is om te lezen? jhat zal proberen
de hele dump in het geheugen te laden, dus je hebt minstens zoveel
gratis geheugen nodig als de grootte van de dump. Mogelijk moet u
-Xmx opgeven in jhat , evenals in
J-d64 om de heapruimte te vergroten.
Een veel beter alternatief dat ik gebruik, is Eclipse Memory
Analyzer Tool , dat wel selectief de heap-dump laadt dan alles
voor te laden. Het was veel beter op 6+ GB heap dumps dan
jhat voor mij was.