> On 29 May 2020, at 17:46, Steven Stewart-Gallus > <[email protected]> wrote: > > Okay I have an idea. > I can't shake the idea you could do fun tricks with thread local executable > pages. > > The theoretically fastest way of safepoint polling is inserting a trap > instruction.
Under what basis are you making that assumption? Moreover, how do you know where to insert that instruction at a safe point in the code? The point of a safepoint is to bring code – wherever it is executing at the time – to the next safe place to stop. There are thousands upon thousands of these in native code generated by the JVM. How would you propose putting the trap instruction in all of them at one time? If you’re jumping to/from a memory location, just so you can jump back 99% of the time, then you’re going to pollute the branch prediction caches and likely introduce stalls in the pipeline. And to do this, the OS will need to verify whether the page (thread local or not) has execute permissions; in effect, doing a similar permissions check as the current ’test a page’ but much more. > But icache overheads dominate. If the icache is based on physical addresses > and not virtual ones then it should be possible to remap the page without > doing icache synchronization. > You should be able to have very fast safepoints by remapping the page. You can get even faster ones by flipping a bit in the page’s protection – no remapping needed then. And if you’re not changing the mapping itself, then you probably don’t even flush the cache line for that part of the page. > But I'm not sure there's a fast way to do a call/return from thread local > storage. And a call/return from a constant page still might not be faster > than just a load. > > TLDR: > Limited self modifying code without icache syncing stuff could be possible > with memory management tricks as long as the icache and other stuff is based > on physical addresses. Should be possible, but won’t be faster. Alex -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/63636C8D-6003-49E7-AE0E-1FF637CB5DBA%40gmail.com.
