Re: kernel stack challenge

["Patrick J. LoPresti" <patl@users.sourceforge.net>]

Jesse Pollard <jesse@cats-chateau.net> writes:

> To prevent the memory leaks you have to have a mark and sweep GC.
> Which still doesn't prevent circular loop leaks.

What are you talking about?  A mark/sweep GC certainly DOES collect
circular data structures.

Perhaps you are thinking of reference counting GCs?

> Then you need a memory pool allocator to relocate all valid
> references.

Now you seem to talking about stop and copy, which is something else
again.  And it is not required to avoid memory leaks, although it does
fix fragmentation.

> The combination is NOT small. BTW, the JVM suffers from circular
> loop leaks too, since all it uses is reference counting (for speed).

Which JVM are you talking about?  Every JVM I know of uses a real
garbage collector, not some reference counting hack.

Perhaps you are thinking of Perl?

Sergiy is right: A Lisp interpreter and runtime can be quite small and
efficient.  And it can provide a secure "sandbox" for running
questionable code safely.

Whether it is a good idea in this context is another question.  My
concern is that it is hard (impossible?) to bound the memory
consumption, both stack AND heap, of a Lisp program statically.  I
would expect such bounds to be important for an implementation of a
security model.  With a Lisp program, you cannot be sure under what
conditions it will exceed whatever space you have alloted for it.
Which means that, although it cannot crash the kernel, it cannot be
used to build a reliable system, either...

 - Pat