This content has been marked as final. Show 2 replies
well you should add some vm parameters to your program to achieve your mission the parameter should be like:
-Xmx2g -Drtsj.precompile=nhrt.precompile -XX:RTGCCriticalReservedBytes=100m -XX:NormalMinFreeBytes=100m -XX:PrintGC
you can read more from the documentation:
[command line options|http://java.sun.com/javase/technologies/realtime/reference/doc_2.1/release/JavaRTSOptions.html]
As Gabi stated there is a lot you need to understand about how to configure the VM for predictability. I assume your first test with JRTS didn't use a real-time thread? In that case RTGC would work against you as its job is to ensure critical threads can achieve their goals - at the expense of everything non-critical (ie your non-realtime thread). Once you have a real-time thread doing the work then you have to make its job more predictable by ensuring you don't get hit at runtime with class-loading, class-initialization, compilation etc. So for that you need to generate pre-compile lists and pre-load lists and ensure that is all done up front. Then you need to start identifying where the "peaks" are coming from. -XX:+PrintGC will show you whether GC is a factor; but you also need to see whether your real-time thread is critical or not (determined by its priority). You can use that info to help tune the RTGC for your situation - by ensuring there is sufficient memory for critical threads to allocate from (RTGCCriticalReservedBytes). If GC isn't the issue (or even if it is) use the Thread Scheduling Visualizer to get an idea of what is happening around those peaks.
Predictability is a system-wide concern. It has to come from the application logic, the VM and the OS. There are so many things that can come into play to cause those "peaks".
The RTGC Guide and the Compilation guide, together with "A Practical Introduction to Achieving Determinism", are all worth a good read.