Please explain what you mean by "more compatible with our system". It is not clear to me what you mean. Also, I don't recall that we agreed on anything concerning the design of the loader. I originally agreed with your argument that it wouldn't be possible to patch the executable code, but I later explained that this would not be a problem because we can use the OS assembler to patch the addresses when the file is loaded.
And I explained that the OS linker won't be able to call hash consing functions, and that we may need to re-patch the machine code during execution (e.g.: after garbage collection).
The reason why the approach I propose is "more compatible with our system" is that it fits with the way code is compiled and linked at run-time. Storing code in the .text segment is what is traditionally done for statically compiled programs. It's outside of our control and requires special handling, since this code is potentially not movable, not freeable, not rewritable.
One applications where startup time is important is when you have a web server processing requests by starting up a new process running the desired program (which is a realistic situation for our "server-side" use of Tachyon).
People haven't been doing that since the CGI scripting day. Every modern server-side scripting system (RoR, Django, PHP, etc.) ships with a module that runs persistently in the web server.
I would appreciate it if you trusted me on this issue. I intend for the implementation to be simple and efficient while fitting with the current design. If somehow, someday, we find that our loading time is hugely burdened and that it's worth complicating our implementation to try and scrape off 15ms, it can be changed down the road.
In the meantime, initializing Tachyon after the machine code is loaded and linked is going to take at least an order of magnitude more time than the loading/linking itself... And this will still make for a very reasonable total loading time.
- Maxime