on GUIs and such things
Shawn T. Rutledge
Thu, 20 Jul 2000 23:41:08 -0700
On Thu, Jul 20, 2000 at 11:07:09PM -0400, Kragen Sitaker wrote:
> > > Palm-sized computers benefit from transparent persistence;
> > > unfortunately, transparent persistence might not interact well with
> > > ten-thousand-cycle flash RAM. I'm not sure whether palm-sized
> > Well I think it's better to just leave the data in RAM all the time,
> > rather than copy it back to something that's artifically designed to
> > resemble "disk" space (FLASH).
> Well, artificially designed to be nonvolatile, anyway.
What I meant was, artificially preserving the idea that data should
be copied from memory to disk before shutdown. In some cases, even
making the FLASH look like a filesystem, emulating the cylinder/head/sector
> > This has been the approach of two
> > of the more successful ones (Newton and Palm).
> What kind of RAM does the PalmPilot family use for "nonvolatile" data?
I think all of the memory is nonvolatile. There is FLASH for the
OS itself, but most programs and their data are in non-volatile
memory; I believe it's SRAM. (There are also utilities to write
add-on programs to FLASH, to save some of the main memory. This
aspect is a bit kludgy.) The battery life probably wouldn't be
so good if a DRAM refresh circuit were running all the time.
> > I think the big thing that
> > stops the idea is the reliability of software. Memory leaks and
> > corruption are absolutely verboten when you aren't planning on
> > starting your memory image over from scratch once in a while.
> EROS' approach is to isolate corruption within a single domain and
> memory leaks within the children of a single spacebank.
That's good, but a leak is still a leak if you never shutdown the
program and restart it, but just persist the entire running state.
Not that it's a bad idea, but it imposes more rigor on the quality
of the software.
> > It would be best to exclusively use languages which prevent these problems.
> Those languages have their own problems ;)
Performance? the usual complaint. What other problems? (BTW when
I said "exclusively" I meant for user-level applications...not the OS)
> Also, you can't entirely prevent memory leaks; if you don't overwrite
> unused pointers, you will still have them in Lisp or Java.
True enough. But I don't think it happens much in practice. And you
don't have to overwrite every unused pointer, just the top one which
points to the entire substructure that is no longer needed. Most
objects belong to something which belongs to something which ... belongs
to a local variable in a method somewhere anyway. When the method exits,
all the local variables and everything under them are garbage collected,
to the extent that none of the objects have other pointers to them
elsewhere. So I think this is why memory leaks in Java are so rare.
I don't know as much about how a typical Lisp GC works.
_______ Shawn T. Rutledge / KB7PWD email@example.com
(_ | |_) http://www.bigfoot.com/~ecloud firstname.lastname@example.org
__) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903