lua rom-ability

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

lua rom-ability

Jay Carlson
[please excuse the lack of proper reply; I'm reading the list via egroups
while my mail host is down :-( ]

I've been thinking about how to make Lua more rom-friendly.  In particular,
I'm interested in making as much stuff as possible live in the read-only
text segment on Unix boxes.  Anything in the text segment is sharable across
all processes running from the same executable/library; anything that gets
allocated in the heap can't be shared.  On machines with copy-on-write,
stuff in the initialized data segment is sharable until it's written to;
machines without copy-on-write can't share anything in initialized data.
IIRC, the GBA is (sadly) an mmu-less ARM.

This sharing is important on the low-memory Linux boxes I work on, like the
Agenda VR3 and the VTech Helio; there's only so much RAM to go around, and
there's no swap.

The big target for me is tolua.  tolua allocates lots and lots of tables and
strings.  There's around 120k of heap (measured by gcinfo) before any user
code in my fltk lua binding runs.  Ideally, I would like to put all of those
strings and tables into pre-generated const structures.  This could have the
additional advantage of keeping the garbage collector from having to scan
those tables; they're effectively immutable and immortal once built now
anyway.

I turned the embedded bytecode generated by tolua from unsigned char[] to
unsigned const char[]; this moves the bytecode arrays from initialized data
into the text segment.  (This shouldn't make much actual difference since
these arrays won't be modified and should remain shared, but I feel better
about guaranteeing they're in text.)  Oh, and I moved a couple of static
buffers in libtolua onto the stack with auto; this is the right thing for
me, but it may not be for people on machines with tiny stack limits.

Since those bytecode arrays are going to stick around forever, it would be
nice if as much of them as possible was used directly, rather than copying
piecewise into heap.  I don't know how possible this is with the current VM
design, but I could imagine functions just using a start/extent pointing
into these blocks in this case.

By the way, the issue of better rom-ability/text sgement sharing is a big
problem for all dynamic languages.  I ran into this in a big way in Squeak,
but smaller versions of it exist in basically everything but
C/C++/Fortran/Ada-style static languages.  Don't get me started about Java.

Jay


Reply | Threaded
Open this post in threaded view
|

Re: lua rom-ability

Luiz Henrique de Figueiredo
>I've been thinking about how to make Lua more rom-friendly.

I'm interested in this too.

>I turned the embedded bytecode generated by tolua from unsigned char[] to
>unsigned const char[]; this moves the bytecode arrays from initialized data
>into the text segment.

Nice tip! I've updated bin2c to reflect this.

>Since those bytecode arrays are going to stick around forever, it would be
>nice if as much of them as possible was used directly, rather than copying
>piecewise into heap.  I don't know how possible this is with the current VM
>design, but I could imagine functions just using a start/extent pointing
>into these blocks in this case.

I've thought about this but haven't found a good solution.
If *all* your bytecode arrays are static, then you may be able to change
lundump.c to reflect this. For strings, I think it's enough to set
ts->marked to FIXMARK. You'll have to change lgc.c to support FIXMARK for
other values.
--lhf