On Fri, Aug 09, 2002 at 04:10:50PM -0400, Dan Sugalski wrote: > This has an implication for bytecode generation--it means that at > least one pointer-sized word at the end of the bytecode will get > altered at load time. This is OK--we can use it as the bytecode fixup > section. (I expect we'll find other things we need to use as fixups > along the way)
Are you *sure* you want to do it this way? My experience of Linux mmap is that if you map a file truly read-only (PROT_READ and MAP_SHARED) then no swap is allocated for the file. I assume that the physical RAM used to map the file in is also shared common to all processes (or threads) independently mapping the file in the same read-only way, but I don't know for sure. [This swap behaviour based on experimentation, not reading the source code. The assumption is because to me it appears an obvious optimisation, and is consistent with my understanding that the read only parts of an executable is only in RAM once, however many processes are running it] However, if the bytecode format requires that part of the file is required to be modified *in place* (as you appear to be saying) then the file needs to be mapped PROT_READ|PROT_WRITE|MAP_PRIVATE, which will mean that swap will be allocated for the whole file, even though only a small part of the file will need to be read-write. (probably over-committed swap, but possibly not. And even if it is over-committed swap, over-committing will only happen up to some multiple of real swap, so large amounts of parrot bytecode could start to eat into actual swap availability even though they will never need that swap space) I think it would be better if we have one level of indirection somewhere, so that the file can be mapped (or read in) read only, and whichever section needs to be read-write can be copied to other RAM and altered there. Or that section mapped in read-write. Or that section not mapped in, but read in conventionally. If I've misunderstood the bit about in place then the rest of this message is irrelevant. Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
