on GUIs and such things

[Shawn T. Rutledge]

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
addressing, etc.
> 
> >  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?
> DRAM?

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  ecloud@bigfoot.com
 (_  | |_)          http://www.bigfoot.com/~ecloud  kb7pwd@kb7pwd.ampr.org
 __) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903