On Mon, Apr 12, 2010 at 20:25, Lennart Sorensen
<lsore...@csclub.uwaterloo.ca> wrote:
> On Fri, Apr 09, 2010 at 03:21:47PM +0800, Ben Kloosterman wrote:
>> On x86_64 segment registers ( in long mode ) are all 0 based ( except for FS
>> and GS)
>>
>> Also im not sure what the above gets you. Forks are not common ( in terms of
>> instructions) so im not sure perf even matters.
>> Normally an app loads from the disk and then it creates a sub proc via a
>> fork , when comparing to a disk a few micro seconds to copy the memory is
>> not a big deal.
>
> fork is not common in a daemon. Some other applications may do lots
> of forks. Depends what the application is. There is no such thing as
> 'normal application'. Just remember lots of things call system() to
> do things.
>
>> I only need to get fork working for mono , if we are talking about apps this
>> only affects data for shared static code, GC references are always
>> indirect/private. Everything else can be patched at load. Static code can be
>> handles like TLS either store it as an Offset to FS ( on x86 ) or a spare
>> register in (x86-64). I know ucLib already has code for this.
>>
>> Note this is more an issue for monolithic OS than a microkernel as you don't
>> really have or rely on as many shared libs.
>>
>> A 3rd alternative I have proposed ( for the .NET & Java apps) is for shared
>> code to be broken into 2 libs and any methods that access static data to be
>> placed in a separate lib and that code is not shared. It can then be patched
>> as normal for full performance and code that is static heavy will be
>> penalized with additional memory use but no perf penalty.
>>
>> Fork was around before copy on write, why not just do it the old way and
>> have the child treated as a new process ( though we need to repatch the code
>> to point to the new location ) ie the fork copies the data AND code. ( note
>> this is not my architecture since there is no fork but just to get it all up
>> and running)
>
> Waste of time, memory and cpu cycles. Also patching might be harder
> since at load time there is no data containing pointers to anything.
> It is a well known state. Once something has been running, you have no
> idea what might contain pointers anymore. Sure you can fix the function
> pointers and such, but you can't fix the stack and other data that may
> contain pointers to things.
That's why you need to
a. Address all data relative to a base register, so you can move the
data and just
update the base register,
b. Use 2 separate stacks:
1. The standard stack for return addresses (jump to subroutine),
so you can relocate
all addresses (pointers to code) when moving/copying the code,
2. A second stack for storing data (mix of "pointers" and other
variables), which you
don't touch when moving (remember, all pointers are actually
offsets relative to
the base register).
But as mentioned before, implementing this needs some heavy compiler lifting.
And yes, this should be somewhere in the very old mailing list archives ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
