Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!alice!pereira From: pereira@alice.UUCP (Fernando Pereira) Newsgroups: comp.lang.prolog Subject: Re: GC triggering and stack limit checking by MMU hardware Keywords: GC, stack, heap, MMU Message-ID: <11085@alice.UUCP> Date: 24 Jul 90 17:47:35 GMT References: <1990Jul19.151524.22544@diku.dk> <3260@swi.swi.psy.uva.nl> <11079@alice.UUCP> <3261@swi.swi.psy.uva.nl> Reply-To: pereira@alice.UUCP () Organization: AT&T, Bell Labs Lines: 65 In article <3261@swi.swi.psy.uva.nl> jan@swi.psy.uva.nl (Jan Wielemaker) writes: >Computers and operating systems are (should be) designed to make life >easier for the user and programmer. Fernando Pereira claims that the >overhead of stack shifting and stack overflow checks is not very large, >that this schema is much better portable and that it is less critical >to OS errors. All these arguments are correct. There is another reason >for which I don't like them. I do not open /dev/rxy0c to read and write >files because I do not trust the OS disk cache and file system handling. >Instead, I tend to use open(), read(), write() and close(). The difference is that the interface offered by system calls such as open() is part of the specification of the OS and so can be relied upon, whereas the continuability of a SIGSEGV is not and thus cannot be expected to exist in all implementations of Unix. Furthermore, even for a particular implementation, the signal may be continuable in certain circumstances but not others. As Guy Harris pointed out in a previous message, OS/machine designers are free to do here whatever they want, since the specification (such as it is) does not require continuability. My point was not that some *possible* OS could not support the proposed use of address exceptions, but that a widely used versions of the Unix OS do not. I was talking about *current* engineering choices, not about OS design. > - I do not have to think where to do stack overflow checks or > how to do them cleverly. [Question: how do you know how > much will be written on the trail before the next point > where you can savely do a stack shift?] Except for the general unifier, which would need to do the test every N'th time through its main loop (N some appropriate margin), a safe upper bound for # of trail entries can be computed for each clause. Furthermore, the general unifier must be made interruptible anyway, to allow other asynchronous signals or some desirable support for multi-threading. > - I do not have to write a stack shifter, nor think about when > to call this thing and how much to grow the stacks. For any > such parameters there always are programs for which they have > the wrong value. It's not *that* hard! I've designed and used stack shifting schemes for the last 12 years without being severely bitten by them. The crucial point is to use a (simple) adaptive algorithm to set expansion factors. > - If stack shifts were the only thing I wanted, I would not be > considered keeping track of references to the stacks (from > the virtual machine, foreign language code, etc.) as the stack > does not move. [Unfortunately I need to keep track of all > these things for the garbage collector]. You said it. You need that info for GC anyway. >Having access to the MMU and the possibility to return from the SEGV >handler I save all the research and programming effort for this. You are trading off language implementation effort to OS design and implementation effort. Unfortunately, one's ability to influence OS design to address all our particular needs seems rather limited, and after 15 years and involvement in several Prolog implementations I have learned painfully that relying on more than the 10% most used portions of an OS (you know, those that are used 90% of the time (-:)) is very dangerous for portability and reliability. Fernando Pereira 2D-447, AT&T Bell Laboratories 600 Mountain Ave, Murray Hill, NJ 07974 pereira@research.att.com