Chuck and Chris,
Thanks for yor explanations,
Let me, try to summarize what I understand adding some extra info and ask my
questions.
Is following classifications true for memory usage of Java ? If not please
correct it.
A. Java memory usage when application is started as a windows service:
1. Heap memory
* objects
2. Non-heap memory
* PermGen (holds reflective data (meta-data) of the JVM itself, such as
class and method objects and static fields )
* JVM's itself ( Garbage collector, managing heap etc.)
* Java service wrapper dlls.
B. Java memory usage when application is with a batch file:
1. Heap memory
* objects
2. Non-heap memory
* PermGen (holds reflective data (meta-data) of the JVM itself, such as
class and method objects and static fields )
* JVM's itself ( Garbage collector, managing heap etc.)
________________________________
If I turn my first e-mail, in my example, java heap size was 512 MB, I did'nt
define PermSize parameter so application uses default value 64 MB. Sum of
PermGen and Heap memory usage smalller then 600,980 KB which I see on Task
Manager. Can you explain the reason of this difference?
Heap PermGen
512 MB + 64 MB = 576 MB = 589824 KB < 600980 KB
Firs e-mail
"In our company, we are using apache tomcat as a windows service. We defined
jvm parameters "--JvmMs 512 --JvmMx 512" in service.bat. But application is
using 600,980 KB memory. I expect the application not to use more then 512 MB. "
Thanks again.
________________________________
From: "Caldarale, Charles R" <chuck.caldar...@unisys.com>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Wed, January 27, 2010 10:32:01 PM
Subject: RE: tomcat memory usage
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: tomcat memory usage
>
> What else goes into PermGen, other than java.lang.Class objects?
It varies by JVM level. In the original HotSpot implementation it was pretty
much just the instances of java.lang.Class. As things evolved, a lot of
class/method/field metadata migrated into PermGen from the C heap, pushed
there, I suspect, by the growing use and sophistication of JMX and JVMTI, as
well as making it easier for GC to clean up dead classes. AFAIK, none of these
secondary structures are directly visible to Java code.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
