gnu@hoptoad.uucp (John Gilmore) (05/26/89)
I've been thinking a bit about tightening up memory use in NeWS.
One important innovation in X/NeWS is the "soft reference". Such a
reference works fine as long as the object continues to exist. When
the last "hard reference" to the object disappears, so does the object,
and an event is sent out to all interested processes. They are
supposed to find their soft reference(s) to that object and remove them.
This lets an ancillary dictionary contain a pointer back into its
parent structure (e.g. to the canvas or the userdict) without
causing the parent structure to stick around just because of this
pointer.
I would like to see this idea of sending events up to the PostScript
programs extended to other situations. In particular, when NeWS
is running low on memory, it should send an event, let the event
be processed, *then* allocate the memory.
This makes it possible to have 'the best of both worlds' regarding
speed and low memory use. An application can cache as much data in the
server as it wishes, in order to provide fast response -- as long as it
is willing to throw that cache away on demand. Retained windows can be
used, and be made non-retained when memory tightens. Applications can
upload large sections of code once, leaving them in the server
between executions of the application, as long as a sentinel process
will delete the code if it is not in use and memory bloat threatens.
The thresholds for when memory usage is considered "loose" or "tight"
should be settable by the user. In a NeWS terminal, physical memory
would be the limit. In a virtual memory system, the limit should still
be less than the physical memory, to reduce response time by avoiding
paging. (SunOS 4.0 is notoriously bad at this, for example.) But
if the user has a fast disk, a good paging algorithm and scheduler,
and lots of swap space, they can set the limit wherever they want it.
The user could adjust it on the fly as the perceived system performance
changes.
A 'low memory' event should probably indicate the starting memory size
(as returned by vmstatus) and the request size, so that when a few
thousand bytes are needed, 500K of 'baby' is not thrown out with the
bathwater. The event handlers can check whether previous recipients
have freed up "enough" memory (in their estimation), and ignore the
event if so. To avoid handling these events constantly, my handlers
would free up more memory than requested, but that choice should be
left to the applications as 'policy', not 'mechanism'. Better control
over the order in which things are tossed would be convenient, but I
don't see a clean way to do it. Do you?
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
A well-regulated militia, being necessary to the security of a free State,
the right of the people to keep and bear arms, shall not be infringed.gregm@SUN.COM (Greg McLaughlin) (06/01/89)
> One important innovation in X/NeWS is the "soft reference". Such a > reference works fine as long as the object continues to exist. When > the last "hard reference" to the object disappears, so does the object, > and an event is sent out to all interested processes. They are > supposed to find their soft reference(s) to that object and remove them. > This not quite true (or at least miss leading). When the last soft reference to an object goes away the object does *not* disappear. Soft references keep the object from going obsolete just as well as hard references. In fact, as long as there are soft references, there are also hard references around. The way it works is that once there are an equal number of hard and soft references (they will come from the same place...think of soft ref's as an anotation to the hard ref that "I want to know when no one is holding any ref's that are not soft") an event will be generated. It is then the responsibility of the processes interested in that obsolete event to clean up their references. Only when *all* the references to the object are gone does the object get GC'ed. Ref possibilities for an object: 0 hard 0 soft => object gets GC'ed hard == soft => /Obsolete event is sent hard > soft => nothing happens, object exists Not a possibility: hard < soft => this just can't happen (unless there is a bug in X/NeWS) I realize that this is not an important distinction in John's mail, but it has been a great source of confusion within Sun. I just want to make sure that NeWS_makers gets it straight. Greg