1 Reply Latest reply on May 30, 2008 8:07 AM by 807557

    Realtime GC in 2.1 beta - worker thread parameters


      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.

        • 1. Re: Realtime GC in 2.1 beta - worker thread parameters

          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



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