Here's a really dumb question that I can't get answered by googling. The Java version they call AMD64 Windows, does that refer to the 64 bit version of windows or what? Since I have an AMD 64 cpu. but the 32 Bit XP Pro, this does create confusion. I know the plain old window version will work fine, but wanted some clarification here.
Two other small suggestions. 1. I have found TWS to run better if I give it 512MB, so that's what i do. 2. if you want the garbage collection "spread out" more, there are several JVM parameters to affect that. I've never found that necessary, but maybe you do.
How do you do that? simply by changing the parameters line to: C:\WINDOWS\system32\javaw.exe -cp jts.jar;jcommon-1.0.0.jar;jfreechart-1.0.0.jar;jhall.jar;other.jar;rss.jar -Dsun.java2d.noddraw=true -Xmx512M jclient/LoginFrame C:\Jts correct?
Thats correct. But next week you're going to be starting a new thread that TWS memory usage is growing to 512MB. I thought you were trying to reduce the memory footprint...
how do i do this for my mac; the command line with the memory size usage included apparently dooesnt work for macs...i gotta use a different command to make it work. res, are u here? can u lend us a hand? tia
I'm not going to increase it. Just trying to understand the nuts and bolts for future reference. thanks for the reply.
I'm seeing instability with the new Java build 1.5.0_08-b03 Hard to say for sure but my system has locked up twice today since installing this .
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).