Release java memory for OS at runtime.

Suppose I have a Swings Java Application,
I set the min Heap is 64MB and max Heap 2GB,
when the user start the application, the log in screen
will be displayed, at this time the app uses 64MB, rights?
From my Windows 7, I can see the java application is allocated 64MB
from the Memory Resource Monitor of the OS (actually, it's more than 64MB because JVM need some memory for it's task).

After that the user does some very heavy job then the application uses 2G.
Then the user log out the application, the log in screen is displayed again (the application is not closed yet). At this time the real memory that the application
is using 64MB (suppose this is the perfect memory management application),
but with the OS this application is still using 2G of RAM, I can see it on the resource monitor of the OS.

I want my application release the memory to the OS when it doesn't need to use a big memory. Can I do it at runtime with java app?

I mean when my application need to use 64MB of Ram,
then the OS gives it 64MB only,
when it need 2GB of ram then the OS gives it 2GB,
after that it need 64MB of ram then the OS gives it 64MB only again,
I don't want it waste 2000MB - 64MB = 1936MB.

The problem might be in deallocation of resources when the user logs out.. You see, when objects are created for a user, it gets memory on Heap, and during its lifetime, it will be referred to by some reference.... Now at some point of time, when we have no references pointing to that, then it is eligible for Garbage Collection, which is done by JVM...

So, you can make sure to free all the resources, and all temporary objects...

Even then, at the end of the day, it is solely dependent on the JVM, when it runs Garbage Collector...

This ultimately depends on the JRE you're using. Oracle's JRE for Windows (which I assume you're using) unfortunately doesn't ever return any memory it has allocated from the OS back. So even if everything is garbage collected (which is what R.Jain talks about), the JVM will keep (and eventually reuse) the memory it has allocated before. The only way to return the allocated memory to the OS is to terminate the JVM.

You might do this -- when the user logs out, you might stop the current instance of the JVM and start a new one. It might behave very similarly to your current behavior. Or, you might try to find out a different JRE, which would do this differently, but I'm not sure at all such a JRE even exist.

This ultimately depends on the JRE you're using. Oracle's JRE for Windows (which I assume you're using) unfortunately doesn't ever return any memory it has allocated from the OS back. So even if everything is garbage collected (which is what R.Jain talks about), the JVM will keep (and eventually reuse) the memory it has allocated before. The only way to return the allocated memory to the OS is to terminate the JVM.

You might do this -- when the user logs out, you might stop the current instance of the JVM and start a new one. It might behave very similarly to your current behavior. Or, you might try to find out a different JRE, which would do this differently, but I'm not sure at all such a JRE even exist.

Thanks Martin... I got to know something new (That returning of memory part)...

Lan Nguyen Thi wrote:I want my application release the memory to the OS when it doesn't need to use a big memory. Can I do it at runtime with java app?

Well, simplest is probably to reduce the 2Gb limit. Do you actually need that much, or is it simply a default?
Also, as far as I know, the system is perfectly able to swap out unused JVM memory, but I'm not sure of the exact interaction between system memory requests and the garbage collector. Rest assured that not all of that 2Gb is resident (ie, in core) though.

What reducing the upper limit will do is lessen the chances of the OS needing to swap, which can help, since swaps are generally quite slow. However, you do need to make sure that it offers sufficient "headroom" for the garbage collector. I'd suggest you take a look at this page and specifically this section for more information.

Basically: Don't panic about the 2Gb figure - too much - it's quite common for modern VM systems to run applications that total far more 'memory' than the machine actually holds. If you're still worried about it, you could add a System.gc() call after a user logs out, but you have to be careful; it could do more harm than good.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here

Ulf Dittmer
Rancher

Joined: Mar 22, 2005
Posts: 42958

73

posted Aug 12, 2012 08:47:14

0

you could add a System.gc() call after a user logs out

That might cause unreachable objects to be de-allocated earlier than might otherwise be the case, but production code shouldn't rely on System.gc() for anything.

Why doesn't logging out cause the app to quit? Is there an advantage in having the app stay open?

That might cause unreachable objects to be de-allocated earlier than might otherwise be the case, but production code shouldn't rely on System.gc() for anything.

Why doesn't logging out cause the app to quit? Is there an advantage in having the app stay open?

Well, if we say we can quit app when a user logs out, then we should ensure that each user session is issued a dedicated JVM instance.. And as the user logs out, we can just terminate the JVM for that user session.... If only this is not an overhead to system performance, I think it would be a better idea to follow this...

Ulf Dittmer
Rancher

Joined: Mar 22, 2005
Posts: 42958

73

posted Aug 12, 2012 10:41:49

0

I'm not sure what you mean by "terminate the JVM for that user session". Is this not a standard desktop app that will generally only be used by a single user, or at least a single user at any given time?

A while ago I played around a little and found that some Java versions did return memory to the OS, whereas others did not, and this depended on the Java version but not on the OS. But, as said, it was a while ago, I do not even remember the exact versions.

I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com