[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.
Thanks,
Ben
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