Why doesn't Smalltalk support explicit deallocation? 
Author Message
 Why doesn't Smalltalk support explicit deallocation?

Noone really bought on my teaser, so here's controversial topic instead.
Are Smalltalks reasons for not supporting explicit deallocatoin (though
it supports explicit allocation via new) more technical or more
philosophical?

I have my own opinions, but I'm curious what others are.

--
Travis Griggs (a.k.a. Lord of the Fries)
Member: 3rd Boolean State Software Collective
Key Technology
"It had better be a pretty good meeting to be better than no meeting at
all"-- Boyd K. Packer



Tue, 13 Jan 2004 04:40:05 GMT  
 Why doesn't Smalltalk support explicit deallocation?

Quote:

> Noone really bought on my teaser, so here's controversial topic instead.
> Are Smalltalks reasons for not supporting explicit deallocatoin (though
> it supports explicit allocation via new) more technical or more
> philosophical?

IMHO, it's for a very simple reason - it adds stability.  Otherwise, we
get dangling pointer ref issues like one has in C and C++.

Quote:

> I have my own opinions, but I'm curious what others are.

> --
> Travis Griggs (a.k.a. Lord of the Fries)
> Member: 3rd Boolean State Software Collective
> Key Technology
> "It had better be a pretty good meeting to be better than no meeting at
> all"-- Boyd K. Packer

--
James A. Robertson
Product Manager (Smalltalk), Cincom

<Talk Small and Carry a Big Class Library>


Tue, 13 Jan 2004 05:11:21 GMT  
 Why doesn't Smalltalk support explicit deallocation?
Thought you could kind of :-)

Send becomes: nil

N



Tue, 13 Jan 2004 05:09:28 GMT  
 Why doesn't Smalltalk support explicit deallocation?

Quote:
> Noone really bought on my teaser, so here's controversial topic instead.
> Are Smalltalks reasons for not supporting explicit deallocatoin (though
> it supports explicit allocation via new) more technical or more
> philosophical?

> I have my own opinions, but I'm curious what others are.

QKS Smalltalk has always provided a method call #Release which defaults to a
no-op in Object. But many other classes use it to release any elements or
external structures they are holding. This operation is part of the
lifecycle framework that includes object properties like
isCompoundStructureValid, isExternalized and messages like StartingUp,
ShuttingDown, etc.

The "actual" object memory itself is not released because that could lead to
pointer errors in the memory system. There are MOP facilities which an
implementor of #Release can use. These include:

a) Changing the class of the object to a generic class like ByteStorage or
Object, etc.

b) Changing the number of indexed slots to 0.

c) Changing the number of storage/struct bytes to 0 [byte-vars].

d) Clearing all the object properties to a default/pristine state.

e) Clearing all the named slots to <nil>.

There is a single VM message that [off the top of my head I think] provides
this in one shot: #basicClearAll.

There are numerous reasons why this could be a dangerous set of operations
even with informed understanding. Fundamentally you may be breaking any
number of contracts in the system based on other objects referencing the
object you are attempting to deallocate. That is the main reason why the
mechanics in up to the class implementor and handled through the #Release
method. The default implementation of #Finalize calls #Release.

--
-- Dave S. [ http://www.smallscript.net ]
   Smalltalk for the AOS Platform and The Microsoft.NET Framework

Quote:

> --
> Travis Griggs (a.k.a. Lord of the Fries)
> Member: 3rd Boolean State Software Collective
> Key Technology
> "It had better be a pretty good meeting to be better than no meeting at
> all"-- Boyd K. Packer



Tue, 13 Jan 2004 06:15:37 GMT  
 Why doesn't Smalltalk support explicit deallocation?

Quote:
> Are Smalltalks reasons for not supporting explicit deallocatoin (though
> it supports explicit allocation via new) more technical or more
> philosophical?

Remind me again: what's the difference between "philosophical" and
"technical"?

Explicit allocation is mostly a local choice. A statement like
    p := Object new.

affects p and, ideally, nothing else. (I say "ideally" because in practice
it may reduce the size of the free memory pool; it is the job of the
garbage collector to give the illusion of an infinite memory pool so that
this doesn't matter.)

Explicit deallocation is non-local. We need to be sure there are no
references to the object, anywhere in the system. It breaks information
hiding in a massive way. It says of every other object, "I know you don't
have a reference to this object"; it leaks a little of the implementation
detail from every other object. So despite your parenthetic comment,
explicit allocation and explicit deallocation are profoundly different.

Breaking information hiding goes against the OO philosophy, but that is
because it causes real, technical problems. For example, Java *had* to
have GC because its security model demanded it. Explicit deallocations
imply dangling references, which imply undefined behaviour when
dereference. Which makes any formal reasoning about the system's
correctness all but impossible. In particular, use of a dangling reference
in one module can make the behaviour of other, unrelated modules
incorrect.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,

                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."



Tue, 13 Jan 2004 06:47:00 GMT  
 Why doesn't Smalltalk support explicit deallocation?

Quote:

> Are Smalltalks reasons for not supporting explicit deallocatoin (though
> it supports explicit allocation via new) more technical or more
> philosophical?

Yes.

Technically:

        o       Allocation is good.
        o       Which gives as possibilities:
                P1) never deallocate
                        a) always never, on purpose
                        b) sometimes never, by accident
                P2) always deallocate
                        a) always, on purpose, and never too early.
                        b) always, but sometimes too early.
                        c) almost always, except by accident.
        o       Choice (P1) is probably bad (until memory gets *really* cheap).
                It seems that if we care about correctness at all,
                we have to choose (P2a) as our goal.
                Seems defensible - the others do not.
                (We might call this the 'philosophical' part).
        o       So how can we approach this goal?
                G1) Have a sufficient supply of very very "good" programmers,
                   who always deallocate, on purpose; i.e. never make these mistakes.
                G2) For each allocation, let the system logically derive a 'correct'
