This discussion is archived
2 Replies Latest reply: Aug 26, 2008 5:09 AM by 807557 RSS

Persistent peak with JRT

807557 Newbie
Currently Being Moderated
Hi,
I'm trying to render a specific program predictable. Using the JRT framework from sun.
(Pictures X axis is the packet test number and Y axis is in seconds)
I made first measures with the default java [Normal JVM|http://imagebin.org/24992] and received quite good results over e period of 10 minutes.
After this i switched to the JRT Virtual Machine and have redone the test. The results where quite shocking to say the least. JRT
The peaks occurred when the GC is activated or the GC enters critical Level.
After setting the priority of my thread to the maximum it stabilized at one or two peaks for the same test [JRT High|http://imagebin.org/24994]
Now i know that it can't be the OS Scheduler creating this peak. Else it would happen in the normal JVM too.

What could be the reason for this peak?

Any input is appreciated
Best regards

Christian DuChamps

Edited by: Vispo on Aug 26, 2008 4:12 AM
  • 1. Re: Persistent peak with JRT
    800408 Newbie
    Currently Being Moderated
    Hi,
    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:
    [http://java.sun.com/javase/technologies/realtime/reference/rts_productdoc.html]
    [command line options|http://java.sun.com/javase/technologies/realtime/reference/doc_2.1/release/JavaRTSOptions.html]

    bye
  • 2. Re: Persistent peak with JRT
    807557 Newbie
    Currently Being Moderated
    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.

    David Holmes