On 30/07/06, Xiao-Feng Li wrote: > Agree that maximum size is still desirable for system stability > reason. :-) ( I hope the OS MM can be more intelligent to deal with > overcommitment.) But here in this specific discussion context, I > think the word `unlimit' or `infinite' is meaning `unlimit under > certain limit'. Whatever the limit is can be defined by the clever OS > (which returns a ENOMEM, for example) or user heuristics. Infinite in a computer science, rather than mathematical sense :-) For example, there may be practical reasons why 4Gb is the maximum (or 2Gb if signed pointers are used). But even if the OS has 512mb of memory, and (say) 256m free, there's no reason to limit the amount of memory that the JVM requests. The user will notice a slow-down in performance as soon as the *practical* limit is transgressed, but unless the user starts with a -Xmx option, the memory should be 'unlimited' in the 'largest amount of space that is possible'. Given that most OSs have virtual memory, why should the JVM decide that it's not going to use it? I'd argue that if not specified, the limit should be unlimited in the sense that the largest possible amount that the process can possible acquire. If the user wants to limit the amount of memory to prevent swapping, that's fine, but it has to be a user-supplied option and not a JVM-enforced-default. Let's face it, the only reason why -Xmx is used at all in almost all JVMs is not to limit the amount of space, but rather a workaround because the JVM gets it wrong. Alex. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org