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 cp

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.