JEP 141: Increase the Client VM's Default Heap Size

[Jon Masamitsu]

On 2/29/2012 12:21 AM, Sunny Chan wrote:
> Jon Masamitsu<jon.masamitsu at ...>  writes:
>
>> Sunny,
>>
>> We've talked about the fallback position of trying to reserve
>> less that the default (say, 1G).  Would you want it all to be done
>> silently?  Or would you want some warning that your
>> not getting the whole 1G?   Or would you want a flag
>> (yet another flag, ugh) that you turn on that would cause
>> a warning?
>>
>> Jon
> I think others should chime in on this, but the way I think about this
> is that 32bit Client VM are most likely running GUI applications, and
> generally they don't see any error message you push out onto the console.
> So unless your warning is going to be a message box pop up, no one would
> ever notice until they hit OutOfMemoryError.
>
> If an application doesn't specify a Xmx or Xms value, it is really
> telling the JVM that it doesn't really care what the sizings of the heap
> are and they are hoping the default would work. So as long as the fall back
> position is well known and well defined (e.g. JVM will try 1G and then 512M,
> then it will fail with a helpful message), then I don't think it would cause
> too many problems.

I'm inclined to think that for a significant number of users, not 
specifying Xmx and Xms means they
have accommodated the default limits, maybe by modifying their code to 
work well within those
limits.  I'm thinking that the change should be advertised as an 
increase up to the 1G (say) but
less if there is less available.  That is, we can't guarantee that we'll 
be able to get 1G so no one
should count on it.  I think that  if we cannot reserve the current Xmx, 
we should fail to initialize as we
do today (I think that would offer the least surprise to current 
users).  I guess that's pretty much
what you're saying.   I'd just be more clear on the disclaimer - "Don't 
depend on getting the
larger heap size".

Jon