But this is hardhats so you'd think it would be a good place for "close to the metal" discussions. :-)
Virtual memory is actually a pretty easy concept. Recall that in at the level of so-called machine language, variables are not identified by symbolic names, but by addresses in memory. Imagine two processes runnning exactly the same code. If the memory addresses were physical, then if one of them updated a variable's value, both would see the change. Thus, using physical memory addresses isn't really practical on a system supporting multiple processes. Instead, the (operating system) kernel provides each process with the illusion of its own private memory by allocating a "virtual address space" which is mapped by internal table to real (physical) addresses. [More technical stuff follows:] This is done by maintaing a table mapping pages (a page is usually 4KB) of virtual memory to pages of physical memory. Whenever a program makes a reference to main memory, the operating sytem identifies which page of virtual memory it belongs to and sees if it is currently loaded. If not, a "page fault" is generated, and control passes to the kernel (this is called a trap), the kernel then loads the actual physical page (if it has been written to disk in a process known as "paging") and possibly evicts another page of memory (typically using an algorithm known as "least recently used" or LRU). That way, many processes can use large amounts of virtual memory, possibly more than is physically available on the machine. A side effect of all of this is that processes do not really just execute machine code. If you initiate memory operation, at some level an interrupt will be generated by your code, allowing the kernel to step in and complete the process. That is yet another reason why memory operations are (relatively) slow. It also explains how it is possible that software can have the illusion of working with actual physical addresses when it really isn't. Typically, if you wanted to read the contents of memory at address a, you would (or your code would): 1. Place the address you wanted to read in a register 2. Issue an interrupt 3. Find the value stored at that address in another register Of course, step 2 is where all the interesting work happens. Your (and every other, assuming a uniprocessor) application process just stops. The kernel starts executing and fulfills your request by loading the value into the appropriate register. Finally, the kernel just "stops" and allows the application processes to resume. Of course, it's all a little more complicated than that, because all processes will want to use the same standard register (e.g., EAX on a Pentium), but they can't really. That's where the other main part of the kernel's job comes in. Each process will be allowed to exectute for a small amount of time, but eventually an interrupt will "halt" processsing. This is where the kernel steps in, saves off all the machine registers, picks another process to run, loads the values it believes are in those registers, and allows it to take over the CPU (for a time). In reality, the kernel is always there, occupying its own area of memory, and it carries on this whole charade to make each process "think" it's working with the real machine without any obvious outside intervention. (There are other operating system components sometimes thought of as part of the kernel and sometimes not, such as device drivers, file systems, network interfaces, etc., but I won't go into that here.) --- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > On Mon, 2005-08-29 at 16:36 -0500, Kevin Toppenberg wrote: > > [KSB] <...snip...> > > > So is this virtual memory maintained by by GT.M for its various > > processes. Or is this something that is done at a Linux level? > When > > a processess is JOB'd off in GT.M, I think it is given a separate > > process ID. But I assume that GT.M is coordinating it somehow. > > > > On the other hand, maybe this is more detail than I need to know. > > [KSB] The operating system maintains virtual memory, and makes it > available to processes via a number of primitives. This is more > detail > than you should need to know to use GT.M. I would be happy to try to > explain more details, but am somewhat pressed for time just now. > Maybe > a topic for over a pitcher at the next VistA Community Meeting? > > > > But let's change the topic. Why are you changing code in a > > production > > > environment? In order to maintain a robust production > environment, > > it > > > should be "locked down" and there should be a somewhat formal > > process of > > > change control by which changes are migrated from a testing > > environment > > > to a production environment. It is not generally recommended to > > change > > > code in a production environment as that code is being used, just > as > > it > > > is not considered a good idea to flush the radiator when driving > > your > > > car. > > > > Well, I took the original source file and backed it up. So I could > > > recover from an error. And I felt that if I had introduced a > > terrible > > error, that the error trap could catch it. And I felt that the > > chance > > of introducing a bad error were small, because I was just removing > a > > printout of time (while leaving the date) of a report. > > > > But your point is well taken. It would be better to have a > practice > > system. I guess I could have two such systems on the same server > -- > > or would I need a separate server. I am still used to Windows and > > it's registry that requires "installation". But I think with GT.M, > > it > > is just a matter of putting the code into a directory and then > > executing it. So I guess I could have a separate code base in a > > separate directory. But I wouldn't want them both listening on the > > > same port for CPRS connections. > > [KSB] You can have an unlimited (except by disk, RAM, and CPU > horsepower > - GT.M imposes no limits) number of application versions,database > files, > GT.M versions, etc. all on the same machine. Each process only needs > to > have $gtm_dist, $gtmgbldir and $gtmroutines set appropriately. For > our > banking application, we routinely have tens of environments on the > same > machine. > > In the classical implementation of the CPRS GUI, you would have each > environment listening at a different TCP port. > > With the "direct connect" CPRS GUI and GT.M V5.0-000, as long as you > can > tell from a client where it wants to connect (e.g., if this can be > determined from the IP address of the client by xinetd), you can > actually have them all listening to the same TCP port. > > -- Bhaskar > > > > ------------------------------------------------------- > 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
