MacTech Network:   MacForge.net  |  Computer Memory  |  Register Domains  |  Printer Supplies  |  Cables  |  iPod Deals  |  Mac Deals  |  Mac Book Shelf


  MacTech Magazine

The journal of Macintosh technology

 
 
Raid Card

Magazine In Print
  About MacTech  
  Home Page  
  Subscribe  
  Archives DVD  
  Submit News  
  Submit a Tip!  
  Get a copy of MacTech RISK FREE  
Google
Entire Web
mactech.com
Mac Community
More...
MacTech Central
  by Category  
  by Company  
  by Product  
MacTech News
  MacTech News  
  Previous News  
  MacTech RSS  
Article Archives
  Show Indices  
  by Volume  
  by Author  
  Source Code FTP  
Inside MacTech
  Writer's Kit  
  Editorial Staff  
  Editorial Calendar  
  Back Issues  
  Advertising  
Contact Us
  Customer Service  
  MacTech Store  
  Legal/Disclaimers  
  Webmaster Feedback  
ADVERTISEMENT
Click Here

Re: Segments from Outer Space

Jeff Alger

Jeff Alger replies to Kent Sandvik's "Children of the DogCow-Segments from outer space", which appeared in the June 1991 issue of FrameWorks.

Kent,

I'm writing to take issue with two things said regarding segmentation vs. VM in your otherwise excellent article on segmentation in the June Frameworks. Just setting the record straight.

First, you mentioned Unix thrashing is due to page after page being loaded as a thread of function calls is followed. As someone who has worked with Unix systems for almost 15 years now, that is the least likely reason for a thrash-and when it does occur, it is a symptom, not the disease. In almost all Unix thrashing, the problem is simply that you are trying to run too many applications with too big a cumulative space requirement at once. If you were using a Mac, you couldn't even make the attempt, so it is poor sportsmanship to knock Unix for at least trying.

The Mac forces you to partition the memory space, with fixed-size allocations per process, while Unix allows the VM hardware to allocate memory across applications as demand shifts. A classic prescription for this kind of thrashing in Unix is to use shared libraries, something that segmentation actually discourages (jump tables are application-specific, as are the memory spaces used to load the segments). In short, Unix does thrash, but only after it has far surpassed the Mac scheme's ability to juggle the same load.

The second thing that I wanted to comment on is your claim that segmentation solves tight memory problems better than VM. If someone at Apple has been able to prove this with real numbers or some sort of statistical model-quick! nominate them for a Turing Award. Maybe he or she can next develop a generalized sorting algorithm with better than n*log(n) performance. If asked, I'll certainly back the nomination.

Humor aside, the only reasons that segmentation is a better strategy than VM for the Mac are backward software compatibility, compatibility with non-VM Macs, and the fact that a reliable VM kernel is more difficult to implement than simply forcing applications to do their own housekeeping.

Performance of a segmented system must be worse than a VM system for so many reasons, I don't know where to begin: segmentation results in less efficient allocation of memory across the whole machine, since process sizes are fixed, while VM automatically balances memory usage among competing processes; segmentation results in larger swaps than the standard 4K page size of VM; VM allows seldom-used data to be swapped, while segmentation deals only with code; segmentation is a software-only solution, while VM is implemented in low-level hardware (in on-chip hardware for 68030's and 040's); segmentation is not suited to interrupt-time swapping, or for that matter, interrupt-driven multitasking, since it only applies at the start of a function call, while VM allows swap-outs to happen any time without damage; segmentation leads to the need for larger reserves of space-worse, larger reserves for each process-since memory is used less efficiently and an entire segment must be loaded in order to recover from a fault; less efficient use of space also results in more swapping, fewer processes, or both; segmentation works against sharing code across applications and creating truly integrated object-oriented operating systems and applications, since it forces an application, rather than system, perspective on memory usage… I'm out of breath.

Kent, I'm not unloading on you personally, but I am getting tired of the lack of justification from Apple for segmentation vs. VM. At first, I sat back and waited for a good explanation, but none has come out in the couple of months this issue has been thrashed out (if you'll excuse the pun) on MacApp.Tech$. Just recycled potshots. Does anyone have any real numbers, or is this just a "let's trash Unix because we didn't invent it"-party?

Your article was great otherwise, and I learned a lot from it. Keep up the good work, in FrameWorks and in your responses to MacApp.Tech$. You're doing a good job of filling Keith's shoes.

Regards-Jeff



Click here to find out more about our best subscription bundle deal ever!
2 years of the magazine, and the all new MacTech DVD ... at 70% off!



Click on the cover to
see this month's issue!

TRIAL SUBSCRIPTION
Get a RISK-FREE subscription to the only technical Mac magazine!
 
 


MacTech Magazine. www.mactech.com
Toll Free 877-MACTECH, Outside US/Canada: 805-494-9797

Register Low Cost (ok dirt cheap!) Domain Names in the MacTech Domain Store. As low as $1.99!
Save on brand compatible and name brank ink jet and laser supplies.
Save on long distance * Upgrade your Computer
Movies with No Late Fees!

See local info about Westlake Village
SJ * BRJ * BJ * OJ * NITS
Staff Site Links



All contents are Copyright 1984-2007 by Xplain Corporation. All rights reserved.

MacTech is a registered trademark of Xplain Corporation. Xplain, Video Depot, Movie Depot, Palm OS Depot, Explain It, MacDev, MacDev-1, THINK Reference, NetProfessional, NetProLive, JavaTech, WebTech, BeTech, LinuxTech, Apple Expo, MacTech Central and the MacTutorMan are trademarks or service marks of Xplain Corporation. Sprocket is a registered trademark of eSprocket Corporation. Other trademarks and copyrights appearing in this printing or software remain the property of their respective holders.