views:

522

answers:

3

Does anybody know of a way to lock down individual threads within a Java process to specific CPU cores (on Linux)? I've done this in C, but can't find how to do this in Java. My instincts are that this will require a JNI call, but I was hoping someone here might have some insight or might have done it before.

Thanks!

+1  A: 

IMO, this will not be possible unless you use native calls. JVM is supposed to be platform independent, any system calls done to achieve this will not result in a portable code.

questzen
I'm not concerned about portability.
Dave
@questzen: and what if the system call is made only if the Java program is found to be run on an OS supporting said call? The code would still be portable but simply not set any CPU affinity on other OSes. This is the one thing that always crack me up: people screaming "non portable code" as soon as you do some JNI or some Runtime.exec(). I've got program that do both and that work on Linux, Windows and OS X.
Webinator
It's not about whether to use or not use native calls but about whether the platform supports this "out of the box". @questzen is right that the JVM will not abstract access to this because it's not very platform neutral. You might be able to find third party libraries that will do it.
PSpeed
A: 

The JVM takes care of your threads ... binding threads would more likely cause performance degradation than improvements --i.e., you have absolutely no control over data locality -- why would you want to bind a thread to some core ? Also the Java way of doing things is thread pools -- so even if you had controll over data locality and you had bound your threads cores. If you make use of the pools your tasks will fly around to different threads.

Hassan Syed
I've got a couple of threads that are very I/O intensive, and some that are very CPU intensive. In C it was critical to isolate them from each other. Is this not the case with Java? I can't imagine how it can know that, so I can't imagine performance is better with a generic scheduling scheme than one in which I can give it some guidance/prior knowledge.
Dave
Have two layers then IMO, one for the C threads and one for the JAVA.
Hassan Syed
Sorry for the confusion - in the past I've worked in C, and this is what I've done. Now I have to work in Java, and I'm hoping to accomplish something similar. For the time being, C is not an option.
Dave
I doubt you can solve this problem without managing your IO threads externally.
Hassan Syed
I fear if your I/O routines are that intensive that you may run into memory bottle necks, etc. long before thread affinity becomes a critical element. Java can move objects around in memory to support its needs and this can kill the kind of stuff we really cared about in high-performance C/assembly code. If you move even your buffer management to native code then you might work around this... and have an 'in' into dealing with thread affinity as well. But some native code will be required either from you or a third party library.
PSpeed
A: 

It's not possible (at least with plain Java).

You can use thread pools to limit the amount of threads (and therefore cores) used for different types of work, but there is no way to specify a core to use.

There is even the (small) possibility that your Java runtime doesn't support native threading for your OS or hardware. In this case, green threads are used and only one core will be used for the whole JVM.

Hardcoded