What would make a JVM memory size 1.9GB ?

Question

This is on Solaris 2.6, JDK 1.2.2_05a, JDK1.2.2_07, possibly JDK 1.3 (it crashed).
WLS 5.1, SP8. With inline_instrs_jit=0.
This is the [heap] segment shown by /usr/proc/bin/pmap. This is native heap, it is
NOT the Java Heap.
I know it could be the Type 2 db drivers - but I doubt it.
With JDK1.3 we set -XX:MaxPermSize=128m - it crashes after an hour.
One part of the application creates its own threads for some parallel processing.
Is this a known
problem with the JVMs?
Any help is much appreciated.
Mike Reiche

Answer 1

What is the 'Break difference' that the debug JVM shows? Is that the Java Heap? Or
is memory in the C Heap that is wasted by fragmentation?
============== C Heap Report ========================
mmap space 300515328
Committed space 95690752
Allocated space 34049316
Break difference 66060288
Breakdown by type:
ClassSpace 15252128
JITCompiledStackMaps 5277188
StackMap 1892672
Dependency 1856760
utf8_space 1854838
untagged 1783520
basicBlocksState 1664992
utf8_table 1055903
Class 811520
JITPrestub 610480
NearClass 531360
CardObjectTable 386048
JavaStack 257024
CheckingDone 200367
SummaryCardTable 193024
name_loader_cache_entry 65976
ScratchRecord 65548
basic_block_t 50896
IntfMethodTable 48960
stringTableOverflowRecord 46480
BitVectorElem 32768
ObjectMap 30724
ClassName 28407
Clinit 18752
Table_mem 18628
LoaderConstraintsTableEntry 11668
JITInlineByteCode 1928
LoaderConstraintsTableLoaderEntry 520
stateVecBuf 237
=====================================================
Total GC time: 2987981 ms
- Mike
"[email protected]" Mike wrote:
>
>
Aslo - GC[1] are taking way long (Debug JVM) - I'm used to seeing them taking
500
ms with the regular JVM. With -ms32m -m256m - I wanted GC[1] to run often
because
that has helped with other memory problems in the past - it doesn't work
so hot here.
GC[1] in 5514 ms: (38Mb, 0% free) -> (38Mb, 69% free)
GC[1] in 6300 ms: (38Mb, 0% free) -> (38Mb, 65% free)
GC[1] in 7130 ms: (38Mb, 0% free) -> (38Mb, 64% free)
GC[1] in 6158 ms: (38Mb, 2% free) -> (38Mb, 62% free)
GC[1] in 6171 ms: (38Mb, 0% free) -> (38Mb, 65% free)
GC[1] in 6885 ms: (38Mb, 0% free) -> (38Mb, 64% free)
GC[1] in 7403 ms: (38Mb, 0% free) -> (38Mb, 61% free)
GC[1] in 689101:25:49 PM PST {218} - Evaluation is: true
GC[1] in 6545 ms: (38Mb, 1% free) -> (38Mb, 61% free)
GC[1] in 7459 ms: (38Mb, 0% free) -> (38Mb, 62% free)
GC[1] in 6861 ms: (38Mb, 2% free) -> (38Mb, 58% free)
GC[1] in 6090 ms: (38Mb, 0% free) -> (38Mb, 56% free)
GC[1] in 6413 ms: (38Mb, 0% free) -> (38Mb, 60% free)
GC[1] in 8230 ms: (38Mb, 1% free) -> (38Mb, 58% free)
GC[1] in 7649 ms: (38Mb, 0% free) -> (38Mb, 54% free)
GC[1] in 7912 ms: (38Mb, 0% free) -> (38Mb, 55% free)
GC[1] in 7696 ms: (38Mb, 1% free) -> (38Mb, 57% free)
GC[1] in 6543 ms: (38Mb, 1% free) -> (38Mb, 60% free)
GC[1] in 7036 ms: (38Mb, 1% free) -> (38Mb, 59% free)
GC[1] in 7483 ms: (38Mb, 0% free) -> (38Mb, 56% free)
GC[1] in 5132 ms: (38Mb, 1% free) -> (38Mb, 59% free)
GC[1] in 8186 ms: (38Mb, 0% free) -> (38Mb, 53% free)
GC[1] in 5691 ms: (38Mb, 0% free) -> (38Mb, 58% free)
GC[1]01:35:49 PM PST {575} - Evaluation is: true
GC[1] in 8176 ms: (38Mb, 0% free) -> (38Mb, 46% free)
GC[1] in 8463 ms: (38Mb, 0% free) -> (38Mb, 47% free)
GC[1] in 7342 ms: (38Mb, 0% free) -> (42Mb, 41% free)
GC[1] in 6920 ms: (42Mb, 0% free) -> (49Mb, 41% free)
GC[1] in 8610 ms: (49Mb, 1% free) -> (60Mb, 40% free)
GC[1] in 9581 ms: (60Mb, 1% free) -> (60Mb, 50% free)
GC[1] in 10514 ms: (60Mb, 0% free) -> (60Mb, 59% free)
GC[1] in 9865 ms: (60Mb, 0% free) -> (60Mb, 60% free)
GC[1] in 11323 ms: (60Mb, 0% free) -> (60Mb, 57% free)
GC[1] in 18768 ms: (60Mb, 0% free) -> (60Mb, 60% free)
GC[1] in 11147 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 7293 ms: (60Mb, 0% free) -> (60Mb, 42% free)
GC[1] in 9372 ms: (60Mb, 0% free) -> (60Mb, 53% free)
GC[1] in 8814 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 9695 ms: (60Mb, 1% free) -> (60Mb, 54% free)
GC[1] in 7309 ms: (60Mb, 0% free) -> (60Mb, 53% free)
GC[1] in 8713 ms: (60Mb, 0% free) -> (60Mb, 54% free)
GC[1] in 11955 ms: (60Mb, 0% free) -> (60Mb, 55% free)
GC[1] in 12685 ms: (60Mb, 1% free) -> (60Mb, 55% free)
GC[1] in 18906 ms: (60Mb, 0% free) -> (60Mb, 58% free)
GC[1] in 13333 ms: (60Mb, 0% free) -> (60Mb, 51% free)
"[email protected]" <[email protected]> wrote:
Rob -
Thanks for your attention -
We create lots of threads - up to five threads for each DB hit (i didn't
design it).
The multi-threading will be disabled/removed and tested later on today.
Both 'top'
and pstack show around 85 threads.
I've read articles on the bea newsgroups about WL hanging on to threadreferences
so that the threads could not be GC'ed, but it sounded more like a customer's
impression
of what might be going on than something from BEA engineering.
Right now we are running with the 1.2.2_05a 'Debug' JVM with -verbose:gc
-verbose:gc
-verbose:gc
JVMARGS=verbose_c_heap,inline_instrs_jit=0
Unfortunately, some of the code being tested is now broken and not being
excercised
today. I will keep you posted.
- Mike
Rob Woollen <[email protected]> wrote:
How many threads are you creating?
Each thread uses some memory (stack etc.), but 1.9GB would be a lot of
thread creation.
-- Rob
Mike Reiche wrote:
This is on Solaris 2.6, JDK 1.2.2_05a, JDK1.2.2_07, possibly JDK 1.3
(it
crashed).
WLS 5.1, SP8. With inline_instrs_jit=0.
This is the [heap] segment shown by /usr/proc/bin/pmap. This is nativeheap, it is
NOT the Java Heap.
I know it could be the Type 2 db drivers - but I doubt it.
With JDK1.3 we set -XX:MaxPermSize=128m - it crashes after an hour.
One part of the application creates its own threads for some parallelprocessing.
Is this a known
problem with the JVMs?
Any help is much appreciated.
Mike Reiche--
Coming Soon: Building J2EE Applications & BEA WebLogic Server
by Michael Girdley, Rob Woollen, and Sandra Emerson
http://learnweblogic.com