Heads up: resident executable support added

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    I've committed enough bits of what I've been working on for the last
    24 hours to make it useable.

    To avoid problems you need to do a full buildworld and installworld.
    If you want to use make -DNOCLEAN buildworld then first cd into
    /usr/src/lib/libc and 'make clean' so it properly generates the new 
    system calls.

    The new support does a much, much, MUCH better job then prebinding.  So
    much better that in stage 3 I am going to *remove* prebinding support
    entirely.  On the downside, there needs to be some integration with the
    build system and some additional augmentation of the 'resident' command
    so the build system to deregister resident programs whos libraries are
    being overwritten :-).  So use the program with care for now.

    Perl, as usually, benefits the most:

	dhcp60# time ./test
	2.860u 2.668s 0:05.61 98.3%     87+231k 0+0io 0pf+0w	PERL5

	dhcp60# prebind /usr/bin/perl5
	dhcp60# time ./test
	1.821u 2.095s 0:03.90 100.2%    34+202k 0+0io 1pf+0w

	dhcp60# rm /var/run/prebind/*perl5
	dhcp60# resident /usr/bin/perl5
	dhcp60# time ./test
	1.239u 1.846s 0:03.08 99.6%     137+280k 0+0io 0pf+0w

	dhcp60# (rebuild perl statically linked)
	dhcp60# time ./test
	0.418u 0.867s 0:01.28 99.2%     808+616k 0+0io 0pf+0w


#!/bin/csh
#
# test script

set i = 0
while ( $i < 1000 ) 
   perl5 < /dev/null
   @ i = $i + 1
end

    How does resident support work?  It's easy and obvious... all that I
    do is vmspace_fork() the VM address space for the user process and save
    the copy in the kernel.  Then, later, when the user process is exec'd
    again the kernel notices that it has a saved address space and instead
    of running the ELF image activator it simply makes a copy of the
    saved address space and runs it directly.

    The ld-elf.so code detects that it was run from a resident copy (by
    checking a static variable which was modified prior to registration),
    and skips *ALL* of the DLL and relocation code.

    The result is that you can make often-used dynamic binaries exec
    far more quickly then before.

    We still have a ways to go to beat static startup, but there is absolutely
    no reason why resident programs shouldn't start as fast as the same
    program compiled statically so I have a bit more work ahead of me to
    figure out why it isn't so... something I'm still not skipping in the
    loader that I can skip in resident mode, probably.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>