[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux

David Holmes david.holmes at oracle.com
Thu Jul 26 05:52:39 PDT 2012

Hi Roman,

Processor binding is a problematic area in general. Copying what Solaris 
does is probably harmless but not necessarily useful - and the Solaris 
implementation is likely incomplete in itself (as there are three 
mechanisms for constraining available CPUs: process binding, processor 
sets and resource pools (which the VM is generally ignorant of).

Do you have a motivating usecase for implementing this?


On 25/07/2012 9:06 PM, Roman Kennke wrote:
> I implemented the other two missing functions in os_linux.cpp
> (distribute_processes() and bind_to_processor() ) which implement
> support for the -XX:+BindGCTaskThreadsToCPUs option (together with -XX:
> +UseParallelGC), which distributes&  binds GC worker threads to
> different processors.
> The implementation is adopted from os_solaris.cpp. In particular
> assign_distribution() is almost 1:1 copy (except for the type diff
> processor_t vs. uint). It could be worth extracting this into a shared
> method, but on the other hand, there is potential for divergence (for
> example, for NUMA support. See my related question here:
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004751.html ).
> Just like the implementation for Solaris, we first check if we are
> running in a CPU set, and take this as a basis. I did not implement the
> other case though, it seems like a really rare fallback (processes that
> do not have any particular processor affinity return affinity with all
> processors set). Plus, if that call to pthread_getaffinity_np() does not
> work, it seems likely that the following call to
> pthread_setaffinity_np() doesn't work either (because lack of
> permissions or lack of support in the kernel or such). Please let me
> know if you think it's worth to implement this case anyway and use the
> set of all online processors then.
> Opinions about that patch?
> http://cr.openjdk.java.net/~rkennke/linux_gc_workers/webrev.00/
> Kind regards,
> Roman

More information about the hotspot-dev mailing list