How can I determine what core a Java thread is running on?

Question

I want to implement a CoreLocal map, which works just like ThreadLocal, only it returns a value that is specific to the core the current thread is running on.

The reason for this is that I want to write code that will take a job from a queue, but I want to give priority to jobs that will have their associated data already be in the same L1 cache as the thread picking the job from the queue. So, instead of one job queue for the entire program, I want to have a queue for each core and only when a queue is empty will a worker thread go looking at the queues of other cores.

Airliah

github.com/peter-lawrey/Java-Thread-Affinity – Decontrol

Sounds like you're really low on nanoseconds there. – Mcdougal

Do you have any guarantee that the thread won't be rescheduled to another core as soon as it has taken a job from the queue, making all this mechanic counter-productive? – Bryology

Q==Queue! Keeping a thread on a core with a hot cache is worth a lot more than nanoseconds (webtide.intalio.com/2012/12/…). I don't know how frequently or on what events threads can skip cores, but you have to assume that there is some affinity otherwise caches would just not work at all. – Airliah

@Airliah I wonder, if you could make some progress with CoreLocal or how it was finally solved. – Rosenberry

Answer 1

I don't think there is any call to get the current CPU currently exposed in the JDK, although it certainly has been previously discussed¹ and proposed as a JDK enhancement.

I think until something like that gets implemented your best bet is to use something like JNA (easiest) or JNI (fast) to wrap a native system call like getcpu on Linux or GetCurrentProcessorNumber on Windows.

At least on Linux, getcpu is implemented in the VDSO without a kernel transition, so it should only take a few nanoseconds, plus a few more nanoseconds for the JNI call. JNA is slower.

If you really need speed, you could always add the function as an intrinsic to a bespoke JVM (since OpenJDK is open source). That would shave off several more nanoseconds.

Keep in mind that this information can be out of date as soon as you get it, so you should never rely on it for correctness, only performance. Since you already need to handle getting the "wrong" value, another possible approach is to store the cached value of the CPU ID in a ThreadLocal, and only update it periodically. This makes slow approaches such as parsing the /proc filesystem viable since you do them only infrequently. For maximum speed, you can invalidate the thread-local periodically from a timer thread, rather than checking the invalidation condition on each call.

---

¹ Both the discussion and the enhancement request are highly recommended reading.

Washerwoman

Answer 2

There's a related linux question with no satisfactory answer (parsing top output doesn't count and the accepted answer doesn't work anymore). I thought that

/proc/<pid>/task/<tid>/sched

might give this information in a line like

 current_node=0, numa_group_id=0

but on my i5-2400 running 4.4.0-92-generic kernel, this line is always the same for all threads. I guess, "node" means a whole CPU (socket) and I have only one.

I could find no documentation on this, or missed it in this document.

---

However, I'm afraid that this obtaining this information could improbably help you:

• Reading from the proc filesystem may be too costly on the scale you're working on.
• Unlike ThreadLocal, your CoreLocal is not thread-safe: Migrating a thread to another core could spoil even trivial non-atomic operations like someCoreLocalField++. Suspending it would do it, too. So you'd need some atomics or thread-locals to get it working, which again may make it far too slow for what you want.

Rosenberry

Answer 3

probably you could check /proc/[pid]/status

These fields may be helpful:

Cpus_allowed: Mask of CPUs on which this process may run

Cpus_allowed_list: Same as previous, but in "list format"

Kasiekask

That's not the question – Hairsplitting