Im trying to find real world examples where there might be more advantages to running threads on a single core vs spanning multiple cores.

Is there a cost to spawning threads across cores vs spawning in the same core.

How does java (or the os) determine when to allocate work on specific cores.

Finally, is there a way to specify explicitly that threads should run on a specific core or is this os level determined?

CodePudding user response：

If the logic is CPU bound, you only want a single thread per core because multiple CPU bound threads on the same core lead to waste due to context switching, cold caches etc. If the thread isn't CPU bound, but I/O bound, it could be beneficial to use multiple threads per core. But this depends on the architecture, e.g. in thread per core architectures like Seastar/Scylla, you still want a single thread per core.

Java doesn't do anything to determine how threads get mapped to cores. That is a task of the OS since Java threads are tied to a native thread.

In Java, there is no out-of-the-box solution to pin threads to cores. But you can use taskset for that or use one of Peter Lawrey's libraries:

https://github.com/OpenHFT/Java-Thread-Affinity

CodePudding user response：

How does java (or the os) determine when to allocate work on specific cores.

Currently in Java implementations based on OpenJDK, Java threads are mapped one-to-one with host OS threads. So the host OS on each platform (macOS, Linux, BSD, Windows, AIX, etc.) schedules each Java thread for execution on which core as it sees fit.

We as Java programmers have no direct control over when our Java thread is scheduled for execution time. Nor do we control which core performs the execution.

is there a way to specify explicitly that threads should run on a specific core

No, not in Java.

Is there a cost to spawning threads across cores vs spawning in the same core.

We cannot restrict our Java threads to specific cores. So the second part of your question makes no sense.

As for a cost to spawning threads, yes there is a significant cost in current Java. Threads currently use quite a bit of memory (stack allocations) and CPU time (CPU core can sit idle while Java code blocks).

Project Loom is an effort to greatly reduce this cost. The main thrust of their efforts is virtual threads, also known as fibers. Experimental builds of Project Loom technology are available now, based on early-access Java 18. To learn more, see videos of recent presentations and interviews done by members of the Loom team such as Ron Pressler and Alan Bateman.

To learn much more on threading in Java, read this excellent book by Brian Goetz et al.: Java Concurrency In Practice.