Give unused memory back to OS
My boss just shakes his hade when i tell him that you need to know how much memory a Java application can take (for setting the -Xmx option) and that the JVM doesn't return unused memory back to the operating system. This leads to Java applications being memory eaters and the only workaround is to constantly exit the application and restart it again. OutOfMemory exceptions occur every once in a while (because we have many concurrent threads that take up much memory for XML/FOP processing). Setting the -Xmx option to mutliple gigabytes doesn't help because at some point the computer is just occupied with swapping. I really wish that the JVM can give unused memory back to the OS.
My boss just shakes his hade when i tell him that you need to know how much memory a Java application can take (for setting the -Xmx option)
Run the application. See how much memory the application uses. Set the -Xmx option appropriately. It's just not hard.
the JVM doesn't return unused memory back to the operating system
True, although generally not a problem I find.
This leads to Java applications being memory eaters and the only workaround is to constantly exit the application and restart it again.
It's true that a Java application which acquires a large amount of memory during its run will not return that memory until the process terminates.
OutOfMemory exceptions occur every once in a while (because we have many concurrent threads that take up much memory for XML/FOP processing).
You'll get an OutOfMemory exception when you've used too much memory. What the hell else is it supposed to do ? OutOfMemory is the result of bad code (usually) or large data sets (sometimes).
Setting the -Xmx option to mutliple gigabytes doesn't help because at some point the computer is just occupied with swapping
Yes. This is true of all applications, not just Java ones. When you use more memory than you have memory, you risk thrashing.
I really wish that the JVM can give unused memory back to the OS.
That's got ****** all to do with most of the problems you've described.
Frankly, there's some validity in the argument that it ought to be possible to persuade a Java application to hand back to the OS the memory that it's no longer using. But there are arguments against it too.
That said, you've presented such a comprehensive picture of yourself as a complete idiot, that I have to assume that you're running zillions of copies of the JVM, parsing unnecessarily large data structures, or otherwise abusing the design process to cause this issue in the first place.
The JVM is not a magic tool. If your design sucks (for example, if your design requires you to treat an OutputStream as if it were an InputStream) then there's nothing it can do about it. Some common sense and flexibility is always required.
Dave.
You just accused me to be an idiot just because i post a request for a future JDK to solve the restriction of the JVM to
1.) release memory back to the OS
2.) take memory from the OS as it is requested from the application and thorw only an OutOfMemoryError, if the OS can't give memeory to the JVM - not if the fixed -Xmx parameter limit is reached.
I guess you have never wrote any large scale multi-threaded server applications with Java.Otherwise you would know that you can only estimate the amount of memory a running application might take. For many applications, you can't predict the exact (or almost exact) amount of memory they need. Of course we have these problems with one special server application as it can process quite some (predictable amount of) concurrent threads, that itself can can take up unpredictable space. The unpredictability is in the XML/FOP Processing as generic stored procedures can result arbitrary amount of data that produces an arbitrary amount of XML files, each with an arbitrary length; resulting in an arbitrary number of PDF files, each of arbitrary length (number of pages).
Even if the point might be true, that in real life a developer should roughly know the amount of required memory, this is not always possible as you can see. Therefore, you can only state "maximum" features as
"only PDF documents up tim 100 pages can be generated"
but that don't help as you can't predict how big a PDF will get, because it depends on the changing database data and lots of other parameters.
With the requests of me solved, this problem would at least be mitigated because for memeory intense PDF generation, the JVM would _temporarily_ take as much memory form the OS as it can. This might lead to swapping but the danger of OutOfMemoryErrors would be decreased. And if the JVM would be able to release memory to the OS, this temporary memory allocation would be reverted to a normal state after processing. Which would lead to an overall more stable and less memory consuming JVM.
I suggest, you control yourself before accusing other people to be "complete idiots". Just ignore those threads and let other people post comments that have an objective way of communication.
> You just accused me to be an idiot just because i post
> a request for a future JDK to solve the restriction of
> the JVM to
I called you an idiot because of an earlier thread in which you failed to understand why you cannot arbitrarily use an OutputStream as an InputStream. And another in which you called for a language feature without understanding the implications of what you were asking for.
This thread is requesting a feature which (for what it's worth) I would consider "quite useful" though your argument is poor and your reasons for "needing" it are suspect.
> I guess you have never wrote any large scale
> multi-threaded server applications with Java.
Designed, built, delivered. So you're objectively wrong there.
[snipped rambling description of an alleged "special" case].
It is always possible to come up with an intelligent estimate of how much memory a process will consume. If you don't fully understand the tools you're using, that's very much your problem.
> I suggest, you control yourself before accusing other
> people to be "complete idiots".
When the people in question give me copious cause to believe they're fools, I take enormous pleasure in pointing it out to them. Thanks for the offer, though.
> Just ignore those
> threads and let other people post comments that have
> an objective way of communication.
If people ignore stupid JCP requests, even in the relative backwater of the JCP forum, there is a risk they may be carried through without forethought. If I don't speak out against the ones I dislike, I'll have to cause for complaint if they make it into the language.
In this case (for once) I don't actively object to the feature in question, but I do think it's necessary to draw attention to the fact that a pressing need to hand back memory to the OS is often indicative of a design problem.
Dave.
I see you don't get it. You are one of those persons who are always right and others are stupid. You can't argument objectively. Any further response from you don't show any understanding. Discussing with you is sensless.
Sure I'm stupid too, and I make plenty of mistakes. In my case, when I ask a question and people say "you can't do that, and if you could you wouldn't want to", I usually figure out that I'm doing something wrong.
Given your rather whiny argument that it "ought" to be possible to use an InputStream as an OutputStream and vice versa, I can hardly call your arguments objective.
> Any further response from you don't show any understanding.
I don't understand your insult.
> Discussing with you is sensless.
Then why are you doing so ?
Why did you put out your idea for discussion if you didn't want any feedback. Just in case you didn't catch my feedback, here it is again: "that would be nice, but if you find it essential your design is poor".
I called you an idiot too, but as you'll note I don't claim that your suggestion is therefore a bad one, and I fail to see how that makes my comments on the design implications wrong either.
Dave.
Most OS can not give any memory a process grabs back until it exits.
ie. a called to free() does not return memory to the OS, it just frees up space in the current allocated memory space for the process. e.g If you malloc 300MB and then free() this memory your process will still show as using 300MB.
