Question about GC threads in parallel scavenge

Jon Masamitsu jon.masamitsu at oracle.com
Thu Jul 26 15:48:10 UTC 2012


Roman,

Nothing has been implemented in hotspot to make a GC thread preferentially
access objects in its local memory first.  So binding the GC threads to
CPU's probably won't hurt.  Should a GC thread process objects in its
local memory first?  Probably yes.  But how the binding is done and
how helpful it will be depends on the GC algorithm.

Jon

On 07/24/12 12:54, Roman Kennke wrote:
> Hello,
>
> today I implemented 2 missing methods in os_linux.cpp
> (distribute_processes() and bind_to_processor()) which are apparently
> used for the parallel-scavenge GC to distribute the GC threads across
> processors when -XX:+BindGCTaskThreadsToCPUs is set (in addition to -XX:
> +UseParallelGC).
>
> I now wonder if this is beneficial in a NUMA environment. There the GC
> threads should be bound to the same processor (or more specifically
> socket) that is 'close' to the GC thread's memory region. A random
> distribution of GC threads over processors seems to undo some of the
> benefits of NUMA. Right?
>
> I am sure I must be missing something here. I am not very familiar with
> Hotspot's GCs and also by far not an expert in NUMA, so I might be
> totally looking in the wrong direction here. Would it make sense to make
> the processor-assignment of GC threads NUMA-aware? Or maybe it already
> is and I simply cannot see it (I am looking at current Solaris
> implementation), maybe a different code path?
>
> Kind regards,
> Roman
>
>



More information about the hotspot-gc-dev mailing list