This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: 18 Million Billion
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
That's a big number! Not a google, but still a big number. So why am I gushing over a big number?
Well, that's (roughly) the number of addresses in a 64-bit address space. What got me thinking about this is the Fall 2004 plan for VisualWorks Smalltalk. In particular, they are planning "preview support" for 64-bit platforms, including "the AMD Opteron, the 64 bit Xeon, and the Sparc 64 bit." Among other things, they point out
The 64-bit implementation uses full 64-bit addresses for objects, providing the ability to fill the entire available address space with objects.
Most objects being pretty small, that's a heck of a lot of objects -- and that raises the question about how many applications actually have or generate or use anywhere near that number of objects. Probably none today, but in the future some could be that big: such as economic and physical simulations, data warehouses, etc. Meanwhile, most applications happily fit in a not-too-constraining 32-bit address space (roughly 4 billion addresses). It's not unreasonable to find computers with that much real memory, but much larger address spaces certainly imply some kind of paged virtual memory system.
Let's put aside the really big applications that use an entire 64-bit address space, and talk about more typical systems that run lots of small applications concurrently, for one or more users. One approach is for the operating system to parcel out ranges of addresses to applications as needed, hoping that they don't interfere with each other. Of course, the operating systems do have mechanisms to detect and prevent such problems, but "memory leaks" are still the root cause of many system crashes.
A different approach is to say that the total 64-bit address space actually consists of independent addressing segments, each the same size (say 32-bit, which would provide 2**32 segments) It is now much easier to allocate segments to applications (as many as an application needs), and to protect them from each other. Further, it is possible to specialize segments to specific tasks, to encapsulate their contents as "system-level" objects. For example, one class of system-object could be devoted to managing process context stacks, another class to user profiles, another to database indexing, and in a full-fledged system-object-oriented system to any other task.
In case anyone thinks I'm day-dreaming here, this second approach to 64-bit address spaces has been in use since the early 1980's in IBM's unloved but profitable step-children, the System/38, AS/400 and iSeries computers.
I started this by mentioning that VisualWorks Smalltalk plans to support 64-bit systems. My intention is not to criticize what they are doing; there are a lot of good reasons to support the new processors. But the very existence of a 64-bit address space demands a second look at how that much memory should be used. Today, VW Smalltalk grabs a big chunk of memory from the operating system and then manages it in terms of areas for new objects, large objects, old objects, etc. Instead, it could use separate 32-bit virtual memory segments for each of these purposes. And further, it could use additional segments for each program package used or defined by an application.
This is obviously not a complete picture of what Smalltalk would look like in a segmented 64-bit address space. Nor is it a design for a proper marriage of Smalltalk objects with the system-objects of an AS/400. It is just the dream I have had since first learning Smalltalk in 1981 while working on the System/38.
Previous Topic
