lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sunday 03 July 2005 02:00, glenn-edgar@onyxengr.com wrote:
[...]
> The private heap which was used
> was taken from the back of the K&R C book.  Each memory block had a 16 byte
> overhead.

Unless those 16 bytes are mostly used for debugging, you're being ripped off, 
I'm afraid. For an allocated block, the overhead should be exactly four bytes 
--- the size of the block, and depending on your application you might not 
need that (if the app keeps track of the size of blocks itself, for example). 
I don't know the K&R algorithm but you can probably do better.

[...]
> 2.  The utilization of the heap was around 50%.  This implied that there
> were a significantly small objects being allocated???  This is a problem
> with C++ and special heaps are designed to solve this problem.

Having a better allocator might help here, as it definitely sounds like you 
have a memory fragmentation problem. I'd suggest doing a brief search of the 
literature, and then using BSD's libc allocator --- the license should be 
acceptable and the algorithm should be good.

[...]
> Are
> there any garbage collectors now or currently planned that will allow lua
> to operate in that area?

IIRC (and I possibly don't) you *cannot* run a hard realtime system with a 
garbage collector. The problem is that there is no (short) upper limit on how 
long it takes to do a garbage collection and since you can potentially run 
out of memory at any point, your worst-case latencies are going to suck.

That said, there are tricks you can do: partial collecting, incremental 
collecting, background collecting, all that kind of thing. However, they do 
not *solve* the problem, only ameliorate it. If you have a fast enough 
processor, you can get away with it... most of the time. If you require 
*truly* hard real-time, with low latencies, I suspect you're doomed if you 
use Lua.

-- 
"Curses! Foiled by the chilled dairy treats of righteousness!" --- Earthworm 
Jim (evil)

Attachment: pgpONO_EFkhnw.pgp
Description: PGP signature