unlimited eh? Thanks.

actually, upon checking unlimited doesn't seem to be acceptable...
this again raises the problem with -Xmx, that it forces me to put a
hard limit on a dynamically allocated resource...

Now that you mention it, old mac os 9 used to require a max heap size
set for every application (get info, maximum memory). However, that
was a horribly primitive system. I understand that they'd want mac
compatibility, but it seems unfortunate that they did it in such a way
that made everyone else suffer... I'd like my programs not to die
every time they get an unexpectedly large input. However high I set
the -Xmx value it's always possible that more heap space will be
necessary.

Given virtual memory, and the fact the fact that on a reasonable
application only a small subset of memory need to be accessible in
ram, thrashing isn't really a problem, there's really no practical
limit to a maximum heap size.

The issue is maximum heap... just because the heap is bounded to a
certain volume, or unbounded doesn't mean that java needs to sbrk that
much heap space. Making the default unbounded, which is all I would
like to see change, wouldn't mean that java by default sbrks the whole
address space, and if it does, that's a java implementation problem
that shouldn't be there.

I don't see how -Xmx is useful for balancing "system memory" (by which
I think you mean memory allocated by malloc... which is also on the
heap btw, just not the gc'd section). As near as I can tell
applications pretty much just die when they run into the -Xmx barrier.
I guess it probably throws an exception which could be caught; however
it seems unlikely that such an exception could be recovered from in a
meaningful way given the number of places that could throw such an
exception.

Someone else mentioned that I could make -Xmx the size of the entire
address space; however I would note that isn't portable, as for 32 bit
systems that is merely 4 gigs, whereas 64 bit machines can handle a
lot more depending on the vm's implementation. The problem is that
right now, java users who know nothing about java implementation
details have to go in and mess with the java launching script to make
their java applications work, and they would still have to do that
occasionally if the script writer guessed a common address space size.
It's not the correct solution.

Someone else mentioned that thrashing can happen... but that is the
result of a poorly written program or gc, not a high -Xmx value.
Extremely large heaps can not thrash, and significantly smaller heaps
can depending on memory access patterns.

In conclussion -Xmx seems like a total hack to me, and I'd like to see
it set to an unlimited value by default. It could still be there for
people who need it, and don't know how to do the exact same thing
through the shell with rlimit. The default action is just a nuisance
though.