[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux

Ben Evans ben at jclarity.com
Thu Jul 26 06:29:46 PDT 2012

Hi David,

Could you expand a bit on why you feel processor binding is problematic?

In the low-latency space at least, this is a topic which often comes up.
Having a view from the platform implementors as to why Java seems to be
lacking compared to alternatives would be very useful.



On Thu, Jul 26, 2012 at 5:52 AM, David Holmes <david.holmes at oracle.com>wrote:

> 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?
> Thanks,
> David
> 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<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/<http://cr.openjdk.java.net/~rkennke/linux_gc_workers/webrev.00/>
>> Kind regards,
>> Roman

More information about the hotspot-dev mailing list