Thanks Michael,
I think I finally understand (finally). What got me going in the wrong
direction was assumming that it was the jvm hogging memory, when in fact
it's the classes. The reason I initially didn't think about classes was
the "dynamic loading" buzzword in java, but now that I think about it,
of course I was being stupid, since even with dynamic loading of
classes, the classes used are still going to take up a fair bit of space
(jdk1.1.7 classes.zip = ~8.8M!) and of course I was running a swing app
(swingall.jar ~2.2M).
I'll check out the mergemem sites you mentioned, since the all-in-1-jvm
approach is good but not perfect, so it always pays to know about
alternatives.
Thanks again (for having the patience to explain twice),
Maksim Lin.
Michael Sinz wrote:
>
> On Tue, 23 Mar 1999 13:42:46 +1100, Maksim Lin wrote:
>
> >Thanks for the info, but I'm still confused - even if top is lying to me
> >about individual jvm mem usage, I think it's telling the truth about
> >totol mem usage (at least thats my rough assessment by comparing it's
> >numbers to hearing the hard disk churn swapping mem in/out).
> >So why do I get these results ?:
>
> Did you read what a posted?
>
> ] Linux automatically will share "code" memory. That is, the same physical
> ] memory space will be used for all of the same physical code.
>
> ] Java has another thing that is not as easy to share: The classes.zip
> ] class files. These are loaded by the JVM into each JVM. This is not
> ] shared automatically. However, there is hack to the VM system called
> ] MergeMem that addresses this type of shared data too. I, personally,
> ] do not use it but I have seen it work. The web site is:
> ] http://das.ist.org/mergemem/
>
> Again, check out the MergeMem page. It explains how Linux shares code
> and in my message I explained how the JVM needs to load classes.zip
> and that is data and not code and thus is not automatically shared without
> something like MergeMem. (Look at the size of classes.zip and its unzipped
> size since the classes need to be unzipped to be used)
>
> Also, note that you may wish to run your Java with the non-AWT version
> which is a bit smaller - but that is mainly in the code size but it also
> means a bit less data space.
>
> Another MergeMem site has some examples as to JDK memory usage:
> http://www.complang.tuwien.ac.at/ulrich/mergemem/
>
> Michael Sinz -- Director of Research & Development, NextBus Inc.
> mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
> My place on the web ---> http://www.users.fast.net/~michael_sinz
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
Remember Darwin; building a better mousetrap merely results in smarter
mice.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
