Florian Weimer writes:
> * Andrew Haley:
> > From a support point of view, the way that Java dynamically sets its
> > limits based on the capabilities of a particular box is quite scary.
> > I can certainly see why it's done, but it does mean that for
> > reproducible builds you have to find VM parameter that is set
> > dynamically and nail it down.
> Well, I'm not sure what's the answer to this problem, and how it relates
> to the MAP_NORESERVE/PROT_NONE issue (and if at all).
Well, this discussion is about memory limits, how they are set, and
what their defaults should be, so I think it's relevant.
The real issue as far as I'm concerned is that the Java VM behaves in
a way that is different from just about every other program in a
GNU/Linux system: when you run a large Java app you may have to
explicitly tell the VM how much memory is going to be needed, and not
only how much, but what kind. On the other hand, if the VM decides
you have a powerful enough box, you may not have to set the limits.
Sure, there are good reasons for this, but it is fairly weird for a
user to have to choose a memory limit before running an application
such as Eclipse or javac.
And I'm not ignoring Peter Kessler's point about changing the gc so
that it no longer needs a single contiguous region, but that is a bit
more long term.
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903