[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