time span,
                   and cause the deallocation to occur somewhere within that span,
                   without need of programmer intervention.
        o       Based on available data, (G1) does not appear promising,
                and (G2) is achieved - but for the matter of continually trying to
improve
                performance by discovering ways to reduce the size of the derivable
time span.
        o       All that remains, I think, is a single selection from:
                x)  Attach a handle to every allocated object,
                    and answer the handle, rather than the object.
                    Upon {optional} explicit deallocation, release the object attached
to the handle.
                    Other uses of the (now dangling reference) can be dealt with
                    by the handle, until the system derived time span arrives
                    and the handle can be legitimately deallocated.
                y)  Don't allow explicit deallocation.
                z!) Only attach a handle to explicitly deallocated objects.    

                x has a cost for every object, but is of benefit to a very small
percentage.
                y eliminates the cost, but prevents important solutions in some cases.
                z is quasi-magic - the best of both.    

        o       I think z is the sort of result that continually occurs in Smalltalk.
                I think this is a result of the Philosophical part.

-jim

Quote:
> I have my own opinions, but I'm curious what others are.
> --
> Travis Griggs (a.k.a. Lord of the Fries)
> Member: 3rd Boolean State Software Collective
> Key Technology
> "It had better be a pretty good meeting to be better than no meeting at
> all"-- Boyd K. Packer



Tue, 13 Jan 2004 13:57:50 GMT  
 Why doesn't Smalltalk support explicit deallocation?

Quote:

>QKS Smalltalk has always provided a method call #Release which defaults to a
>no-op in Object. But many other classes use it to release any elements or
>external structures they are holding. This operation is part of the
>lifecycle framework that includes object properties like
>isCompoundStructureValid, isExternalized and messages like StartingUp,
>ShuttingDown, etc.

>The "actual" object memory itself is not released because that could lead to
>pointer errors in the memory system. There are MOP facilities which an
>implementor of #Release can use. These include:

>a) Changing the class of the object to a generic class like ByteStorage or
>Object, etc.

>b) Changing the number of indexed slots to 0.

>c) Changing the number of storage/struct bytes to 0 [byte-vars].

>d) Clearing all the object properties to a default/pristine state.

>e) Clearing all the named slots to <nil>.

>There is a single VM message that [off the top of my head I think] provides
>this in one shot: #basicClearAll.

>There are numerous reasons why this could be a dangerous set of operations
>even with informed understanding. Fundamentally you may be breaking any
>number of contracts in the system based on other objects referencing the
>object you are attempting to deallocate. That is the main reason why the
>mechanics in up to the class implementor and handled through the #Release
>method. The default implementation of #Finalize calls #Release.

One thing I thought would be useful is for some objects to have a reference
count, or specify that certain objects are additionally reference counted in
the garbage collection algorithm.  Or for some resources, this could even be
managed explicitly in Smalltalk/SmallScript as opposed to by the VM.  For
resources, especially ones such as large Bitmaps, its important to release
them immediately after they are not used.  Whenever you reference a Bitmap,
you could explicity increase a reference count, or add yourself to a Set of
objects that are referencing it, and when you're done you would remove
yourself from the set or decrease the reference count.  When the Set or
count is empty, this would Release the object.

I imagine it wouldn't be hard to add behavior like this in SmallScript.

Ian



Wed, 14 Jan 2004 00:49:19 GMT  
 Why doesn't Smalltalk support explicit deallocation?

Quote:

... snip ...

> One thing I thought would be useful is for some objects to have a
reference
> count, or specify that certain objects are additionally reference counted
in
> the garbage collection algorithm.  Or for some resources, this could even
be
> managed explicitly in Smalltalk/SmallScript as opposed to by the VM.  For
> resources, especially ones such as large Bitmaps, its important to release
> them immediately after they are not used.  Whenever you reference a
Bitmap,
> you could explicity increase a reference count, or add yourself to a Set
of
> objects that are referencing it, and when you're done you would remove
> yourself from the set or decrease the reference count.  When the Set or
> count is empty, this would Release the object.

