Increase memory limits for IcedTea

[Peter B. Kessler]

Andrew Haley wrote:

> Peter B. Kessler writes:
>  > Andrew Haley wrote:
>  > > Peter B. Kessler writes:
>  > >  > Andrew Haley wrote:
>  > >  > 
>  > >  > > Peter B. Kessler writes:
>  > >  > > ....
>  > >  > > 
>  > >  > >  > The right solution is to make it so the heap doesn't have to
>  > >  > >  > be in contiguous memory.  Anyone want to help work on that?
>  > >  > > 
>  > >  > > Hmm.  Surely it's better / more efficient to ask the kernel to map a
>  > >  > > contiguous range of pages rather than for the VM do more work in user
>  > >  > > space.  The nice thing about Java on Linux is that we're in a position
>  > >  > > to ask the kernel engineers to help us with what we need.
>  > >  > 
>  > >  > You are probably thinking of reasonable users who want to run in
>  > >  > reasonable heaps that leave plenty of address space for other bits
>  > >  > of the process.  We get the phone calls from the folks that want
>  > >  > to shoehorn the largest possible heap into their address space.
>  > >  > Contiguous heaps are pain for them.
>  > > 
>  > > Yes, I see.  I suppose I would rather take the position today that
>  > > such people really should be using 64-bit systems: AFAIK it has not
>  > > been possible to buy a (new) 32-bit x86-based machine for a year or
>  > > so.  So, while I accept your point, it's more of an issue for legacy
>  > > hardware.  (I'm only considering desktop systems and servers here:
>  > > embedded Java is a whole 'nother ball of wax.)
>  > 
>  > The "problem" is that all these spiffy 64-bit systems can also
>  > run 32-bit JVM's.  Running the same app (or benchmark) on a
>  > 32-bit JVM and a 64-bit JVM quickly convinces you that you want
>  > to stay on a 32-bit JVM for as long as you can.  So you milk
>  > that address space for all it's worth.
> 
> Ah, I see.  That's really interesting, and a little surprising to me:
> gcc/gcj runs faster in 64-bit mode than in 32-bit mode, so we've never
> had to make such a tradeoff.  I think the main reason for this is that
> we can do much better register allocation on x86_64 than on x86, and
> the calling conventions are much better.  I hadn't realized that the
> Sun JVM took such a hit.
> 
> Andrew.

It depends on whether you are CPU intensive, in which case the
extra registers are a big win, or memory intensive, in which
case the extra memory traffic, having the caches hold fewer
objects, etc. is a loss.  I guess the people who are having
trouble wedging themselves into a 32-bit address space are
memory intensive rather than CPU intensive.

			... peter