Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!agate!bionet!csd4.milw.wisc.edu!mailrus!iuvax!purdue!decwrl!sgi!scotth@harlie.SGI.COM From: scotth@harlie.SGI.COM (Scott Henry) Newsgroups: comp.sys.amiga.tech Subject: Re: memalign (can it be simulated?) Message-ID: <25616@sgi.SGI.COM> Date: 26 Jan 89 23:26:54 GMT References: <5471@bsu-cs.UUCP> Sender: daemon@sgi.SGI.COM Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 23 From article <5471@bsu-cs.UUCP>, by jbwaters@bsu-cs.UUCP (J. Brian Waters): > In article <0164.AA0164@julie>, mcr@julie.UUCP (Michael Richardson) writes: >> >> I have discovered that the Manx malloc is a fake - is uses a 40K >> arena which is allocated at run time regardless of how much malloc'ing > > How did you determine this? The source to Manx's malloc shows it calling > lmalloc which in turn calls AllocMem with the size of your request plus room > for a tag to allow the clean up routine to free it on exit. > > -- > Brian Waters !{iuvax|pur-ee}!bsu-cs!jbwaters > uunet!---/ I turns out that Manx has TWO malloc()s... the "normal" one that (eventually) calls AllocMem() each time, and one in heapmem.o which works out of (defaults to) 40KB chunks (this one includes a realloc()). If you don't link in heapmem.o you get indirect AllocMem() calls. BTW, I don't understand why Manx only includes a realloc() in heapmem.o. -- Scott Henry #include