Trying to find right -Xss, -Xmx values for application using JNI
I'm trying to find the "right" VM memory/stack settings for our application that uses JNI. We are using JDK 1.3.1_01, SunOS 5.7 (and/or NT4). The application engine written in C++ is both memory and computation intensive, the GUI is in Java. The 2 sides communicate through JNI.
What effect does these options have on the C++ side? I thought setting -Xmx to 1.4 G for NT and 2G for Solaris would allow our application to utilize all the resource. But I was told by our local Java guy that setting -Xmx too high would reduce the memory C++ side can use. But, isn't C++ side just a thread under JVM -> same process? Then, the amount of memory it can access is the address space (2G on a 32-bit machine). Increase the heap size would increase the memory the process can access? On the other hand, why increasing -Xss would prevent a recursive C++ function running out of stack? See my confusion? Larger -Xmx won't help C++ side but higher -Xss would.
What scares me is that the Java side of our application does depend on the C++ side in terms of the memory consumption. If we get this wrong, our application would die when our customers using it for the real thing. What is the guideline for setting these numbers? BTW, we typically set ulimit to unlimited for Solaris.
Please help.
[1318 byte] By [
yangdyy] at [2007-9-26 12:37:12]
That's very tricky indeed.... I'm spending a lot of time on tuning JVM for high load/availability production server. Some things still beat me and no one seems to have an answer. Here is what i found by try-and-error by now.
1) Xmx max limits:
- 32bit Linux: ~1.8M
- 32bit Windows: ~1.7M
- Solaris (Spark CPU): quite unlimited (at least more than 3Gb)
2) To make life easier for JVM, set Xms to be the same as Xmx (there are some 'Hotspot JVM Performance tuning' on sun site which u might want to look at)
3) Xss defines thread stack size for the threads created by JVM (both 'native' and java stack size).
4) Latest hunch (smth i stumbled at just 5 min ago): Xss*nRunningThreads+Xmx~=<max Xmx> (that is, eg, 1.8M under 32bit Linux - see above).
5) Any JNI code is executed inside the context of the Java thread it was called from
AFA i know, Xss is mainly important for JNI code. AFA i know in Java calls this param mainly limits method argument names lengths and how deep your recursive calls can be. As to native code, it does effectively limit the size of structures u can allocate on stack inside your C code.
The important thing is that all native heap allocations are made completely outside of JVM heap. Thus, i think in native heap allocations u are only limited by OS settings. Eg, it's no problem allocating 2G of data on native heap with Xmx param set to 200M.
The conclusion:
1) Check what is the biggest stack allocation in your native code
2) !!!! make sure you never brake the rule metioned above at #4 (eg, by limiting the number of concurrent _threads_ running) - ASA u break it u will start getting all kinds of 'OutOfMemoryExceptions' from your native code (or Java code for that matter - on creation of new Thread). I am currently thinking of rewriting communication layer with nio to avoid excessive threads allocations.
3) Default stack sizes for OSs (as of 1.4.1-beta):
256k for 32-bit intel, 512K for 32-bit
sparc, 1M for 64-bit sparc)
Good luck.
Here are some corrections (again, just for the record, since not many people get involved in these threads for some reason). I tried to prove the 'hunch' "Xss*nRunningThreads + Xmx ~= <max Xmx>", but couldn't do it on artificial test. Probably the JSR mentioned in another thread might explain why. In real life senario though, there is some obvious correlation between coredumps and number of threads currently running, as well as Xss parameter (eg, with Xss=10M, the particular application coredumps with 5 concurrent threads, with Xss=1M - 40-50 threads, Xss=256k - couldn't make it core dump at all). I think the main clue is that each thread does execute native code. One thing for sure is that -Xss memory is not getting 'reserved' when thread is created, but dynamically allocated on-demand basis. At least under 32bit Linux.
> 1) Xmx max limits:
> - 32bit Linux: ~1.8M
> - 32bit Windows: ~1.7M
> - Solaris (Spark CPU): quite unlimited (at least more
> than 3Gb)
Limits....
http://forum.java.sun.com/thread.jsp?forum=37&thread=202978
>
> 2) To make life easier for JVM, set Xms to be the same
> as Xmx (there are some 'Hotspot JVM Performance
> tuning' on sun site which u might want to look at)
>
I wouldn't necessarily call that a general rule.
> I'm trying to find the "right" VM memory/stack
> settings for our application that uses JNI. We are
> using JDK 1.3.1_01, SunOS 5.7 (and/or NT4). The
> application engine written in C++ is both memory and
> computation intensive, the GUI is in Java. The 2 sides
> communicate through JNI.
>
> What effect does these options have on the C++ side?
None.
> I thought setting -Xmx to 1.4 G for NT and 2G for
> Solaris would allow our application to utilize all the
> resource.
It will let the java heap use that much.
> But I was told by our local Java guy that
> setting -Xmx too high would reduce the memory C++ side
> can use.
Correct. The application (applies to any application) is limited by the addressable memory of the OS and the virtual memory size. The java heap and the C++ heap are seperate, but together are limited by the application limit total. So if you increase either the java heap or the C++ heap then it reduces the other side.
> But, isn't C++ side just a thread under JVM
> -> same process?
That has nothing to do with it.
> Then, the amount of memory it can
> access is the address space (2G on a 32-bit machine).
Not necessarily. See the link in the other posting.
> Increase the heap size would increase the memory the
> process can access?
Nope.
> On the other hand, why increasing
> -Xss would prevent a recursive C++ function running
> out of stack? See my confusion? Larger -Xmx won't help
> C++ side but higher -Xss would.
>
Nope. Xss applies to the java stack. It has no impact on the C++ stack (except perhaps for the actual call interface to a JNI method itself.)
> What scares me is that the Java side of our
> application does depend on the C++ side in terms of
> the memory consumption. If we get this wrong, our
> application would die when our customers using it for
> the real thing. What is the guideline for setting
> these numbers?
Test, test, test. And guess.
> Nope. Xss applies to the java stack. It has no impact on the C++ stack (except perhaps for the actual call interface to a JNI method itself.)
Not quite so... "HotSpot doesn't have separate native and Java stacks". In IBM JVM java stack size and native stack size are set separately. In pre-HotSpot SUN JVM it was separate as well AFA i remember. In hotspot JVM Xss parameter started to define both Java and Native stack size - a simple test can prove it.
> > Nope. Xss applies to the java stack. It has no
> impact on the C++ stack (except perhaps for the actual
> call interface to a JNI method itself.)
>
> Not quite so... "HotSpot doesn't have separate native
> and Java stacks". In IBM JVM java stack size and
> native stack size are set separately. In pre-HotSpot
> SUN JVM it was separate as well AFA i remember. In
> hotspot JVM Xss parameter started to define both Java
> and Native stack size - a simple test can prove it.
Please provide the reference that states that.
It is http://java.sun.com/docs/hotspot/VMOptions.html - see under -Xoss option.Also see: http://forum.java.sun.com/thread.jsp?forum=37&thread=470915&tstart=0&trange=15
> It is http://java.sun.com/docs/hotspot/VMOptions.html
> - see under -Xoss option.
>
Hmmmm....at least in older versions of windows there was maximum size for this in C code. To get around this one either compiled it in or modified it at runtime (before calling obviously.)
And the windows jre, no longer has the Xss option. Or at least it is not documented. So unless my memory is incorrect it makes me wonder what versions of the windows/cpus the newer jre's are really intended to support.
Yes, as i said, in 'older' versions native and java stack sizes were set separately. Also, Xss param is still there, at least as of 1.4.1_02 JVM. At least it is being displayed with java -X command...
