devdocs notes on memory layout and runtime initialisation

Some notes I made while learning about runtime internals.
Maybe useful for other new developers.
But maybe misleading because eggnog :)

The problem with putting this stuff in source comments is that the reader would have to spend a lot of time fishing around in different files and following calls to find it. This is intended to be a code walkthrough of the execution path for a specific example. It took me the better part of a couple of days reading the source and playing in lldb to figure out what code path was followed in my example. My intention in writing it up this was is that someone else who wants to get a feel for what kind of stuff has to happen to print "Hello World!" can spend 15 mins reading a few pages.

As for there being "too many specific implementation details mentioned which may change" I think that is the nature of the beast. How can you have a runtime code walkthrough that contains anything other than specific implementation details? The point of documenting the current state is to make it easier for new devs to understand what is going on now, so they can effectively design and implement changes.

There is a tradeoff for all complex code bases: If you don't document the internals, then only a few people will understand them and be able to make useful contributions. If you do document the internals, then the documentation becomes part of the codebase and has to be updated when things change. Comments in the code are only one dimension. The other dimensions are just as important: i.e. data layout, architecture/layer diagrams, temporal views (walkthroughs) etc.

I admit I was worried about the line-number URL links too as I pasted them into the doc. However, until github has a syntax for linking to a function definition I think it's better than nothing. My guess is that the line numbers will drift over time, but that at least the links will take the reader close enough to the right place that it's still useful. I considered the alternative of using a link to a fixed version of the file, but I decided that it is better that the reader sees the latest code if they are reading about internals. If they find an annoyingly bad link, they can fix it.