Hmm...I'll have to look into this further. I thought copy on write was supported by newer Unix kernels, but I may simply have been mistaken.
--- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > [Warning: Arcane technical details follow. Hit the DELETE key if it > is > not of interest.] > > The default is for GT.M on all platforms to dynamically link code > into > heap space, which is process private. The reason GT.M does not do it > the C way is that there must be a way to provide a way to link (via > ZLink) a new version of a module that has been previously linked. C > doesn't provide for new functions of the same name to replace > existing > functions in active processes. > > If a routine XYZ is in a shared .EXE OpenVMS file, and a ZLink "XYZ" > is > executed, OpenVMS provides a "copy on write" feature, that allows > GT.M > to remap a page in the address space from a shared virtual memory > page > to a process private virtual memory page, and then to modify it. As > long as I have been associated with GT.M (since 1/1/1995), GT.M has > had > the ability to share object code between processes on VMS. > > UNIX/Linux does not (or did not - I have not checked lately whether > this > is still the case) have the ability to remap a page in the virtual > address space of a process from shared virtual memory (as in a shared > library or an shared executable file) to process private virtual > memory. > Thus, GT.M on UNIX/Linux did not traditionally support the sharing of > object code by placing it in shared virtual memory. > > A few years ago, we came up with a somewhat innovative way to create > object modules where on a ZLink, we did not need to modify what had > been > linked. We came up with a way to keep everything that needed to > change > on a relink on the heap, which meant that there was no longer a need > to > remap pages of the address space from shared to process private. > However, implementing this feature is in code that is specific to > each > platform, since it requires very low level changes to the structure > of > object modules and how they are linked. We received funding to > implement this for GT.M on IBM pSeries AIX, HP PA-RISC HP-UX and HP > Alpha/AXP Tru64 UNIX. So, today, we have the ability to put object > code > generated by GT.M into shared libraries on those platforms, but not > on > Sun SPARC Solaris and x86 GNU/Linux. > > We currently have received funding to implement the functionality on > Sun > SPARC Solaris, and so that work is in the development pipeline. We > are > looking for funding to implement it for GT.M on x86 GNU/Linux. [The > one > down side to an open source free software based business model is > that > it is harder to do work "on spec" funded by current or prospective > license revenue, and project funding is forced to be more > transparent.] > > >From a practical point of view, this makes no difference because the > only real inefficiency is in virtual memory usage. Real memory is > cheap > and getting cheaper, and virtual memory is even cheaper yet (since > except for the working set, the rest of process virtual memory can > sit > on disk). Unless you want to deploy thousands, or perhaps tens of > thousands, of users on a single computer system, cheap RAM and cheap > disk rule! [Languages like Java, for example, don't even attempt to > put > object code in shared libraries or shared executable images.] > > -- Bhaskar > > On Mon, 2005-08-29 at 15:50 -0500, Greg Woodhouse wrote: > > This surprises me a little. I'm certainly no expert on the Linux > > kernel, but I'm a little surprised that there would be a need for > > separate routines linking to the same code to maintain their own > > copies. Was this a design decision, or does it reflect a limitation > > of > > Linux (vs. say, OpenVMS or BSD Unix)? > > > > --- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > > > > > Kevin -- > > > > > > In response to the first implicit (e.g., Do PQR^XYZ for a routine > > > > that > > > is not currently linked in the process address space) or any > > explicit > > > request to access a routine (e.g., ZLink "XYZ"), GT.M will search > > for > > > that routine as specified by the $ZROutines search path, compile > > the > > > routine if needed (if the .o file is older than the > > corresponding .m > > > file), bring it into the process virtual memory and link it into > > the > > > process address space. [Tangential side note for the technically > > > > curious: if the routine is placed in a shared library on > > Proprietary > > > UNIX platforms where this is supported by GT.M, or in a shared > .EXE > > > file > > > on OpenVMS, GT.M still links it into the process address space, > but > > > the > > > virtual memory is shared and so overall memory usage is more > > > efficient > > > than GT.M on x86 GNU/Linux.] > > > > > > > > > > > === > > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > > > > > "Perfection is achieved, not when there is nothing more > > to add, but when there is nothing left to take away." > > -- Antoine de Saint-Exupery > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing > > & QA > > Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
