memory allocation in foreign function routines

[aoki@monet.Berkeley.EDU (Paul M. Aoki)]

We are running KCL under SunOS.  We are porting an application
from Franz LISP to KCL, but we have foreign-function code that uses 
malloc() frequently enough so that we don't want to use the malloc() 
in alloc.c, the one that operate in lisp memory. I mean, cdring down 
that one global list of blocks (malloc_list) to free() something when 
when the list is thousands of items long sounds like an ugly thing,
and throwing freed blocks back into the heap doesn't sound like
an ideal method of C memory allocation.

Now, KCL wants successive sbrk()s to simply extend its memory space.
This appears to mean that you really can't use the libc malloc(), 
which will also sbrk() and thus hose KCL.

The options appear to be:
	1. Write a C memory manager that works inside of big chunks
		of KCL-managed memory
	2. Rewrite the KCL memory manager (arggh)

I would like to have another option:
	3. Figure out some incredibly clever hack that will let us
		use libc malloc() without having to change KCL much

Has anyone else managed to kludge around this somehow?  I can't believe
we're the first people to build something using non-trivial foreign-function
code, code that's big enough not to want to use a toy malloc().

Does AKCL do memory allocation without requiring contiguous sbrk()s?
That would work, too.

Alternatively, if you *have* used the KCL malloc() and it isn't too awful,
please tell me that my fears are unfounded.

(If we can't do efficient C memory allocation, we will probably have to
use yet another !@#$%^ proprietary lisp....)
----------------
Paul M. Aoki
CS Division, Dept. of EECS // UCB // Berkeley, CA 94720		(415) 642-1863
aoki@postgres.Berkeley.EDU					...!ucbvax!aoki