on GUIs and such things

[Norman Hardy]

At 10:28 -0700 00/07/24, Karp, Alan wrote:
>> -----Original Message-----
>> From: Shawn T. Rutledge [mailto:rutledge@cx47646-a.phnx1.az.home.com]
>> Sent: Sunday, July 23, 2000 1:12 PM
>> To: eros-arch@eros-os.org
>> Subject: Re: on GUIs and such things
>>
>> 			(snip)
>>
>> And I think that Java's garbage collector is probably up to
>> the task of
>> making sure that applications don't leak memory.
>
>It's far too easy to leak memory in Java.  You've got to be careful to drop
>references, and I think there's a problem with circular references, although
>the documentation says that they're handled properly.
>
>>
Here are two "bugs" that complient Scheme systems may have that are hard to
find:
(let ((x ...))  ... x ... (list (q))). The system cannot do tail recursion
and thus the unneeded value of x is retained while q executes. Some
compiling systems transform the program to (let ((x ...))  ... x ... (set!
x '()) (list (q))).

Another case is (let ((x ...)) ... (lambda (...) zot)) where x does not
appear in zot. The procedure returned by the outer expression retains the
unneeded value of x by statically linking the the prior activation record.
These are hard to find and work around.

It all boils down the the prhase in the Scheme spec: "can be proven to be
immaterial to the future of the program". Differences in proof diligence
between compliant systems can make application difficult to port. Java is
subject to these problems.

Yet another problem is where I allocate storage and send you a capability
to the behavior implemented in that storage. There comes a time that I know
that the capability that I sent you is useless and yet I cannot reclaim my
storage. See <http://www.mediacity.com/~norm/CapTheory/Language/Lunch.html>
for a concrete example.

Keykos space-banks provide tools to find and easily work around these problems.
Norman Hardy  <http://www.mediacity.com/~norm>