For this to work, all of writes, removing and setting page write permissions and handling exceptions must be sufficiently cheap. The exception handler then checks and causes the VM to check for events. So the heartbeat changes the guard page's permissions to take away write permission and cause an exception. Modern professors have write buffers so the write has very low cost (because it is never read) and is effectively free. In the HotSpot Java VM, if the platform supports it, a frame building send writes a byte to a guard page. The heartbeat simply sets the stack limit to the highest possible address to cause a stack limit check failure on the next send, and the stack check failure code checks if the stack limit has been set to the highest dress and calls the event check instead of handling the stack page overflow. In Smalltalk VMs which do context-to-stack mapping it is natural to organize the stack as a set of pages and hence to have frame building sends check a stack limit (guarding the end of the page). One gets a regular event check frequency at very low cost. The natural solution is a heartbeat thread, and this is used in a number of VMs. The system didn't check for events very often. What was happening was that the large integer primitives were taking so long that the counter took many seconds to count down to 0. One day I was doing something which invoked lots of long-running large integer primitives and I noticed that when I tried to interrupt the program it took many seconds before the system stopped. Consequently there was an enormous frequency of event checks, until, that is, ione did something that reduced the frequency of frame-building sends. This counter was initialized to 256 (IIRC). in the jitted machine code that activated a Smalltalk send), and when this counter went to zero the VM broke out and checked for events. Instead there was a counter decremented in every frame-building send (i.e. When I started working on the VisualWorks VM (HPS) in the '90s it had no heartbeat (IIRC, it might have only been the Windows VM that worked like this). I hope I've explained above that I expect the drawbacks will be intermittent failures of external code.Īs a footnote let me describe why we use a heartbeat at all. > Also, what would be the drawbacks besides an increase on the vm size? > The code in sqUnixHeartbeat.c is not a lot nor very complex, it should not be difficult to do. Whatever you do in the short term to deal with these problems I'll support, but in the long term we simply want a threaded heartbeat without needing to install anything. Having to install a file in /etc just to be able to use a thread is insane (and AFAICT unique to linux). It causes hard to debug issues with external code, has to be turned off and on around fork. To summarize, the itimer heartbeat is to be avoided as much as possible. Then the file installation would be unnecessary. Instead one can only use the thing if one has superuser permissions to install a file in /etc, just to use a thread of higher priority than the main one.Īn alternative might be to lower the priority of the main thread. Were it that the vm merely had to detect whether it could use the threaded heartbeat then things would be easy. I had to implement the itimer heartbeat to get Qwaq forums running on Linux running pre 2.6 kernels, but had many other problems to solve as a result (ALSA, database connects). Why linux erected this mess in the first place is something I don't understand. Neither Windows nor Mac OS X requires such nonsense, and a threaded heartbeat is used on those systems without any issue at all. The real issue is that linux's requirement that thread priorities be set in per-application file in /etc/security/limits.d (IIRC) is a big. Since Pharo is becoming more reliant on external code it may impact us more going forward. The itimer interrupts long-running system calls, which means that things like sound libraries break (at Qwaq I had to fix ALSA to get it to work with the itimer heartbeat). The issue is that the itimer mechanism is problematic, especially for foreign code, and is therefore a stop gap. I think it's a fine idea but it isn't really the issue. > What do you think about having a VM that manages that as an argument provided when we launch the VM? This would add some flexibility that we don't have right now because we make the decision at compile time. It somehow bothers me that there are different compiled artifacts, one per option. > I was checking the code in sqUnixHeartbeat.c to see how the heartbeat thread/itimer worked. On Jan 6, 2017, at 6:44 AM, Guillermo Polito wrote:
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |