quote:

---

> 1) What do the chile process 'looked like' after fork
> e.g. (using virtual memory address)
> "Parent process":
> - code memory address: 0x1000-0x2000
> - data memory address: 0x2000-0x3000
> after fork, is this what the child process looked like:
> "Child process":
> - code memory address: 0x3000-0x4000
> - data memory address: 0x4000-0x5000
> or?
> - code memory address: 0x1000-0x2000 (same as parent)
> - data memory address: 0x3000-0x4000

---

quote:

---

> 2) so do the OS do "rebasing" (just like loading a DLL in Win32 where
> the 'desired' memory address is not available) of the child process
> because the change in the memory address?

---

quote:

---

> 3) In case the child got it's new Code Memory, do some OS (vfork in
> *nix???) map the virtual memory address of the code memory to the SAME
> physical address?

---

quote:

---

>The fork() call duplicates the page tables and marks all of the
>child's pages as copy on write. This means that, initially, both code
>and data are mapped to the same physical memory as in the parent. If
>a page is written to by the child, that page will be allocated a new
>physical page to perform the write on. Code is read-only, so it will
>never be copied. The virtual address space is never changed.

---

quote:

---

> baronng@astri.org (Baron) writes:
>
>
> Neither. Both code and data stay at the same address.
>
>
> No.
>
>
> The fork() call duplicates the page tables and marks all of the
> child's pages as copy on write. This means that, initially, both code
> and data are mapped to the same physical memory as in the parent. If
> a page is written to by the child, that page will be allocated a new
> physical page to perform the write on. Code is read-only, so it will
> never be copied. The virtual address space is never changed.

---

quote:

---

> mru@kth.se (Måns Rullgård) wrote in message news:<yw1xhdyrotme.fsf@ford.guide>...
>
> Are you talking about the case of 'vfork' instead of the old/original
> 'fork' implementation?(i read from the faq of the newsgroup that vfork
> works like what you said, so i'd like to know the original
> implementation of fork)

---

quote:

---

> must call exec or _exit. The child is not allowed to change any data
> before doing one of these.

---

quote:

---

