AMD, is just a standard. So there are a few implementations. The current favorite AMD implementation is require.js. It is a clean project led by James Burke. The documentation is good and the project has a lot of visible support on the internet. Also, I’ve read some of his online interactions. It is tough to help out on an open source project and respond to criticism. However, James really handles it well. This is really important. Many online discussions drift towards negative behavior during technical debates.
Anyways, as I’m learning more about this and how these JS apps are being developed, I’m just struck at how their ‘new’ ideas are just rediscoveries. These are the same problems that early microcomputer devs had to deal with in the 1980s.
How does this tie to AMD loaders? Well, they missed a few of the lessons. They haven’t quite made the conceptual jump that they really need to manage memory. I’m not talking about malloc, I’m talking ‘module’ or code memory management. This may seem odd, because that is surely one of the intents they are addressing in the first place. I think it is because the browsers do not offer the capability to control this yet.
For example, in the early days of microcomputing, there was a popular system of the day called UCSD Pascal, or the UCSD p-system. It was a cool virtual machine implementation that emulated a 16 bit stack machine on just about any computer of the day. One thing that blew me away back then was the fact that even a few games were written in the system (Wizardry, Sundog, and a few others). The history and popularity of that system is the subject of another post. (Apple Pascal and How I learned Pascal)
One of the key attributes of the system was the concept of a ‘segment’ manager. This is the part that is relevant to this discussion. It managed what code was in memory at the given moment. Some other languages and systems had different names (overlay manager), but the concept was the same.
Here is how it worked:
Since machines in the late 70’s were just starting to have 64k total memory at that time, memory was a premium. At some point, some programs just needed more memory to solve the task for a portion of the program than a 64k system could provide. In order to run those programs, a code module manager was implemented in the p-system (segment manager). You could load or unload segments as needed for an application. For example, if you needed to switch to s apreadsheet from word processor mode, you would associate the code for the spreadsheet with a segment. If the user switched to spreadsheet mode and caused that code to run, the magic happened. The system would unload an unused segment from memory and then load the spreadsheet segment from disk and then execute it. Here is the interesting part. When you finished using that code, the system would automatically unload the code segment from memory so it could be used by another portion of the program. This system allowed people to finally write programs that were larger than the machines they used.
This was done in the early 1980s, yet, even today, this type of system is not common place. The segment manager was so important back then that it was replicated in the Mac Toolbox (which was originally in Pascal) until OS X. Almost all PC pascal implementations had it as well (Notably Turbo Pascal and Delphi). These systems did not appear in any of the ‘C’ based environments.
Eventually, the need for these was lessened as some of the functionality was replaced by dynamic loaders on unix or the DLL system on windows. Computers had lots and lots of memory for code. Still, the choice is not optimal today. For example, modern Unix or WinNT based kernels may un-associate part of a programs address space from physical RAM, but it still must maintain the book-keeping and page-tables for that code. If you look at the address space of a typical desktop program in memory, there are so many modules that this linking process can actually be responsible for the slow startup on todays ‘modern’ systems. The segment system was much cleaner and smaller.