The fast-path overhead in this polling scheme (calling code at a specific memory location and returning from it, relying on remapping of the page the code us in to change its behavior from do-nothing to take-safepoint) is much higher than the currently-popular polling schemes of loading from a protect-able page or testing a bit in memory. It also has the downside of only working globally (no thread-specific safepointing capability like the one we use in Zing, or the one a HotSpot introduced in recent versions).
On Friday, May 29, 2020 at 11:25:02 AM UTC-7, Steven Stewart-Gallus wrote: > > Behold! > > I don't think this actually safely works though on x86 at least. > Pretty sure they use the virtual address for instruction caching and > debuggers have to do synchronisation when modifying from a different > address space. > > oh well. > > On Friday, May 29, 2020 at 9:46:38 AM UTC-7, Steven Stewart-Gallus 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. 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. >> >> 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. >> >> -- 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/1c4004a9-5236-4e2f-aa15-56599cb4fe3a%40googlegroups.com.
