Re: how to enlarger Java heap size?
Lew wrote:
This is an OS limit; it's not really Java's fault.
Peter Duniho wrote:
I guess that depends on how much of an abstraction one believes Java
should provide. Java _could_ provide larger heaps by not depending
directly on the OS to allocate the space.
But it's not Java that makes such a thing the wrong thing to do.
It's my opinion that the current implementation is the correct one;
almost everyone who might take advantage of a larger Java heap on a
32-bit OS would quickly find that for performance reasons, they really
don't want to do that on a 32-bit OS.
Right. Its not Java's job to run with whatever metasetting (-Xmx greater than
2 GB) you throw at it; only to do so within the limitations of the host
environment. The JVM cannot magically buy you more RAM nor alter the OS's
memory-allocation system calls. The portability promise only extends to the
language, not the platform. That Java chooses not to work around (I shall not
say "solve") a limitation imposed by the 32-bitness of the host system, is not
a flaw in Java but a refusal to do the unnecessary. They offer a 64-bit
version precisely to address that limitation.
I note that the same exact bytecode runs with identical functionality in the
64-bit version as in the 32-bit version, keeping Java's portability promise.
But I think it's safe to say that it's at least a _little_ bit "Java's
fault". It's not like it would have been _impossible_ for them to
support larger heaps on 32-bit OSs. :)
I understand that you are exercising some rhetorical license here, and I grant
you full marks for it.
You are absolutely correct in your analysis, however you require a somewhat
idiosyncratic albeit somewhat defensible definition of "fault". I propose we
give this one to Java's designers and not be too upset that they didn't try to
implement 64-on-32. If it's a sin to be pragmatic and reasonable, then yes,
Java is at fault.
--
Lew