Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Segmentation (was Re: ARRGH (Strings and things))
Message-ID: <8878@hoptoad.uucp>
Date: 1 Nov 89 18:33:37 GMT
References: <16004@netnews.upenn.edu> <8835@hoptoad.uucp> <16420@dartvax.Dartmouth.EDU> <8852@hoptoad.uucp> <14386@well.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 78

In article <8852@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>I get a different moral out of this -- don't unload segments.  I use so
>many function pointers in my code that it's impossible anyway, so I
>don't have this problem.  As far as I'm concerned, UnloadSeg was
>relevant only to the Mac 128K....

In article <14386@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes:
>	Are you serious, Tim?!?!?  UnloadSeg is as useful today (maybe even
>more so) than it was back in the days of the 128K Mac...By using UnloadSeg and
>keeping careful watch of which segs get used the most to keep them around and
>possibly preloaded one is able to not only get lots of code into very small
>MF partitions but can also keep their heap from getting fragmented.

The heap fragmentation issue is obsolete, now that the OS moves code
segments into high memory.  It is impossible for the heap to become
fragmented with this operation, assuming that nothing moved into high
memory is ever moved back down (which is how it should be done; that's
the purpose of the high memory operation).

And sure, you can move things into smaller partitions this way, as long
as you don't care about certain minor facts like keeping to the
interface guidelines.  User operations are supposed to begin taking
effect instantaneously.  If they require fetching in a large resource
from the application file, then they are anything but instantaneous.

You also ignored the function pointer issue.  I received a letter from
a person at Apple that I respect and who is usually right, but not this
time.  He says that you should put all function-pointer fetching
routines into the main code segment: that way, they will be jump table
pointers.  This may work fine for code that uses one or two function
pointers and calls them all itself.  However, just imagine passing a
function pointer into the jump table to the vertical retrace manager or
as a completion routine to the file manager.  Can you say "intermittent
crash when A5 is not CurrentA5"?  I knew you could.

And imagine code (if you must; I don't have to imagine) that has lots
of function pointers -- you're going to move *all* assignments to them
into the main code segment?  I don't think so!

You're also asking for errors.  Suppose you forget just once to put one
of your function pointer fetches into the main code segment.  Normally,
it won't have any problems.  But then, just very occasionally and not
so you can figure out what's happening, that code segment will wind up
relocating and you will have a function pointer to inner space.  The
tester or user who finds this little bug is not going to be able to
tell you what happened; users, in particular, tend to forget everything
that happened right before a crash due to emotional shock, and even if
they don't, they can only give you the broadest area of functionality
in which it occurred.  And with this kind of bug, even if they remember
exactly, the problem can't be replicated reliably.

A similar kind of bug will happen (as I just noted to Pete Gontier) if
you inadequately provide guarantees that a segment can be reloaded when
you need it.

And as recently pointed out by another poster, you have yet another
potential intermittent error if traps glue happens to be in an unloaded
segment.  This has the same replicability problems as the others.

>	I think more programmers should start using UnloadSeg so that we can
>have more small partition applications and therefore have more and more of them
>running - sure I know about virtual memory, but I prefer the real thing!

I prefer instant response and program reliability, as well as the
ability to use function pointers freely in my code.  There are really
very few people who need to use more than two or three programs in
conjunction with the Finder at once, and those people can get SIMMs
pretty cheap these days.  Real RAM hogs like MPW Shell and FullWrite
may need to use it, but my programs rarely get over 250K.

>So get with it folks - there is such as thing as UnloadSeg - USE IT!!!

No thanks!
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Prisons are built with stones of Law, Brothels with bricks of Religion."
    - Blake, "The Marriage of Heaven and Hell"