-Xmx considered evil (at least in the Windows desktop)

Question

I've written my own launcher (actually, my own "wrap up Java as a COM object"). Occasionally, and rarely, the InitializeJVM call returns -4 (JNI_ENOMEM), even though there's plenty of memory available, according to the Task Manager. Reducing the max heap size gets around the problem, but that's not good, because my application can be a bit of a memory hog.
So, I have two questions:
1. What does {color:#ff0000}InitializeJVM {color}actually do (on Windows)? Does it do a VirtualAlloc MEM_COMMIT? If it's not committing, it can't possibly run out of virtual address space. But, it's silly for it to commit. Besides, looking at the memory usage more closely, it's clear that the heap is not fully committed. So, does it MEM_COMMIT then MEM_DECOMMIT? That doesn't make sense.
2. Why does Java bother with a maximum heap size, anyway? Windows doesn't restrict process space. Of course, the underlying resource, the page file, can be exhausted. But them's the breaks. I do not see how Java can possibly guarantee the requested heap space will be available in the page file (e.g., as committed memory) when needed, since it doesn't commit what it's not using. Some other process could easily gobble up the page file and leave none for me.
I imagine Java is doing something I don't understand. I wish I did understand it, because then I could fix my problem.
I'm hoping someone with access to the code implementing InitializveJVM can read it and tell me how it treats the -Xmx parameter.

Answer 1

Doctor_Dad wrote:
Memory leaks are possible in both GC'ed and non-GC'ed environments. I maintain it's easier to think about in non-GC'ed environments. In an alloc/free environment, the programmer has the obligation, having coded the alloc, to code the free and to arrange to have it called. He can then use the object. In a GC'ed environment, there's no simple way to think about how to ensure that the newly created object will eventually become garbage. That is my fundamental objection to Garbage Collection. It is impossible to think about clearly. And what matters in the business of software development is thought. Not technology. Not fancy Design Paradigms. Thought.
It is the same in both environments actually. And it applies to any resource not just memory.
Any resource has a runtime scope. At the end of that scope it must be deallocated.
The correct way for a designer and/or implementator to reduce problems is to consider that scope when the resource is first acquired and code appropriately for that.
An object's being garbage is a system wide attribute. An object reference exists in a web of references and one hopes one can turn the entire web into garbage by slicing a particular strand. But how easy is it to document (+a priori+) or determine (+a posteriori+) what that web is and how to slice it?
Except for the very, very rare object that is not a problem because of the limited set of references to it. If one has more than one type of class in even large apps which has more than a couple references then it would at least suggest a possible problem with the design.
The de-reference of a dead pointer is a bug that is often stumbled on during ordinary testing. A GC-memory leak can't be found unless you're actually looking for it with a memory analyzer. (OK, the same is true of memory leaks in non-GC'ed systems.)
(Ok nbr 2: De-referencing a dead pointer is a bug that can be very hard to diagnose.)
Simple solution to 2, set it to null. This is regardless of language being used.
And then there's the folk that have very tight scheduling deadlines and don't like GC randomly stealing CPU cycles. I'm not one of those people, so don't argue to me that it can all be adjusted with the right -XX parameter. I don't have any facts at my disposal to dispute it. However, the people I talk to who do have those deadlines say they can't use Java because it's GC'ed.
Huh?
I can only suppose that perhaps you meant someone with very strict timing requirements since that is the only relation to CPU. Most people that use GC options are either attempting to squeeze extra performance out of a system or they have a system that for some reason bogs down due to GC. Myself I suspect that the latter is due to a poor system rather than a short coming in GC itself and performance is always (again any language) much more stongly impacted by requirements/design than by implementation.