java using 200 MB of memory with only tws

Quote from alanm:

Thanks, skunk, for pointing that out.

If I recall correctly from studying Java's memory model a while back, "lazy programming" and "memory leaks" are generally not applicable to Java in the same way as C++. The nature of Java's model is that the programmer does not explicitly release memory as one does with free() and delete - rather that memory is automatically reclaimed by the garbage collector as needed and as defined by memory management params. Increasing -Xm lets the heap grow bigger until the GC has to run, which may increase performance by spending fewer resources on GC. Unless, of course, you are short of physical memory, in which case it will probably worsen things because the OS ends up having to use swapfile (on disk) to satisfy part of the memory allocation.

AFAIK, as long as the Total Commit Charge stays under Physical Memory (as shown in Task Manager), you're cool. If not, get more memory or reduce the value of -Xm by the amount it is exceeding it (assuming that it's Java, and not something else, that is sucking up a lot of memory).
More...

One further comment -

There are actually two garbage collectors. It seems that the one that releases memory back to the OS (ie calls free () or sbrk ()) is called MarkSweepCompact. It defragments the heap. It is 'expensive' to run, so is rarely called. But if the memory requirements of the application approach the -Xmx limit, it will be frequently run. This will adversely affect performance of the application, so setting -Xmx too small is not a good idea. Unless there is good reason not to, I would leave -Xmx to at least the IB setting.
 
Quote from dcraig:
There are actually two garbage collectors. It seems that the one that releases memory back to the OS (ie calls free () or sbrk ()) is called MarkSweepCompact. It defragments the heap. It is 'expensive' to run, so is rarely called. But if the memory requirements of the application approach the -Xmx limit, it will be frequently run. This will adversely affect performance of the application, so setting -Xmx too small is not a good idea. Unless there is good reason not to, I would leave -Xmx to at least the IB setting.

But don't you agree that, as expensive as GC might be, having the OS swap to disk is probably far worse? If you are silly enough to run a machine with 256Mb of memory, and use TWS at all with a setting of -Xmx256M, it will almost certainly cause Commit Charge to exceed physical memory, and cause swapping. Even a machine with 512Mb may not have enough memory to run with -Xmx256M.

For example, I have an older machine with 768Mb, running two older instances of TWS (with -Xmx128M) and a number of other usual trading things. It's sitting at 646Mb commit charge right now. Clearly, TWS cannot be set to -Xmx256M on this machine, with only another 120Mb headroom.
 
Im seeing less instabilty with a 256k max mem setting, but why is the VM Size Usage running up to 270 meg??? This reading from Task Manager.

Doesn't seem right at all.
 
There are other things besides heap that use memory. Heap is just the largest of them in this case. Probably leave yourself another 30Mb (+/- 20 Mb) headroom in addition to heap for total memory usage. It also gets more complicated since some of that VM space is not actually "dirty" and can be easily reclaimed by the OS, but that's way too much depth for most of us to deal with. Just buy more memory :)
 
POS software programs which always seem to cause more trouble than they're worth:

*Java
*iTunes
*Enternet 300
*Realplayer

Anyone have additions for this list?
 
Quote from alanm:

There are other things besides heap that use memory. Heap is just the largest of them in this case. Probably leave yourself another 30Mb (+/- 20 Mb) headroom in addition to heap for total memory usage. It also gets more complicated since some of that VM space is not actually "dirty" and can be easily reclaimed by the OS, but that's way too much depth for most of us to deal with. Just buy more memory :)
More...


I have *never* seen that VM usage tick down, so I'm not sure what you mean by reclaim. I'm not 100% sure, but my 'impression' is that the high reported usage does actually bog down things and create instability.

I mean , thats a HUGE amount of memory. What the blazes is in there? If its used, what's it used for, if it's not 'really' used, why is it being reported as used.
 
It's really not huge in the current environment of bloated libraries and the nature of Windows' memory model. This isn't the place for, and I'm not qualified to explain, the nature of this model. Sun and ORA do a decent job of explaining the Java memory model, and many publishers, including MSFT's Knowledge Base and MSDN, have decent writeups on Windows'.
 
Quote from Rearden Metal:

POS software programs which always seem to cause more trouble than they're worth:

*Java
*iTunes
*Enternet 300
*Realplayer

Anyone have additions for this list?
More...

Windows Media Player is my vote
 
You must log in or register to reply here.
Back
Top