This discussion is archived
1 Reply Latest reply: May 30, 2008 1:07 AM by 807557 RSS

Realtime GC in 2.1 beta - worker thread parameters

807557 Newbie
Currently Being Moderated
Hi,

I have a (possibly daft) question regarding the real-time GC parameters in 2.1 beta.

Say, for example, I have an 8-core system. If I set the RTGCNormalWorkers to 2, does this reserve 2 cores purely for the RTGC, leaving 6 cores for real-time threads? Or do the 2 GC threads just get scheduled onto the 8 cores along with everything else?

The GC documentation implies the former, since it mentions dedicating processors to GC work, but I may be misinterpreting the usage of "dedicated" in this context :-)

I assume I can get this effect by setting the priorities appropriately - setting the realtime thread priorities to 12, and normal GC priority to 14 (and restricting GC worker thread count to 2) would ensure that the 2 GC threads always get CPU time (assuming that nothing ran at a higher priority) - effectively dedicating those 2 cores to GC work.

Was just wondering if the new worker thread params did anything special.

Thanks for any help.

David.
  • 1. Re: Realtime GC in 2.1 beta - worker thread parameters
    807557 Newbie
    Currently Being Moderated
    Hi,

    Thanks for your feedback. We should indeed have also specified the priority in the example
    to really dedicate CPUs.

    In general, to control the RTGC behavior, you can play with priorities, with the number of RTGC threads
    and with the RTGC start criterion.

    For this particular example, we just set the 'start criteria' (-XX:NormalMinFreeBytes=1G) which forces
    the RTGC never to stop and ask the RTGC to use 2 worker threads when it starts
    (-XX:RTGCNormalWorkers=2). However, they start at the NormalPriority, which is the lowest
    real-time priority. If there is no RealTime threads, this is sufficient to guarantee the behavior we wanted
    (this is a configuration I usually recommand to people who just want to try the RTGC without changing
    their application).

    Now, if you have a lot of RealtimeThreads, you have to decide whether they should preempt these 2
    RTGC worker threads (as long as there is enough free memory left). You can set -XX:RTGCNormalPriority
    to decide the importance of these RTGC work.

    To 'dedicate' CPUs, RTGCNormalPriority should be set to the same value as RTGCBoostedPriority.

    To be exact, this still does not really dedicate CPUs. It just creates two worker threads at a very high priority but:
    -1- there are few phases were only one of them can run
    -2- we still allow the hard real-time threads (the NHRT and the critical treads) to preempt to RTGC threads

    Thanks,

    Bertrand

    --
    Bertrand Delsart, Sun Microsystems
    180 av. de l'Europe, ZIRST de Montbonnot, 38334 Saint Ismier, FRANCE