Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!voder!pyramid!comdesign!ivucsb!dan From: dan@ivucsb.UUCP (Dan Howell) Newsgroups: comp.sys.amiga.tech Subject: Re: Task KILL for Amiga Message-ID: <505@ivucsb.UUCP> Date: 30 Jan 89 20:03:56 GMT References: <3716@crash.cts.com> <10908@s.ms.uky.edu> <5713@cbmvax.UUCP> <10926@s.ms.uky.edu> <32094@tut.cis.ohio-state.edu> Reply-To: dan@ivucsb.UUCP (Dan Howell) Organization: The Audio Club at UCSB, Isla Vista, California Lines: 24 In article <32094@tut.cis.ohio-state.edu> Jeff Martens writes: |In article <10926@s.ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes: | [ stuff deleted ] |>It also seems to me that resources could be tracked with bitmaps. Where |>is the serious speed/memory degradation? |OK. Let's keep track of every byte of RAM in the Amiga. If we allow |for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte. |The alternatives are to increase the granularity of our map or keep it |on disk. It won't fit on a floppy, and even on a hard drive |performance would be hampered. If we increase the granularity to, |say, a "paragraph" (Intel's term for 16 bytes if memory serves), then |8MB is thought of as 512k paragraphs, so the bitmap can fit in 64kB. |This is still a considerable amount of memory, and results in wasted |space if the user doesn't use memory in 16 byte chunks. Seems to me you could use a concept known as private heaps, where a process would allocate a heap in chunks of 1k or so (which the OS would keep track of with a bitmap). Then the process would be able to allocate small pieces of this heap at a time, and if it needs more than 1k, the OS automatically increases the size of the heap. Then when the process dies, the OS automatically deallocates the heaps associated with that task. -- Dan Howell <...!apple!comdesign!ivucsb!dan>