Path: utzoo!utgpu!watserv1!watmath!att!pacbell!indetech!vsi1!apple!agate!sprite.berkeley.edu!elm From: elm@sprite.berkeley.edu (ethan miller) Newsgroups: comp.unix.cray Subject: Re: Malloc() under UNICOS Message-ID: <1990Sep11.074344.27891@agate.berkeley.edu> Date: 11 Sep 90 07:43:44 GMT References: <5931@castle.ed.ac.uk> <61360@lanl.gov> <729@garth.UUCP> Sender: usenet@agate.berkeley.edu (USENET Administrator) Reply-To: elm@sprite.berkeley.edu (ethan miller) Organization: Berkeley--Shaken, not Stirred Lines: 30 In article <729@garth.UUCP> fouts@bozeman.bozeman.ingr.UUCP (Martin Fouts) writes: %>>>>> On 28 Aug 90 16:51:52 GMT, ttw@lanl.gov (Tony Warnock) said: % %Tony> Generally, system actions such as MALLOC() cannot be speeded up. %Tony> These ususally require at least a trip through the operating %Tony> system. If the current location of the program in memory does not %Tony> have enough room for the program to expand, the job must be swapped %Tony> to disk and then put back into a larger slot. % %Malloc is not strictly a system operation, and doesn't always require %a trip through the operating system. The underlying system call is %brk/sbrk, which adds memory to (subtracts memory from) the end of the %data section of the program's address space. malloc/free/realloc %manage that memory once it has been allocated. On the Y-MP, at least, there are *always* two traps to the operating system. The malloc() call must use semaphores to guard the allocation routine, and manipulating them requires interrupts to be off so they can be set and cleared atomically. Because the interrupt mask can't be changed at user level, there are two (undoubtedly very short) traps to the system (it may be four--two to set and two to clear, but I don't remember, though I can check). This is in addition to any calls to brk() or sbrk(). ethan ================================= ethan miller--cs grad student elm@sprite.berkeley.edu #include {...}!ucbvax!sprite!elm Witty signature line condemned due to major quake damage.