JVM ergonomics can default to a very small (64Mb) max heap on 32-bit desktop-class systems; at least older JVMs certainly used to. That's not enough to do very much at all.
It would be nice to just yield to the JVM's ergonomics when it is doing something useful, like the allocations 1.5 and up have applied to server-class systems. These would often provide for a *larger* heap that we're discussing allocating here. I have no idea how one would detect the ergonomics the JVM is using, though. On Thu, Dec 22, 2011 at 2:59 PM, Uwe Kubosch <u...@kubosch.no> wrote: > On 2011-12-20, at 07:19, Charles Oliver Nutter wrote: > > > I was thinking of bumping to 1GB. > > > > A 32-bit JVM can't go higher than a 4GB process space, and typically > > you don't go above 2GB heap there in case there's a lot of native > > memory that might push it close to the 32-bit process limit. So I > > think we'd be safest halving that and doing 1GB, which would be enough > > for the vast majority of uses, but not so large it would commonly > > exceed available memory on a typical desktop or server. > > > Why do we need to set the max heap size differently than the JVM default? > Because JRuby applications need more heap than other Java apps? > > If we need to explicitly set the heap size, what about setting it to > double of the standard JVM setting? > > We run lots of different apps on JRuby, and they all have different Xmx > settings. 512MB fits many Rails apps, but for many background jobs we use > half that, and for many Rails apps we use much more. > > If we cannot adjust to the JVM default settings, I think 512MB on 32-bit > and 1GB on 64-bit would be good all-round settings. > > -- > Uwe Kubosch > u...@kubosch.no > http://kubosch.no/ > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
