Sudden increase in native heap memory

Question

Hi all,
we are using JRockit 26.4 and currently configured with 1800MB heap on windows 2003 with /3GB switch.
We noticed that after the weblogic server is started the total memory (java heap + native memory) lingers around 2550 MB... (We monitored this using perfmon -> virtual bytes of java process)
after couple of days run, the native memory suddenly increased by 300 MB, taking the total virtual bytes to 2850 MB.
Do we know what could be the reason for such a sudden increase?
Thanks,
- Pritam.

Answer 1

I don't believe this is documented anywhere unfortunately, and it might vary depending on the exact JRockit release. But the key thing to watch out for is growth, regardless of which component it is. If you see that, post a question here and we'll find someone to tell you what the issue is...
That said, here's an example printout and some guesses from my side.
[JRockit] memtrace is collecting data...
[JRockit] *** 0th memory utilization report
(all numbers are in kbytes)
Total mapped                         ;;;;;;; 860976
; Total in-use                        ;;;;;;  89816
;;  executable                         ;;;;;   4400
;;;   java code                         ;;;;    384;   8.7%
;;;;    used                             ;;;    236;   61.6%
;;  shared modules (exec+ro+rw)        ;;;;;   8496
;;  guards                             ;;;;;    180
;;  readonly                           ;;;;;   3052
;;  rw-memory                          ;;;;;  78132
;;;   Java-heap                         ;;;;  65536;   83.9%
;;;   Stacks                            ;;;;   1976;   2.5%
;;;   Native-memory                     ;;;;  10619;   13.6%
;;;;    java-heap-overhead               ;;;   2056
;;;;    codegen memory                   ;;;    576
;;;;    classes                          ;;;   2048;   19.3%
;;;;;     method bytecode                 ;;    219
;;;;;     method structs                  ;;    277    (#5929)
;;;;;     constantpool                    ;;    788
;;;;;     classblock                      ;;     69
;;;;;     class                           ;;    143    (#443)
;;;;;     other classdata                 ;;    338
;;;;;     overhead                        ;;     91
;;;;    threads                          ;;;      6;   0.1%
;;;;    malloc:ed memory                 ;;;   1445;   13.6%
;;;;;     codeinfo                        ;;     60
;;;;;     codeinfotrees                   ;;     24
;;;;;     exceptiontables                 ;;      5
;;;;;     metainfo/livemaptable           ;;    243
;;;;;     codeblock structs               ;;      0
;;;;;     constants                       ;;      0
;;;;;     livemap global tables           ;;    135
;;;;;     callprof cache                  ;;      0
;;;;;     paraminfo                       ;;     30    (#506)
;;;;;     strings                         ;;    426    (#8402)
;;;;;     strings(jstring)                ;;      0
;;;;;     typegraph                       ;;     27
;;;;;     interface implementor list      ;;      5
;;;;;     thread contexts                 ;;      8
;;;;;     jar/zip memory                  ;;    497
;;;;;     native handle memory            ;;      5
;;;;    unaccounted for memory           ;;;   4493;   42.3%;3.11
---------------------!!!Total mapped means mapped virtual memory, eg the largest size the JVM can be expected to grow to. This is typically on the same order of magnitude as the Java heap size (Xmx).
Total in-use is the actual memory in use, this is the current "memory footprint" of your process.
executable refers to JIT compiled code, I believe.
Java-heap is the heap (duh).
Stacks should be the thread stacks (where local variables are stored).
classes is native memory used to store bytecode etc. If this grows, it may be because you are generating classes dynamically and they are not getting cleaned up because there are still live instances. Or maybe you're running with -Xnoclassgc.
threads can grow if you start a lot of threads and don't let them die.
Stuff under malloc:ed memory is mainly misc JVM metadata.
unaccounted for memory is...everything else. The most common leak involving unaccounted-for is native byte buffers (DirectByteBuffer).
-- Henrik