aj@zyx.UUCP (Arndt Jonasson) (03/25/88)
In the book 'The design of the Unix system', by Maurice J. Bach, the following is said in the section about 'brk': "If the process is calling 'brk' to free previously allocated space, the kernel releases the memory; if the process accesses virtual addresses in pages that it had released, it incurs a memory fault." My interpretation of the word "releases" is: the process gives up the right to use those pages -> they are no longer owned by the process -> they can be assigned to another process that wishes to allocate more memory. Are there Unix implementations that do this right? My faith in Unix (small as it was) was considerably reduced when I found that of two Unix implementations that I tested, both got it wrong. What is wrong? In this context, it is wrong for the kernel not to make the 'released' pages accessible to other processes. The pages are kept somewhere, and only really released when the process exits. One of the two implementations is 4.2BSD. Since the BSD system where I tested this can handle a considerable number of processes before swap space becomes scarce (swap space 140 Mbytes), it probably seldom gets to be a problem. On a workstation implementation, however, it is quite another matter. Granted, the book describes System V, and a look in the manual page for 'brk' on 4.2BSD reveals that nothing at all is said about calling 'brk' so that the allocated space shrinks. One System V brk manual page (which may not be the 'vanilla' one) says that the allocated space is 'nominally decreased'. This at least describes the system's behaviour. However, the issue is not whether the implementation conforms with the documentation, but rather whether what the system does is 'right'. In the case of BSD, it turns out not to be an ordinary bug or oversight; in the source code (vm_drum.c), the following is to be found (I hope this is a small enough piece as not to constitute breach of any non-disclosure laws): /* * Expand or contract the virtual swap segment mapped * by the argument diskmap so as to just allow the given size. * * FOR NOW CANT RELEASE UNLESS SHRINKING TO ZERO, SINCE PAGEOUTS MAY * BE IN PROGRESS... TYPICALLY NEVER SHRINK ANYWAYS, SO DOESNT MATTER MUCH */ vsexpand(vssize, dmp, canshrink) I consider this a grave misfeature. I am interested in knowing whether any Unix implementors have made the effort to really release memory, and, what your suggestions are to circumvent this problem on systems where they have not. -- Arndt Jonasson, ZYX Sweden AB, Styrmansgatan 6, 114 54 Stockholm, Sweden email address: aj@zyx.SE or <backbone>!mcvax!enea!zyx!aj
shankar@hpclscu.HP.COM (Shankar Unni) (03/29/88)
/ hpclscu:comp.unix.wizards / aj@zyx.UUCP (Arndt Jonasson) / 7:01 am Mar 25, 1988 / > My interpretation of the word "releases" is: the process gives up the > right to use those pages -> they are no longer owned by the process -> > they can be assigned to another process that wishes to allocate more > memory. > > Are there Unix implementations that do this right? My faith in Unix > (small as it was) was considerably reduced when I found that of two > Unix implementations that I tested, both got it wrong. Not necessarily. There are architectures in which different processes will get (unconditionally) non-overlapping *virtual* memory spaces. In HP's Precision Architecture ( our RISC, for those who don't care for Marketese ), virtual addresses are 64 bits each: a 32-bit "space-id" (unique to each process - each process gets one or more "spaces" exclusively) and a 32-bit offset within the space. Of course, this whole address is mapped to a 32-bit physical address, but virtual space given up by a process cannot be allocated to another process. Also, there are per-process mapping tables. Of course, what you're arguing is that when a process brk's downwards in such a layout, all those pages should be unmapped from the mapping tables, making it illegal for the process to access them. I won't argue with you there. But this would happen, if at all, only on a page-by-page basis, so, for instance, decrementing brk by 20 and then accessing a char that is 19 bytes beyond won't necessarily generate a fault.. --scu
amos@taux01.UUCP (Amos Shapir) (03/30/88)
NSC's implementation of sysV does it right - so right, that we discovered a bug in /bin/sh that had been there for years, but never surfaced in implementations which did not really released sbrk-ed pages. (sh used to release space that was still in use). -- Amos Shapir (My other cpu is a NS32532) National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 amos%taux01@nsc.com 34 48 E / 32 10 N