[PATCH] Implement -XX:+BindGCTaskThreadsToCPUs for Linux (original) (raw)

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 oslinux.cpp (distributeprocesses() and bindtoprocessor() ) 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 ossolaris.cpp. In particular assigndistribution() is almost 1:1 copy (except for the type diff processort 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 pthreadgetaffinitynp() does not work, it seems likely that the following call to pthreadsetaffinitynp() 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/linuxgcworkers/**webrev.00/<http://cr.openjdk.java.net/rkennke/linuxgcworkers/webrev.00/> Kind regards, Roman

More information about the hotspot-dev mailing list