In article <NOP.92Aug17135014@theory.Mankato.MSUS.EDU>, nop@theory.Mankato.MSUS.EDU (Jay A. Carlson) writes:

| I think that William and I were thinking in a more theoretical slant.
| Yes, the kernel would give each process its own copy if this was done
| without guile.  

  Exactly so. We need to write the page in such a way that the kernel
doesn't notice. Hum, I've used kernels that did that, but it wasn't a
feature.

| A brute force technique would be to include a kernel function that
| would do the necessary patch and then restore the previous
| dirty-status of the page.

  Or, as you implied earlier, not effect the status at all. Since these
are shared code segs, they better be clean.

| Note that with processes sharing the same text, there is even less
| overhead, since the patch only happens once per call point per shared
| image instead of once per call point per process.

  I had completely missed this. The overhead of a single fixup is shared
between all processes running the image. That is a feature of a runtime
loader, as well.

| I'm not sure that all this trouble is worth it.  Does anyone have any
| hard data on the performance loss of jump tables?

  That's very hard to get, since the overhead is dependent to some
degree on program behavior and system load. If the jump table stays in
memory due to usage, the overhead is small. If the call to the jump
table results in a page fault, the realtime goes up, and the system
overhead may or may not be reported back to the process. Up to a certain
point load help keep the JT in memory, after which it starts to force
other stuff out, and the memory used by the jump table(s) starts to
hurt. This seems likely only in a machine with minimal memory for its
load.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.