>shows up in the System monitor as using the
>ridiculous amount of >200mb virtual memory. The use of "physical
>memory" is much smaller.
That means it has a big virtual address space. It reserves disk swap
space for that. What really counts though is the working set size, how
much real ram it is normally consuming. Your "physical" memory is much
smaller. That's the one to worry about. A app not even computing,
totally swapped out still consumes its virtual ram even if it has no
real ram.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
mortenalver@gmail.com - 02 Dec 2005 02:48 GMT
> That means it has a big virtual address space. It reserves disk swap
> space for that. What really counts though is the working set size, how
> much real ram it is normally consuming.Your "physical" memory is much
> smaller. That's the one to worry about. A app not even computing,
> totally swapped out still consumes its virtual ram even if it has no real ram.
Thanks for your reply! So the point is that these 200mb can be
considered "free"? It still seems strange to me that the JVM would
reserve such large amounts compared to all the non-Java applications I
use - at the very least it makes the application *seem* extremely
memory-hungly, thus my current explanation problem.
Morten
Roedy Green - 02 Dec 2005 03:09 GMT
>Thanks for your reply! So the point is that these 200mb can be
>considered "free"? It still seems strange to me that the JVM would
>reserve such large amounts compared to all the non-Java applications I
>use - at the very least it makes the application *seem* extremely
>memory-hungly, thus my current explanation problem.
It is reserving space for example for threads that you may or may not
create. It is awkward to rearrange memory on the fly, so the JVM
parcels out the virtual ram for various tables when it first loads.
I wrote my own JVM of sorts (BBL Forth/Abundance). One of the
trickiest pieces of code in it was the way it could reallocate ram and
shift everything around on the fly. It had to be able to do this
right in the middle of running a program. It had to adjust all kinds
of pointers and counts. I use the analogy of changing the tires on a
car while it is moving. It is ever so much simpler to fix the
locations of all your critical system stuff when you first load.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Mickey Segal - 02 Dec 2005 04:11 GMT
> Thanks for your reply! So the point is that these 200mb can be
> considered "free"? It still seems strange to me that the JVM would
> reserve such large amounts compared to all the non-Java applications I
> use - at the very least it makes the application *seem* extremely
> memory-hungly, thus my current explanation problem.
Does the program start out by grabbing 200 MB or does it build up to it
after doing lots of things?
mortenalver@gmail.com - 02 Dec 2005 05:03 GMT
> Does the program start out by grabbing 200 MB or does it build up to it
after doing lots of things?
At once. As an example, I've shown below a program that runs a simple
loop. When I start this program (java Hello), immediately its entry
pops up in the System Monitor, showing a virtual memory usage of 254.1
mb.
Program:
public class Hello {
public static void main(String[] args) {
try {
while (true) {
System.out.println("Hello");
Thread.sleep(1000);
}
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}
}
> I've a feeling that this should be general knowledge, but I haven't
> been able to find any clear information on it.
I feel the same way.
> A small Java app, run on Linux (Ubuntu 5.10, kernel 2.6.12, Dell
> Latitude w/Pentium M), shows up in the System monitor as using the
[quoted text clipped - 10 lines]
> in a discussion on the web about "reserving" virtual memory, but this
> was AMD64-specific, so I'm not sure if it was relevant.
There are different measures of how much memory a program uses. In a
modern operating system it isn't a clear question.
To see the memory hogs you can run top. Just now it gave me (slightly
edited):
top 15:22:20 up 12 days, 21:58, 2 users, load average: 0.18, 0.09, 0.09
Tasks: 84 total, 1 running, 83 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.0% us, 0.7% sy, 0.0% ni, 57.8% id, 40.5% wa, 0.0% hi, 0.0% si
Mem: 247700k total, 243884k used, 3816k free, 828k buffers
Swap: 2097144k total, 274104k used, 1823040k free, 35396k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8283 tackline 15 0 339m 75m 8252 S 0.7 31.1 49:49.56 opera
2954 tackline 16 0 175m 70m 11m S 0.0 29.1 96:43.92 thunderbird
3152 tackline 15 0 51804 10m 3892 S 0.7 4.3 6:12.44 gedit
4051 tackline 17 0 189m 9.9m 1560 S 0.0 4.1 2:58.27 java
2754 gdm 15 0 20432 2996 2176 S 0.0 1.2 20:59.17 gdmgreeter
2693 root 15 0 141m 1476 964 S 0.0 0.6 26:31.51 X
2962 tackline 16 0 6440 1352 920 S 0.0 0.5 0:00.77 gconfd-2
2881 tackline 15 0 8520 1052 528 S 0.3 0.4 66:20.51 sshd
13292 tackline 16 0 2024 984 784 R 0.3 0.4 0:00.09 top
2882 tackline 16 0 6268 948 728 S 0.0 0.4 0:17.40 bash
See I've used 520000k or so (on a 256 MB machine, less 8 MB Intel
Extremely Crap Graphics), but with the collective memory use higher than
that. X is taking 141m, but all it is doing is showing a static login
screen.
There you can see java (JEdit) with 189m of VIRTual memory, but only
actually using 9.9m of RESident physical memory. You can get some
information on how it is allocated with pmap (or pmap -x) with the
process id (PID).
Some of the memory will be shared between processes, but counted each
time. For instance shared libraries and 6 MB of classes between Java
instances. For older (i.e. current) versions of Java, jar files will be
memory mapped. Memory mapped files may just exist on disc, not copied
into physical or swap memory.
Windows is probably dirtier. Some .Net shared libraries are considered
part of the operating system and so are not counted. The equivalent Java
files are counted for every process they are used be.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/