>
> Quoted from "Unix Programmer FAQ":
> -----------------------the FAQ-------------------------
> Some systems have a system call `vfork()', which was originally
> designed as
> a lower-overhead version of `fork()'. Since `fork()' involved copying
> the
> entire address space of the process, and was therefore quite
> expensive, the
> `vfork()' function was introduced (in 3.0BSD).
>=============
> So it seems that the 'old'/unimproved implementation of fork copy the
> ENTIRE memory space (including the code memory) when doing 'fork'
> in this case, do the OS 'rebase' the child?

---

quote:

---

>=============
>
> -----------------------Continue the FAQ-------------------------
> The basic difference between the two is that when a new process is
> created
> with `vfork()', the parent process is temporarily suspended, and the
> child
> process borrows the parent's address space. This strange state of
> affairs
> continues until the child process either exits, or calls `execve()',
> at
> which point the parent process continues.
>=============
> So, copy-on-write is used in fork...
> and vfork suspend the parent process...and if the child call execve,
> it works like 'fork' and can call "_exit" to exit right away

---

quote:

---

>=============
>
> So....the whole Virtual Memory Address space is different for
> different process?

---

quote:

---

> What i mean is that, in the case of "fork" - 2 processes actually
> using the same virtual memory address but different physical
> address....(as you said: "Both code and data stay at the same
> address")

---

quote:

---

>
> This conflict with my previous OS knowledge that the page table is a
> one-to-one mapping between the virtual address and the physicall
> address in the ENTIRE OS instead of "per-process"

---

quote:

---

>
> All the FAQ is trying to say is: Untill child is there parent can't run.

---

quote:

---

> This avoids race conditions when child and parent update the same
> physical memory. After child does exec or exit ('exit' would be really
> stupid in this case, why to vfork and then just exit?)

---

quote:

---

> the parent can continue working. So there's no copy-on-write
> here. And vfork does not work like fork in this case. Maybe it would
> be simpler to think of 'fork' as a mean to allow independent actions
> on the memory content of parent and 'vfork' as a mean to launch
> completely different process.

---

quote:

---

>=============
>So it seems that the 'old'/unimproved implementation of fork copy the
>ENTIRE memory space (including the code memory) when doing 'fork'
>in this case, do the OS 'rebase' the child?
>=============

---

quote:

---

>=============
>So, copy-on-write is used in fork...
>and vfork suspend the parent process...and if the child call execve,
>it works like 'fork' and can call "_exit" to exit right away
>=============

---

quote:

---

>So....the whole Virtual Memory Address space is different for
>different process?

---

quote:

---

>What i mean is that, in the case of "fork" - 2 processes actually
>using the same virtual memory address but different physical
>address....(as you said: "Both code and data stay at the same
>address")

---

quote:

---

>This conflict with my previous OS knowledge that the page table is a
>one-to-one mapping between the virtual address and the physicall
>address in the ENTIRE OS instead of "per-process"

---

quote:

---

> The fork() call duplicates the page tables and marks all of the
> child's pages as copy on write. This means that, initially, both code
> and data are mapped to the same physical memory as in the parent. If
> a page is written to by the child, that page will be allocated a new
> physical page to perform the write on. Code is read-only, so it will
> never be copied. The virtual address space is never changed.

---

quote:

---

> Måns Rullgård <mru@kth.se> spoke thus:
>
>
> Is this true of all *nix flavors? I know it's the case with Linux.
> Just wondering.

---

quote:

---

> Christopher Benson-Manica <ataru@nospam.cyberspace.org> writes:
>
>
>
>
> AFAIK, yes. Maybe some ancient versions are different.
>

---

quote:

---

> Then I have a question on windows DLL loading...
> as I know there are something called "rebasing" where the desired
> virtual memory address of a .DLL (can be set when compile) is not
> available, the OS needs to do a 'rebasin' by changing all the memory
> references in the code to a new memory base...
>
> if different programs (in the case of fork, 2 processes can use the
> same virtual memory which may points to different physical memory) can
> goes into the same memory address, why loading a .dll needs
> rebasing???

---

quote:

---

> time it is loaded, it will have to be relocated to use some other
> virtual memory addresses. Shared libraries in Unix systems are
> typically compiled to position independent code, meaning that there
> are no references to absolute addresses. These can be loaded at any
> address without any extra work.

---

quote:

---

> space on fork. They did not support VM anyway, so they had no choice,
> and for the same reason it is likely that MINIX did the same.
>
> Then came BSD, and they introduced VFORK because FORK became probitively
> expensive on large memory spaces; FORK was still there and still doing
> full copies, but now under VM the address space could be unchanged.

---

quote:

---

>
> At some point (these were the years when the history of Unix was most
> complicated!) VFORK acquired the copy-on-write semantics. Then FORK as
> it was became useless, and VFORK took completely over, including the name.

---

quote:

---

> originally, a is in virtual address 0x1000, physical address 0x21000
> after fork, both parent and child process still use the same addresses
> for both virtual and physical address
> after 1 or 2, parent points to 0x1000 / 0x21000,
> would child points to virtual: 0x1000 and physical: e.g. 0x31000???

---

quote:

---

> if so, why rebasing is needed for different .dll?!
> e.g.
> if dll X loads to virtual address 0x1000 / 0x21000, dll Y can still
> load to virtual address 0x1000 but different physical address (e.g.
> 0x31000)

---

quote:

---

> I am a bit confused on the virtual/physical memory usage...

---

quote:

---

> different memory addresses, it's needed when one process wants to use two
> DLLs that normally map to the same virtual address.
>
> Suppose I make a DLL, foo.dll that normally loads to virtual address
> 0x1000 and you independently make a DLL, bar.dll that normally loads to
> virtual address 0x1000 too. If a process has already map foo.dll and goes to
> map bar.dll, bar.dll needs to be rebased.

---

quote:

---

> Yep, it seems you are.

---

quote:

---

>
> is that a loaded .dll can be used by different processes?
> I remembered that i heard it before (as dll is no unloaded immediately
> after the process that use the dll ends...)
>
> so..is that
> 1)
> if process A loaded a .dll X and exit, .dll X won't unload
> immediately,
> and if process B start and load .dll X BUT the address used in .dll X
> don't collide with any other .dll(s) already loaded by process B, B
> will use the .dll X immediately
> 2)
> in case process A loaded a .dll X and exit, while process B already
> loaded another .dll(s) and collide with .dll X's VM address, .dll X
> will be rebased to other VM address, right?
> so, if process C then load .dll X again, and the address used by .dll
> X (rebased by B already) collides with the .dll(s) loaded by C, C will
> load another instances of .dll X and rebase it to the "free" virtual
> memory address.
> so there will be two instances of .dll X
>
> am I correct?

---

quote:

---

> Not really. There's no need to have 2 copies of DLL. I better say .so
> library, since I don't know for sure about DLL. The code would be stored
> in the same physical memory. But different processes may access that
> code at different virtual addresses.

---

quote:

---

> Andrei Voropaev <avorop@mail.ru> writes:
>
>
> This works only if the shared library uses position independent code.
> If it doesn't, all memory references in the code will have to be
> adjusted to point to the correct places. The library will have a
> relocation table listing all instructions using absolute addresses
> that need to be checked.

---

quote:

---

>
> Then I have a question on windows DLL loading...
> as I know there are something called "rebasing" where the desired
> virtual memory address of a .DLL (can be set when compile) is not
> available, the OS needs to do a 'rebasin' by changing all the memory
> references in the code to a new memory base...
>
> if different programs (in the case of fork, 2 processes can use the
> same virtual memory which may points to different physical memory) can
> goes into the same memory address, why loading a .dll needs
> rebasing???

---

quote:

---

> Unfortunately, because the code has pointers and addresses that
> point to the data, the code then needs to be modified on a per
> process basis to point to the different data segments which
> therefore means that the code does need to be copied and modifed
> (rebasing).
>
> This is a flaw of the microsoft OS. They insist on making their
> DLL use position dependand code, while Linux uses sharded libraries
> use position independant code. You might care to look these two
> concepts up on the web somewhere.

---

quote:

---

> If it doesn't, all memory references in the code will have to be
> adjusted to point to the correct places. The library will have a
> relocation table listing all instructions using absolute addresses
> that need to be checked.

---

quote:

---

> this is confusing
> 1) the relocation table is used at RUNTIME?

---

quote:

---

> e.g. if process A loaded the .dll at memory location 0x1000,
> while process B's 0x1000 is NOT available
> do you mean there is relocation table for process B e.g. (0x3000 is
> free for process B, but the .dll is loaded to 0x1000 by process A, so
> when ever process B reference the dll, the relocation is simply map
> 0x3000 (VM address of the dll 'seen' by process B) -> 0x1000 (actual
> VM address)
> then the OS will map the Virtual Address of the dll to physical
> address..
> but that's another matter....

---

quote:

---

> 2)what does 'rebasing' actually change?
> What i think is that it will change the memory reference (virtual
> address of course) in the dll.

---

quote:

---

> If you said that there is only 1 copy of the dll....

---

quote:

---

> I don't know how exactly it works! As I think the 'rebasing' stuff
> occurs at LOAD TIME
> e.g.
> Process A already loaded DLL X into memory 0x1000 and running a
> function inside DLL X
> now Process B tried to load DLL X, but the base address of DLL X is
> NOT AVAILABLE for Process B.
> so...what will happen?

---

quote:

---

> I don't think the OS can MOVE DLL X from 0x1000 to other Virtual
> Memory Location where Both Process A and B are 'free'

---

quote:

---

> 3) It seems to me that Position Independent Code would have
> performance impact over that of Position Dependent Code, right???

---

quote:

---

> I don't think you know what you're talking about. Either that or using
> terms like 'data segments' and 'position inddependant code' to mean
> something totally different from what they nomally mean.
>
> DS

---

quote:

---

> A mapped the DLL. The problem would be if the DLL was coded to load at
> virtual address 0x1000 and that address was already in use by a program that
> tried to load the DLL.

---

quote:

---

> Well, it doesn't change it in the DLL file itself. It changes it in the
> DLL as seen by a particular process.

---

quote:

---

> Windows supports both shared and unshared segments in DLLs. If a program
> modifies a byte in a shared segment, the DLL file itself is modified and all
> processes using the DLL see that change. However, the segments that are
> rebased are never shared, they're unshared. If a process modified a byte in
> an unshared segment, then it stops sharing the page containing that byte
> with other processes and gets its own private copy of that page.

---

quote:

---

> You're confused. Process A and process B have totally independent
> virtual address space, so there is no way one process can use another
> processes virtual address space. The virtual address would have to already
> be in use in the process that's trying to attach to the DLL.

---

quote:

---

> Yes, PIC is generally slightly slower. However, the advantages of not
> having to make a separate copy of a page for many processes just because one
> byte needs to be relocated make PIC advantageous for any shared library code
> that you expect to be frequently used by more than one process at a time. It
> is, essentially, a size/speed tradeoff. PIC code can also be attached to
> faster, though that rarely matters.

---

quote:

---

>
> Yes, PIC is generally slightly slower.

---

quote:

---

>
> So, all the VM space (e.g. 0 to 2^32 or 4G) are available for any process??

---

quote:

---

> e.g. if I have 4G memory

---

quote:

---

>, I have process A and process B
> process A use 0x0000 to 2G?
> process B can also use 0x0000 to 2G?

---

quote:

---

> while the OS will map
> Process A: 0x0000 -> 2G to (physical) 0x0000 -> 2G
> Process B: 0x0000 -> 2G to (physical) 2G - > 4G
> ?

---

quote:

---

[QUOTE][color=darkred]
> Yes but if the DLL is shared by both Process A and Process B, the
> relation becomes
> A---.DLL---B
> since .DLL has to exist in both Process A and Process B's virtual
> address (I assume .dll is sharable.....please correct me if I'm
> wrong..)
> so the .DLL has to find a virtual address that is free in the virtual
> address space in both Process A and Process B, right?

---

quote:

---

> do you mean that there will be 2 dll?
> e.g.
> - Process A load the .DLL from FILE to MEMORY, and mark the pages used
> by the .DLL copy-on-write
> - Process B load .DLL again
> - if Process B needs the .DLL to be REBASED => rebase occur on the
> .DLL, but since the pages used by .DLL are COPY-ON-WRITE =>
> essentially the .DLL is duplicated with new REBASED virtual address
>
> right???

---

quote:

---

> this backed up the explaination of having 2 instances of the dll when
> rebase is needed for any process that loads that dll

---

quote:

---

[QUOTE][color=darkred]
> I know process A and process B have 2 independent virtual address
> space...
> but I was thought that the .dll is shared by process A and B, and that
> act as a linkage between 2 processes' virtual address space;

---

quote:

---

> I'm wrong because the .dll isn't really shared by process A and B if
> rebasing occur.

---

quote:

---

> i.e. if a dll occupy the virtual address from 0x1000 to 0x2000
> and Process A and Process B can load the dll to 0x1000-0x2000 without
> rebasing
> => the dll is SHARED
> HOWEVER, if any one of the process A or/and B needs to rebase the dll
> (as 0x1000-0x2000 is occupied by other .dll/codes) a new copy of the
> dll is created (due to copy-of-write -- write occur when rebasing)
> right???

---

quote:

---

> what this means is that if rebase NEVER OCCUR, PIC won't be STRICTLY
> slower than absolute addressing?
> as I know, REBASING takes lots of time (esp for large dll).
> so
> - PIC consume less space because the library (.so) can be shared with
> all processes (no rebasing, no copy-on-write)
> - PIC is slower when rebasing is not needed
> right???

---

quote:

---

> of *physical* memory?

---

quote:

---

>
> No, the virtual-to-physical mapping could be totally random.

---

quote:

---

> caused be the severe shortage of registers, and PIC uses one of them
> for special purposes. Real CPUs have so many registers that using one
> specially isn't much of a problem.

---

quote:

---

> what about shared memory object? do the OS allocate it by searching
> a common available space for ALL processes or there is a special
> reserved virtual memory addresses that are solely for storing shared
> memory object?

---

quote:

---

> what about shared memory object?
> do the OS allocate it by searching a common available space for ALL
> processes or
> there is a special reserved virtual memory addresses that are solely
> for storing shared memory object?

---

quote:

---

> address for both processes.

---

quote:

---

> No. The DLL is mapped into a particular process' virtual address space
> through a mapping. That mapping can make changes, including mapping any
> physical address to any virtual address in that process and including
> substituting some pages mapped into process private pages rather than shared
> pages that hold cached pages from the original file.

---

quote:

---

> Right, through the physical page. In other words, process A might map
> physical page 0x1000000 at virtual address space 0x1000 and process B might
> map that same physical page at his virtual address space 0x2000.
> Virtual-to-physical address translations are done through a mapping and each
> process has its own mapping.

---

quote:

---

> No, it really is. Just some pages become unshared because one process
> modifies them. The sharing is read-only, so any attempt to modify a page
> breaks the sharing and the process that attempted the modification gets a
> private copy and its mapping is changed to map that virtual address to the
> new private copy.

---

quote:

---

> No, the DLL is always shared just like all files always are.
> Usually you don't particularly care about load time. Execution time is
> more important. However, memory usage can be important as well, especially
> for a shared object file that will be used by large numbers of processes.
> PIC will, in general, run slightly slower. However, it is more shareable
> and the number of pages that will become unshared when multiple processes
> use the shared code is much lower for PIC.

---

quote:

---

> Every process has its own virtual memory space. One process does not care
> about another process' virtual memory space.

---

quote:

---

[QUOTE][color=darkred]
> but DLL, unlike .so, use ABSOLUTE (virtual) Addressing, so the DLL has
> to be the SAME Virtual address for both processes IF both processes
> share the SAME DLL

---

quote:

---

> if the DLL mapped into the DIFFERENT virtual address - REBASING of the
> DLL already occured -> one of the process already get the PRIVATE copy
> of the DLL....
> right?

---

quote:

---

[QUOTE][color=darkred]
> I think DLL is loaded to the virtual address space DIRECTLY, but not
> through any mapping.....otherwise, there is no need to REBASE a
> DLL.....
> virtual address -> physical address mapping seems to be another matter
> my main focus is on the virtual address of DLL, where the DLL is
> shared between two (or more) processes...

---

quote:

---

[QUOTE][color=darkred]
> Yes..I'm clear about this
> but DLL/processes doesn't care about physical address
> space....actually i think physical address space is hidden from any
> processes - that's the principal of Virtual Memory, right??

---

quote:

---

[QUOTE][color=darkred]
> "some pages become unshared because one process modifies them"
> exactly...what i mean if REBASING occur, I assume most pages got it's
> own copy ...
> what I tried to say is in case REBASING occur, the DLL is essentially
> UNSHARED..

---

quote:

---

[QUOTE][color=darkred]
> that's because pages are 'copy-on-write' when rebasing the DLL, right?

---

quote:

---

> while .so don't need any rebasing -> most of the code pages are
> shared.

---

quote:

---

[QUOTE][color=darkred]
> then, how do shared memory object allocated by the OS?

---

quote:

---

> where do they exist?

---

quote:

---

> do process A access a shared memory object using the virtual address
> that is the used by by process B, who is also accessing the same
> shared memory object?

---

quote:

---

>
> yes...of course...
> Intel has PAE - allow 36 bits memory addressing..., right?
> do intel implment it using special instruction
> e.g.
> change_page to page 01 (all the way to 16)
> access memory normally
> change_page to page 06 (all the way to 16)
> access memory normally
> ,etc?

---

quote:

---

>
>
>
>
> ar...that's ture....the physical memory can be pagefile on harddisk, right?

---

quote:

---

>
> then, how do shared memory object allocated by the OS?
> where do they exist?
> do process A access a shared memory object using the virtual address
> that is the used by by process B, who is also accessing the same
> shared memory object?

---

quote:

---

>
> Only on braid dead machines like the Intel x86.

---

quote:

---

>
> But such machines are nearly useless anyway, since they're so
> susceptible to dredlocks.
>

---

quote:

---

> process initially loads, its virtual addresses are mapped based on
> system defaults and how the code was set up by the programmer, compiler,
> linker and loader. The process may also load libraries using dlopen(2)
> and allocate memory pages with mmap(2). The system then will map a
> shared memory object into an appropriate address space. For instance,
> HP-UX allocates 4 regions indexed by space registers. One of these
> regions is intended for shared objects. Again, processes may have the
> same shared object mapped at different addresses. Other Unixes map
> shared objects into different regions based on OS specific defaults.

---

quote:

---

> Lets say process A and B uses libc.so, libx.so and liby.so, but based on
> the way they were linked, A might map libc, libx and liby in that order
> where B might map libc, liby and libx in that order.

---

quote:

---

> WRT: fork(2). In general the parent and child of a fork with have
> identical virtual addresses at the point of the fork since they are
> effectively identical twins. But, after the fork, dynamically loaded
> shared object can be loaded at different virtual addresses.

---

quote:

---

> you mean Intel x86 machines are useless?
> I think their performance is superb.

---

quote:

---

> shared memory object are just memory location where several processes
> map part of their (virtual) memory space to the same physical memory
> location => 'shared memory';
> virtual memory <=> physical memory mapping are independent from the
> process's view, right?
> processes only 'see' virtual memory.

---

quote:

---

> this still holds for windows, right?
> but it may affect which lib will do the 'rebasing'

---

quote:

---

>
> so the parent and child is actually two different processes which
> shares nothing except the 'physical pages'; but since process don't
> 'see' physical pages
> we can actually treat them as two different processes which totally
> unrelated to each others...the copy-on-write stuff is for the
> performance issue

---

quote:

---

> you mean Intel x86 machines are useless?
> I think their performance is superb.

---

quote:

---

> silly joke.

---

quote:

---

>
> Now you're getting it.
>
> DS

---

quote:

---

>
> They're not in the market anymore, right?

---

quote:

---

> I've learnt that RISC machine is better than CISC's one
> and VLIW machine (Itanium) is even better than RISC

---

quote:

---

> but it turns out that Intel x86 or the 64-bit version (Opteron) is /
> will be a sucessful product
>
> Opteron is a CISC x86 machine, right?
> it has more registers and cache
> and P4 Prescott can have 32 pipline stages

---

quote:

---

> I remember that RISC machine can have more registers/cache/clock speed
> (pipline stages)/etc.
> but it's seems that today's P4/Opteron can also achieve it.

---

quote:

---

> like the upcoming Power5 will be. The PPC970 used in Apple's G5
> Powermac is based on the Power4.

---

quote:

---

>
>
> You'll have to define "better" before that makes any sense.

---

quote:

---

>
>
> There's nothing good about having many pipeline stages. On the
> contrary, many pipeline stages are bad for performance when there is a
> missed branch prediction.

---

quote:

---

>
>
> Intel optimize their CPUs for clock speed only. The simple reason
> behind that is that idiots shopping for a new PC will see the
> fantastic numbers like 3 GHz and think it must be fast. Real CPUs are
> optimized for actual use, or at least for benchmarks.

---

quote:

---

> but G5 isn't as good as it claimed...

---

quote:

---

> performance

---

quote:

---

> i know that.
> but isn't that for RISC machine; it can run higher clock speed as each
> instruction takes short time?
>
> that's true
> I like AMD more then Intel.
> AMD has better architecture, esp for the hypertransport / 64bit x86

---

quote:

---

> baronng@astri.org (Baron) writes:
>
>
> Numbers?

---

quote:

---

>
>
> It still comes down to the individual implementation. A good CISC can
> be far better than a bad RISC.

---

quote:

---

>
>
> Why do you think they stopped printing the actual clock speed? Now,
> if they'd only drop the x86 compatibility it could make somewhat
> decent machine. The fact is that all modern pentium3, pentium4,
> athlon etc. CPUs are made as a RISC core with an ugly x86 translator
> tacked on. Imagine what could be done if that silicon were put to
> better use.

---