Re: Question on -Xms/-Xmx and -XX:MaxPermSize in JVM start parameter

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Mon, 11 May 2009 21:27:35 -0400

Message-ID:

<4a08d082$0$90265$14726298@news.sunsite.dk>

Tom Anderson wrote:

On Sun, 10 May 2009, Arne Vajh?j wrote:

Tom Anderson wrote:

On Sun, 10 May 2009, Arne Vajh?j wrote:

Tom Anderson wrote:

Personally, i find it incredibly irritating that there isn't a flag
to limit total memory use, which is surely what people actually
need. I couldn't give two hoots about the size of PermGen, but if i
have a machine with 4 GM of RAM that's running two app server
stacks in parallel, i bloody well need to be able to put a hard
limit of 2 GB (or whatever) on each. Yes, i can probably do this
with ulimit in the startup script, but why isn't there just an
option for it?

But if you prefer an OOME instead of degrading performance,
then you could use that limit you want.

Hang on, are you suggesting that using ulimit would lead to OOME when
JVM flags wouldn't, or that either would lead to OOME when not using
a limit wouldn't?

If the JVM will not allocate or the JVM can not allocate what
you need then you get OOME.

You didn't answer my question! Do you think a limit set with ulimit will
behave differently to a limit set with mx/MaxPermGen with regards to
when OOME is thrown?

No.

And I tried to answer.

will not = Xmx/MaxPermGen
can not = ulimit

At least in theory two other options exists for ulimit:
- the JVM aborts at startup
- the JVM crashes or gives another error when it can not allocate

I don't know about ulimit; i would hope that the JVM would cope
gracefully with hitting a memory limit, ie not crashing or getting
over-excited with OOMEs. And i don't think setting a hard limit on
memory use, by any method, is likely to lead to OOME in my particular
situation: as i mention above, it will just lead to more frequent
GCs. I'm talking about cutting down memory use from 2.5 GB to 2GB,
not 2.5 GB to 0.5 GB. I'm fairly confident that my app will run in
that amount of memory; it uses most of its RAM for caches, so those
can always be tuned to use less memory (i don't think they're
self-tuning, sadly).

If the app can run in MIN(Xmx,ulimit) then you should not get OOME.

But I see your point. You want to decrease paging by increasing GC'ing.

Interesting point.

I believe that a JVM should itself increase GC'ing if it notice a lot
of PF's. But I have no idea whether current implementations actually
do do.

I didn't even know it was possible for a user-level process to notice
page faults. Perhaps via some system monitoring interface?

I believe practically all the common OS's provide such an API.

I certainly
haven't heard of any JVMs doing that; that doesn't mean they aren't, of
course. It would be an interesting idea, for sure,

It seems rather logical for the same reasons you want it.

although i would
worry about unforeseen interactions between the OS's VM manager and the
JVM's anti-VM-manager - if the JVM keeps shrinking its heap to stay in
physical memory, perhaps the OS will keep shrinking its physical memory
allocation?

I don't think low paging will cause the OS memory management to reduce
physical memory allocated. That would be punishing the well-behaving
apps.

Arne