> I imagine it wouldn't be hard to add behavior like this in SmallScript.

What you're describing does not need some feature or SmallScript. I've done
this kind of thing for years in classic Smalltalk. It just requires
providing a reference count mechanism explicitly in your code. There are
numerous good examples of this technique in the Objective-C [C with
Smalltalk features] language.

What SmallScript can do, is make this simpler and easier to implement. If
you go back to my example posted on "An aspect style example" some weeks
back, you'll see discusion of around methods.

That technique could be used to provide reference counting around
getter/setter fields for some limited set of client objects. Similarly,
managed object services for read/write barriers/delegation could also be
used to simplify some issues regarding reference counting.

Off the top of my head, I cannot think of an efficient mechanism to say
"notify me of all clients that reference or release a reference to me". To
do so, would require that all read/write operations (assignments [including
stack references]) tracking/examining the object being assigned in some way
shape or form. That is a "relatively" expensive thing to do and would slow
down performance significantly [which is why reference counted systems are
generally slower unless there is hardware support].

The AOS platform utilizes virtual memory hardware support to avoid needing
to have any "explicit" intergenerational/remember-set assignment tracking
(which is a slightly cheaper equivalent to ref-counting in non-ref-counted
GC systems). In other words, the AOS Platform does not even pay the typical
"explicit" costs for maintaining remembered-sets. It turns out that on
modern cpu cache architectures the virtual-memory tracking mechanism can
actually be used to improve caching performance. Which in turn mean that
overall performance with this technique is relatively unnaffected, whereas
explicitly tracking remembered-sets is "probably" not.

--
-- Dave S. [ http://www.smallscript.net ]
   Smalltalk for the AOS Platform and The Microsoft.NET Framework

- Show quoted text -

Quote:

> Ian



Wed, 14 Jan 2004 02:45:27 GMT  
 Why doesn't Smalltalk support explicit deallocation?

Quote:


> >QKS Smalltalk has always provided a method call #Release which defaults to a
> >no-op in Object. But many other classes use it to release any elements or
> >external structures they are holding. This operation is part of the
> >lifecycle framework that includes object properties like
> >isCompoundStructureValid, isExternalized and messages like StartingUp,
> >ShuttingDown, etc.

> >The "actual" object memory itself is not released because that could lead to
> >pointer errors in the memory system. There are MOP facilities which an
> >implementor of #Release can use. These include:

> >a) Changing the class of the object to a generic class like ByteStorage or
> >Object, etc.

> >b) Changing the number of indexed slots to 0.

> >c) Changing the number of storage/struct bytes to 0 [byte-vars].

> >d) Clearing all the object properties to a default/pristine state.

> >e) Clearing all the named slots to <nil>.

> >There is a single VM message that [off the top of my head I think] provides
> >this in one shot: #basicClearAll.

> >There are numerous reasons why this could be a dangerous set of operations
> >even with informed understanding. Fundamentally you may be breaking any
> >number of contracts in the system based on other objects referencing the
> >object you are attempting to deallocate. That is the main reason why the
> >mechanics in up to the class implementor and handled through the #Release
> >method. The default implementation of #Finalize calls #Release.

> One thing I thought would be useful is for some objects to have a reference
> count, or specify that certain objects are additionally reference counted in
> the garbage collection algorithm.  Or for some resources, this could even be
> managed explicitly in Smalltalk/SmallScript as opposed to by the VM.  For
> resources, especially ones such as large Bitmaps, its important to release
> them immediately after they are not used.

WE asked about this years ago and got not real response.  It was for this exact
reason.  And it is not even real explicit deallocation.  It is simply a way of
saying to the VM, attempt to CG this one object.  Now of course at the point you
are doing that you would not want to be referencing it by anything but a weak
collection.  But it is a lot different from saying do a global GC now.

- Show quoted text -

Quote:
> Whenever you reference a Bitmap,
> you could explicity increase a reference count, or add yourself to a Set of
> objects that are referencing it, and when you're done you would remove
> yourself from the set or decrease the reference count.  When the Set or
> count is empty, this would Release the object.

> I imagine it wouldn't be hard to add behavior like this in SmallScript.

> Ian



Thu, 15 Jan 2004 08:40:37 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Why doesn't everybody use smalltalk?

2. Why doesn't everybody use smalltalk?

3. why isn't the environment explicit ?

4. The Smalltalk Store: Why we've been slow, and why we're getting better

5. BUG: StatusBar doesn't support font changing

6. VIEW doesn't support PUT?!?

7. Driver doesn't support transaction framing

8. DBInfo()/DBFNTX Doesn't Support DBI_FULLPATH?

9. MIT scheme doesn't support define-macro ?

10. CosmoPlayer (SGI) doesn't support my vrmlscript

11. g77 doesn't support select case?

12. urllib doesn't support proxies: until now!

 

 
Powered by phpBB® Forum Software