This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: A Conversation on 64-bit Smalltalk
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
A high point of the recent Smalltalk Solutions conference in Seattle was a conversation I had with Eliot Miranda, the VisualWorks VM guru. In this note, I report on that conversation, expanding a bit on the ideas I expressed while reporting his ideas accurately (I hope).
Eliot has been working on a 64-bit VM to take full advantage of the 64-bit microprocessors that are now available. He was somewhat surprised when I asserted that "64-bit support is insane!" By this, I just meant 64-bit memory addressing scaled up from today's standard 32-bit addressing. I really wasn't talking about 64-bit numeric and logical operations, where wider words can mean better performance for some applications.
Eliot pointed out that he has customer requests for a 64-bit VM, and that some VisualWorks customers are already hard against the limits of 32-bit addresses in some really big applications. As far as he is concerned, there is no great difference between going from 16-bit addresses to 32-bit addresses, which happened a few years ago, and now going from 32-bits to 64-bits.
I argued that this is more than just a change in scale. Going from 16-bits to 32-bits only increased the size of the address space from 65 thousand to 4 billion addresses. But going from 32-bits to 64-bits increases the size of the address space monstrously, from 4 billion to 18 billion billion addresses, an address space far beyond the needs of any conceivable application today. Straight-forward support for 64-bit addresses is (to me) a huge waste of memory, causing a gross expansion of the size of all programs.
"So what's the alternative?" he asked.
In brief, it is to use 32-bit relative addresses that are added to a 64-bit base address, thereby eliminating all the unused high-order 0-bits of 64-bit addresses. This trades-off the processor time needed to add addresses in order to to save memory, but then today's processors have cycles to burn.
But this is just the tip of what is needed, namely a radically different technology for managing memory resources. Before I explain further, let me note that this technology has been successfully used by the IBM System/38, AS/400 and iSeries computers in nearly a million multi-user systems since 1980. It's still revolutionary, but hardly untested. (I'll call this the Pacific architecture/system after the name of the original development project.)
Take advantage of a basic property of programs called "locality of reference." This is the simple fact that most program references are to addresses that are relatively close by, almost all within a 32-bit address space. So why not manage memory in terms of segments of the total 64-bit address space. In fact, 32-bit segments work pretty well.
Recognize that very few systems will ever have a RAM big enough for even a small portion of a 64-bit address space; mostly much less than 2**32 bytes. This means that most data has to be stored on disks and transferred to and from RAM. So why not do it in terms of fixed-sized chunks (often called pages) for which both hardware and software is optimized? The size of such pages would be some factor of a segment size, perhaps 2**16.
Increased memory management flexibility. If one 32-bit segment isn't enough for an application, let it have as many as it needs. This is still more sensible than giving each application a full 64-bit address space.
Built-in security. Segmented memory management lends itself to a greatly enhanced form of security based on system created and managed "capabilities."
Better memory sharing and utilization. With an appropriate use of capabilities, it is possible for multiple concurrent programs to share pages of one or more segments. It just isn't necessary for an entire 10 megabyte program to be loaded into a Pacific system for each of its users. Instead, only the active pages of the program are loaded, and those are shared by all users. The system's memory manager efficiently acquires and retains active program pages for as long as they are needed.
Built-in concurrency controls, in the form of system managed locks on the use of segment pages.
I rattled these ideas at Eliot, and he was patient enough to hear me out. But he soon started expressing a variety of practical considerations. Among them:
RAM has gotten so cheap; even if you don't have enough RAM for the full 2**64 addresses, high-end applications can easily afford some multiple of 2**32 bytes of RAM, and that's what his new 64-bit VM is aiming for.
True, but that doesn't answer the code bloat argument. The use of 64-bit addresses exacerbates the RAM requirements of big applications.
The difference between processor speeds and RAM access speeds is already several orders of magnitude, with even more difference in speed between RAM and disk access. Bridging these differences becomes increasingly difficult as processor speeds keep getting ramped up, so virtual memory schemes become less and less effective.
Doesn't this just mean you have to pay more attention to optimizing techniques: buffering, caching, LRU algorithms, the size of the chunks transferred, and the amount of RAM available. The 1980 System/38 was designed to support multiple users with only 1 megabyte of RAM, and 512-byte pages. The larger models of the current Pacific systems support thousands of concurrent users, but do so with many gigabytes of RAM and much larger page sizes.
Shouldn't a segmented virtual memory architecture really be part of the operating system? Remember that VisualWorks runs as an application on top of a a variety of different operating systems.
Well, the original Smalltalk systems were designed to be a replacement for an operating system. One of the original Smalltalk designers said something like "An operating system is everything that got left out of programming languages; there shouldn't be one."
Great, but that doesn't reflect today's realities.
Still, why can't an application grab a large chunk of memory, and a large chunk of disk, and manage them according to this segmented memory scheme. It wouldn't be as good as a tighter knit relationship between the hardware and VM, but it is still an experiment worth trying.
At (more or less) this point in the conversation, Eliot asked how I would want to see Smalltalk implemented in a segmented memory system. I can't say I have thought it all the way through, but it helps to think of existing Smalltalk implementations, and then to think about what a Pacific system does, and finally to think about them together.
Looking first at Smalltalk, there are two obvious ways to use a segmented memory:
An image is already broken into regions that are used for different purposes: for short-lived small objects, for long-lived small objects, for large objects, etc. In today's implementations each region is managed for best performance. Objects migrate from one to another as their properties change. Garbage is collected using the best algorithm for each region.
Separate 32-bit memory segments could be used for each of these regions. Like other segments, their pages could be anywhere in RAM, without concern for actual locations (relative to each other). Smalltalk could finally leave behind the concept of a monolithic "image."
At a deeper level each kind of memory region would be an instance of a MemoryClass, each with its own internal and external behaviors, potentially instantiable or subclassable by applications.
And then there's the mess that I'll collectively call pundles: bundles, packages and parcels (or applications and subapplications in the ENVY environment). How about putting each pundle into a separate memory segment, and letting the VM's page manager handle their loading and sharing as needed by the applications that use them. This would eliminate the absurd notion in current systems that entire 10 megabyte images need to be loaded before anything useful can be done. And it would eliminate the need for applications to provide their own dynamic pundle loading schemes.
Now let's look at what Pacific systems do with segmented memory.
Everything is an object! Sound familiar? Well it means something a little different here. In Pacific systems, every System Object is implemented as a memory segment, and System Objects literally "contain" Program Objects, which are the primitive data types of programs written in RPG, COBOL, C, Java, etc.
But System Objects are not just "containers." Every System Object is an instance of a specific "type" that encapsulates its contents, allowing access by only a predetermined set of programs. The big difference between Pacific and Smalltalk objects is that Pacific has no formal notion of classes. It supports a fixed set of System Object types and a fixed set of Program Object types, but no application-defined types.
One important type of System Object is "Program", instances of which are produced by compilers, and which are similar to Smalltalk pundles. But there are many other types of System Objects, with specific behaviors in support of both operating system and application requirements, including Contexts, User Profiles, Indexes, Data Spaces, a variety of process work spaces, and database spaces. The result is a set of interacting objects at a higher level of abstraction than the Program Objects typically used by applications.
So where would Smalltalk objects fit into the Pacific architecture? They are clearly something more than Program Objects in that they have intrinsic, class-defined behaviors. And System Objects are something more than Smalltalk objects in their containment of Program Objects in a capability-based security and sharing environment.
Now, what if
New types of System Object are designed to contain Smalltalk objects.
Smalltalk classes are used to define and instantiate new classes of System objects.
Smalltalk methods (using Smalltalk syntax) are used to program interactions among System Objects (as well as at the level of today's Smalltalk objects).
Smalltalk classes are packaged, loaded and managed as instances of a new kind of "Program" System Object.
At the end of our conversation, Eliot expressed a concern I often hear. There are a lot of cool ideas worth investigating, but who is going to finance the work. The Cincom VisualWorks team, for example, already has more than enough work keeping up with customer requests for refinements. Think about it, the hardware keeps getting better and faster, but even Smalltalk, the best software technology we have, is now 25 years old and essentially unchanged. At some point someone needs to step outside of this increasingly tight box and make the next big push. Perhaps the move to 64-bit processors is the incentive we need to do so. Perhaps a marriage of Smalltalk and Pacific technologies is what we need. But in my opinion, a simple scaling up of 32-bit addressing to 64-bits is not enough.
This was a most enjoyable discussion, well worth the cost of attending the conference. Will anything necessarily come out of it. Not immediately, but ideas were shared, and there is nothing more powerful than shared ideas.
Previous Topic
