3 ms·

Is there an affinity between a Java virtual thread and a CPU core?

2 points by ycuser20241126 2y ago

I believe (perhaps erroneously) that the OS keep a certain affinity between a native thread and a core, just to avoid cpu cache line trashing, or conversely to increase cache line hits. When a few carrier threads are jumping all over (well, under..) thousands of virtual threads, I fear there was a complete disregard towards cpu cache. But I hope I'm wrong. Has anyone ever read/heard/found that a carrier thread could be scheduled preferably on the core where the virtual thread was last ran, to spare the cpu cache from trashing?

pestatije 2y ago
there isnt unless you pin it...after a context switch the data in the cache is useless so it makes no difference whether you pin it or not (for this specific regard)
- ycuser20241126 2y ago
  I must be missing something from your comment. Afaik, the cpu caches are memory buffers to avoid reading from memory if at all possible. It's not the same as cpu registers. Some memory barriers like synchronized and other levels described in details with java 9 varhandles, must be doing tests for safety, but a context switch doesn't seem like a prescription to invalidate all cache lines. I admit I don't know everything about cpu architecture, but it would be overkill to do so. Imagine 2 threads minding their own business in distinct few kB areas of memory and those areas both fitting in the couple MB cache. Why would any cache line be invalidated? Unless there is a write, by another core, the cache line stays valid, afaik. So back to the question, I would think it is possible for the JVM to record in the VT the core of the carrier who last ran the VT, and pay attention this when later scheduling a VT on a carrier that already has affinity to the same core. Doesn't seem far fetch, but I can imagine the sudden increase in VT scheduling complexity when facing 24 cores with their list of carriers (although typically 1 carrier per core is allocated initially). Perhaps the upcoming years will do that.

pestatije 2y ago

there isnt unless you pin it...after a context switch the data in the cache is useless so it makes no difference whether you pin it or not (for this specific regard)

ycuser20241126 2y ago
I must be missing something from your comment. Afaik, the cpu caches are memory buffers to avoid reading from memory if at all possible. It's not the same as cpu registers. Some memory barriers like synchronized and other levels described in details with java 9 varhandles, must be doing tests for safety, but a context switch doesn't seem like a prescription to invalidate all cache lines. I admit I don't know everything about cpu architecture, but it would be overkill to do so. Imagine 2 threads minding their own business in distinct few kB areas of memory and those areas both fitting in the couple MB cache. Why would any cache line be invalidated? Unless there is a write, by another core, the cache line stays valid, afaik. So back to the question, I would think it is possible for the JVM to record in the VT the core of the carrier who last ran the VT, and pay attention this when later scheduling a VT on a carrier that already has affinity to the same core. Doesn't seem far fetch, but I can imagine the sudden increase in VT scheduling complexity when facing 24 cores with their list of carriers (although typically 1 carrier per core is allocated initially). Perhaps the upcoming years will do that.