haitex@pnet01.cts.com (Wade Bickel) (04/12/88)
I am writing a fast memory alloc/dealloc system, and have found control
of chip vs. fast memory to be a puzzler.
Basically, in order to use the system, the programmer must register
allocation types. Registration is by mem-type and size and the registration
pointer is used in place of these fields in future requests.
(The registration function returns a pointer).
The puzzle is how to handle the case where CHIP memory is allocated in
place of FAST memory (ie: No FAST mem. was avail). This must be fast!
If the system is not too idiosyncratic I will make it public by summer.
Any sugestions/comments welcome,
Thanks,
Wade.
UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COMavery@puff.cs.wisc.edu (Aaron Avery) (04/13/88)
In article <2804@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > The puzzle is how to handle the case where CHIP memory is allocated in >place of FAST memory (ie: No FAST mem. was avail). This must be fast! Note: if the program requests FAST memory, and there isn't enough of it (or none) to satisfy the request, you do NOT allocate the memory, as you couldn't satisfy the request. You return a NULL pointer or whatever indicates failure. If the program requests FAST memory, you MUST give it FAST memory, just like if the program were to request CHIP memory, you MUST give it CHIP memory. I hope I didn't mis-interpret your message, but it shouldn't be handled the way you stated above. -- Aaron Avery (avery@puff.cs.wisc.edu) ({seismo,caip,allegra,harvard,rutgers,ihnp4}!uwvax!puff!avery)
cmcmanis%pepper@Sun.COM (Chuck McManis) (04/14/88)
In article <2804@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > The puzzle is how to handle the case where CHIP memory is allocated in >place of FAST memory (ie: No FAST mem. was avail). This must be fast! Well my allocator uses Exec nodes linked together to create 'remember' list. The following routines are implemented : (char *)mmalloc(mptr,size,attributes); /* just like alloc remember :-) */ SHORT mmark(mptr); /* Returns a memory "marker" */ BOOL mfreemark(mptr,int); /* Free's everything past the mark */ BOOL mfree(mptr,ptr); /* Free memory associated with this pointer */ BOOL mfreeall(mptr); /* Free all memory associated with this pointer */ The structure that this maintains looks something like this : struct mmallocstruct { struct Node mm_Node; /* Node list (14 bytes) */ int mm_Mark; /* Memory "marker" */ int mm_Size; /* Memory chunk size */ int mm_Pad; /* force longword alignment */ long mm_Data; /* First longword of data */ } The allocations actually allocate enough memory to store both the memory node and the data and return a pointer to the data. &(mm.mm_Data) Now it does "waste" 20 bytes each time you allocate something but it is useful. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.