Increase memory limits for IcedTea

[Peter B. Kessler]

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.

			... peter

>  > The problem is that we don't know in advance if they will want the
>  > address space for Java heap, thread stacks, libraries, malloc space,
>  > etc.  Otherwise we'd just reserve the whole address space for the
>  > heap.  That wouldn't leave any room for anything else, though.
>  > It would be better to only reserve the space we need, do the work
>  > to make the heap not need contiguous addresses, and make it all work
>  > efficiently in the kernel.
> 
> I take your point.  I suppose the key question is just how much extra
> work in userland can be justified for this effort.
> 
>  > (We talk to the kernel engineers for our favorite operating system,
>  > too. :-)
> 
> (Oh, OK.  :-)
> 
> Andrew.
>