This discussion is archived
7 Replies Latest reply: Dec 6, 2009 4:00 PM by 807557 RSS

getPreemptionLatency in Sun's RTJ

807557 Newbie
Currently Being Moderated
Hello,

I've tried the following piece of code to obtain information about the interference introduced by the garbage collector:
System.out.println( RealtimeSystem.currentGC().getPreemptionLatency());
in the following system:
- Ubuntu (9.1)
- Real-time Linux Patch (linux-rt package)
- Sun's VM
- 1,6 Ghz Laptop

My results showed that the preemption time for JRTS 2.1 is 1 ms. After testing this value empirically, running one low-priority thread which is executing System.gc() and measuring the interference on a high-priority NoHeapRealTimeThread, some questions come to my mind.

- Is this the maximum interference any NoHeapRealTimeThreadshould expected from the garbage collector?
- How is it possible that a garbage collector obtain this value?
- Is there any strategy to reduce the preemption time?

Thanks,
Pablo

Edited by: pbasanta@ on Dec 3, 2009 10:41 AM
  • 1. Re: getPreemptionLatency in Sun's RTJ
    807557 Newbie
    Currently Being Moderated
    pbasanta@ wrote:
    I've tried the following piece of code to obtain information about the interference introduced by the garbage collector:
    System.out.println( RealtimeSystem.currentGC().getPreemptionLatency());
    "interference" is not what getPreemptionLatency() reports. getPreemptionLatency() is the worst-case interval that a heap-using schedulable-object, with priority greater than the GC may have to wait until it can actually preempt the GC due to the GC not being at a safe preemption point.

    NHRTs are not affected by this as they don't have to wait for anything to preempt the GC.

    David Holmes
  • 2. Re: getPreemptionLatency in Sun's RTJ
    807557 Newbie
    Currently Being Moderated
    Hello again,

    Thanks for the answer. According to the description given, gcPreemptionLatency refers to the extra time that RTTHs need to allocate objects in the worst scenario.

    Another question about the implementation of Sun's RT-GC. What kind of interference does the RT-GC introduce in NHRTs? I imagine that the garbage collector should explore the stack of the thread (stopping the thread or activating certain parallel low-level barriers) in order look for references, stored in the stack, to objects allocated in immortal and scoped memory. If this is the case, NHRTs suffer a small preemption time due to the process of scanning the stack, am I right?
    Could this interference be relevant (hundreds of microseconds or milliseconds)?
    Is there any way to measure it (a non-RTSJ method or something similar) similar to gcPreemptionLatency?


    Thanks,
    Pablo
  • 3. Re: getPreemptionLatency in Sun's RTJ
    807557 Newbie
    Currently Being Moderated
    Hi Pablo,

    By construction, NHRTs do not have any reference to the Heap on their stack. Hence the RTGC need not scan their stack.

    The interference of the RTGC logic on the NHRT is negligible (mainly activating and deactivating barriers). We can still reach latencies in the tens of microseconds with NHRT when the RTGC is running.

    Of course, at this level of determinism, you have to be careful with hardware issues (cache misses, bus saturation, ...) and use for instance processor sets and interrupt shielding.

    Regards,

    Bertrand.
  • 4. Re: getPreemptionLatency in Sun's RTJ
    807557 Newbie
    Currently Being Moderated
    Hi Bertrand,
    Bertrand.Delsart wrote:
    Hi Pablo,

    By construction, NHRTs do not have any reference to the Heap on their stack. Hence the RTGC need not scan their >stack.
    So, if you have a NHRT that has a reference to an object in immortal memory that has a connection to an object allocated in the heap.

    (NHRT->[scopedmemory or immortal object]->Heap-object)

    Then, according to your comment, el heap object is not destroyed if:
    1) There is another object in immortal memory that has a reference to the object (even if the object is not reachable)
    2) The whole scope (*LTMemory*) is not reclaimed (even if the object is not reachable).

    >
    The interference of the RTGC logic on the NHRT is negligible (mainly activating and deactivating barriers). We can still reach latencies in the tens of microseconds with NHRT when the RTGC is running.

    Of course, at this level of determinism, you have to be careful with hardware issues (cache misses, bus saturation, ...) and use for instance processor sets and interrupt shielding.
    In this case, the garbage collector is similar to another thread. Nice solution .;)

    Thanks,
    Pablo

    Edited by: pbasanta@ on Dec 4, 2009 4:16 AM
  • 5. Re: getPreemptionLatency in Sun's RTJ
    807557 Newbie
    Currently Being Moderated
    pbasanta@ wrote:
    So, if you have a NHRT that has a reference to an object in immortal memory that has a connection to an object allocated in the heap.

    (NHRT->[scopedmemory or immortal object]->Heap-object)

    Then, according to your comment, el heap object is not destroyed if:
    1) There is another object in immortal memory that has a reference to the object (even if the object is not reachable)
    Indeed, our RTGC does not collect ImmortalMemory.
    2) The whole scope (*LTMemory*) is not reclaimed (even if the object is not reachable).
    By definition, a scope is a fast area which is recycled as a whole as soon as it is no longer useful (e.g. entered).
    Note that since scopes are primarily used by the NHRT, they contain very few Heap references. In addition, the scopes are often recycled automatically more frequently than the GC cycles. Thus, you would not gain a lot by trying to detect earlier objects that are not longer reachable within the scope... and this would be expensive both in terms of overhead and in terms of code complexity.

    Bertrand.
  • 6. Re: getPreemptionLatency in Sun's RTJ
    807557 Newbie
    Currently Being Moderated
    pbasanta@ wrote:
    Thanks for the answer. According to the description given, gcPreemptionLatency refers to the extra time that RTTHs need to allocate objects in the worst scenario.
    No that's not what I said. If the RTT needs to do an allocation then it will get blocked at allocation time if the GC has not yet freed sufficient memory. That's independent of the preemption latency.

    David Holmes

    Edited by: davidholmes on Dec 7, 2009 10:00 AM
  • 7. Re: getPreemptionLatency in Sun's RTJ
    807557 Newbie
    Currently Being Moderated
    Bertrand.Delsart wrote:
    Then, according to your comment, el heap object is not destroyed if:
    1) There is another object in immortal memory that has a reference to the object (even if the object is not reachable)
    Indeed, our RTGC does not collect ImmortalMemory.
    But to be clear this is part of the definition of ImmortalMemory in the RTSJ. Objects in immortal live forever and so objects they reference also live forever.

    In theory, looking at the spec under the right light, you could do some GC on immortal (because if the object is unreachable then the application can't tell whether you GC'ed it or not). But that GC must not introduce any significant delays to NHRTs. And I'm not aware of any RTSJ implementation that actually attempts to do immortal memory GC.

    David Holmes