This content has been marked as final. Show 1 reply
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
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