sandra@utah-cs.UUCP (04/08/87)
The Lisp system I've been hacking on occasionally needs to use a large chunk of memory (like about 200K) for scratch storage during garbage collection. I would like to allocate this memory dynamically and free it when GC is complete, so that there will normally be some memory left over that the user could use to spawn an editor process (or whatever) from Lisp. I've heard that "malloc" works fine when repetitively allocating and freeing blocks of memory, but unfortunately it only takes a word argument to specify the size of the block to allocate -- far too small for my needs. I've also heard that "Malloc" (which does take a longword argument) has bugs that cause it to eat memory. So what's the right thing to do? I thought of maybe using the C functions brk and sbrk and bypassing malloc altogether, but being a Lisp hacker and not a C hacker, I'm not real sure if this will do what I want. Any suggestions? -Sandra Loosemore sandra@utah-cs.uucp, sandra@cs.utah.edu
braner@batcomputer.UUCP (04/09/87)
[] The C (and other) compilers can only give you what TOS yields, even if it is repackaged. So for example, Megamax C takes big (8K or larger) chunks from TOS, using Malloc(), when you do a malloc(), then manages those chunks on its own when you do more malloc()s. It never returns the space to TOS until you exit the program, even if you free() it all! I wonder if some ways of using Malloc() are safe. - Moshe Braner
apratt@atari.UUCP (04/09/87)
> [How can I get 200K dynamically, then free it?] > > -Sandra Loosemore > sandra@utah-cs.uucp, sandra@cs.utah.edu Use Malloc. If you Malloc a big block, use it, and Mfree it, all will be well. The problems with Malloc will arise when you allocate many blocks: no process should have more than 20 blocks Malloc-ed at a time. Brk, sbrk, and malloc won't help you, because they all manage the memory between your basepage and your stack pointer: this is all within one big block that was Malloc'ed when your process started up, and is unavailable to future applications anyway. Of course, you have to Mshrink before you can Malloc. But since you are planning to exec a child, I assume you have already done that. You don't always have to Mshrink before you can Malloc: The exceptions are when there is a "hole" in memory, created (for instance) when you start a shell, then start a TSR (like a ramdisk or print spooler), then leave the shell. The next process will load beyond the TSR, and the memory the shell was in will be a hole. Only explicit Malloc calls will use up this hole; programs will always load into the largest free block. /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/
jafischer@watrose.UUCP (04/10/87)
[] >... M. Braner writes: >I wonder if some ways of using Malloc() are safe. Could someone please summarize the Malloc() bugs? Just what are they? In the couple of programs I wrote that used it, I never had a problem, but if it was really dangerous and I was, say, going to write something for a mag or for commercial distribution or whatever, I'd really like to know the dangers. -Although it won't be too much of a problem for me since, after a great deal of wavering back and forth between Megamax and MWC, I've decided to go with MWC (if we can only get version 2 in the store before the next ice age). P.S. -please post quickly, as my account is about to die in a week or two, it being the end of term. -- - Jonathan Fischer (jafischer@watrose.UUCP) or ...watmath!watrose!jafischer