Re: RES: FW: srlua extension to run with glued zip file

[Jay Carlson <nop@...>]

André de Leiradella wrote:
> > I'm confused.  Why don't you just use the linker to put in the data
> > that you want?  The most portable way to do this is just stuff
> > everything into a const char[] and compile it.  If you want to skip
> > the octets->.c->.o overhead I suppose you could use objcopy to go
> > directly from octets->.o, or use a linker script for more control.
>
> One problem with that is that your char[] array will seat in RAM even
> after it has been compiled by Lua, which looks like a waste. Reading
> from somewhere (a file, a chunk of data at the end of the executable or
> a Windows resource, be them compressed or not) does not waste memory.

That's not true.  On any modern desktop or server system, executables 
are demand-loaded.  Anything read-only and only touched once, like that 
const char[], is an good candidate for the OS to just drop, in the same 
way that it drops caches of files.  Files hang around in memory after 
you read them too...

This does depend on a little on OS cache tuning.  Some kernels 
prioritize retaining mmap'd pages (like from executables) over retained 
caches of files.  But it's only a matter of degree.

I suppose you could provide a stronger hint to the kernel by calling 
madvise, or munmap the data after you were done.  You'd have to be 
careful how you set up the latter of course.

My first real C programming experiences were on the Amiga and MS-DOS 
where what you said is true.  I continue to find the physical memory 
usage on demand paged operating systems to be unintuitive.

Jay