Hi,
No an executable is not necessarily all loaded into memory upon startup.
In general an OS will allow one to modify the file corresponding
to a running executable although one can usually sequence the operations
to avoid this, for example during patching.
http://en.wikipedia.org/wiki/Memory-mapped_file
http://www.linuxhq.com/guides/TLK/mm/memory.html
Linux uses demand paging to load executable images into a process's virtual memory. Whenever a command is executed, the file containing it is opened and its contents are mapped into the process's virtual memory. This is done by modifying the data structures describing this process' memory map and is known as memory mapping. However, only the first part of the image is actually brought into physical memory. The rest of the image is left on disk. As the image executes, it generates page faults and Linux uses the process's memory map in order to determine which parts of the image to bring into memory for execution.
Scott
On Fri, 6 Mar 2009, Carlos Simmerling wrote:
> I know this was a problem on SGI machines under IRIX, since it would
> often crash the job. I agree with Ross, best to be safe.
On Thu, 5 Mar 2009, Robert Duke wrote:
> There may be some system dependencies on actual access to the executable. In
> old systems for sure, the executable would be paged in from disk as needed, so
> overwriting could cause grief (and often was not permitted - there are various
> ways this was handled, and it was filesystem/os dependent). If I were doing
> this, just to insure sanity, I would install in a different directory and
> switch when nothing is up. I have not looked at this issue for 20 years, but
> better safe than sorry is my basic attitude.
On Thu, 5 Mar 2009, Ross Walker wrote:
> This is 'in my experience' operating system dependent. In theory replacing
> the executable with another one while that executable is running should not
> cause a problem. I.e. the executable that was present has been loaded into
> memory. However, this is not always true and certainly isn't true in the
> case of shared libraries like MKL etc. If you link these shared and then
> change them during a run you can all sorts of problems.
>
> The same can be true of the executable. I have certainly seen problems in
> the past on IBM AIX where replacing the executable would ultimately crash
> the job since IBM didn't necessarily load the entire executable into memory.
> I have not seen this problem on Linux although that does not of course mean
> it doesn't exist.
>
> Short answer is if the job is still running okay you are probably fine. I
> doubt it will give the wrong answer because you moved / updated / removed
> the executable but rather would just crash with some error.
>
> In general when running very long runs (where I don't want to keep
> restarting etc) I place the statically linked executable in the same
> directory as my run script. That way I don't inadvertently modify it.
>
> All the best
> Ross
>
> > -----Original Message-----
> > From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
> > bounces.ambermd.org] On Behalf Of Lachele Foley
> > Sent: Thursday, March 05, 2009 3:14 PM
> > To: AMBER Developers Mailing List
> > Subject: [AMBER-Developers] Update question
> >
> > I'm pretty sure the answer to this is "it shouldn't cause trouble", but a
> > user asked me, so I want to be sure.
> >
> > Let's say someone is running a really long job using amber11's sander or
> > pmemd or some other routine likely to be run for a really long time. Is
> > there any chance that updating amber11 will cause any trouble for that
> > run? I think no. I think these programs, like most others, find all the
> > data they need at the start, and the executable is loaded into active
> > memory, and the version of the program on the disk is ignored thereafter
> > until the program is called again. Yes? No?
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Mar 18 2009 - 01:20:03 PDT
