Zombie Instances

Hi,

I'm trying to delete 2 classes (a model and a presenter) that I just
sued for some testing.

However, Everytime I try to delete them, I get an error complaining
that each one has an instance. I don't have any worspaces with
instances of it or anything like that.

How do I get rid of those pesky classes? O:-)

Thanks

On Wed, 30 Mar 2005 13:07:21 +0200, Fernando  <[hidden email]> wrote:

>Hi,
>
>I'm trying to delete 2 classes (a model and a presenter) that I just
>sued for some testing.

Used, of course.

I'm slightly upset with their behavior, but not enough to go ahead and
sue them. ;-)

Fernando,

> How do I get rid of those pesky classes? O:-)

The usual reason is that they are being referenced by a zombie view, so
using the "panic" button should get rid of them.

If not, and you don't want to track down what's causing the problem, you can
try evaluating ...

YourClassName allInstances do: [:each | each become: String new]

... which should turn them all into empty Strings that will be garbage
collected normally.  Be a bit careful though, make sure you backup the image
and/or your packages first.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Fernando" <[hidden email]> wrote in message
news:[hidden email]...
> On Wed, 30 Mar 2005 13:07:21 +0200, Fernando  <[hidden email]> wrote:
> >I'm trying to delete 2 classes (a model and a presenter) that I just
> >sued for some testing.
>
> I'm slightly upset with their behavior, but not enough to go ahead and
> sue them. ;-)

first backup your image, and then click on "Panic" button (screaming face),
on the main dolphin window, that often helps. Also as an excercise, you
could try to rebuild your image from your packages, just to make sure that
you can, and that there are no suprises in that area.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

On Wed, 30 Mar 2005 14:45:18 +0200, "rush" <[hidden email]>
wrote:


>first backup your image, and then click on "Panic" button (screaming face),
>on the main dolphin window, that often helps. Also as an excercise, you
>could try to rebuild your image from your packages, just to make sure that
>you can, and that there are no suprises in that area.


Actually, that's a very good idea. :-)

On Wed, 30 Mar 2005 13:42:13 +0100, "Ian Bartholomew"
<[hidden email]> wrote:


>If not, and you don't want to track down what's causing the problem, you can
>try evaluating ...
>
>YourClassName allInstances do: [:each | each become: String new]
>
>... which should turn them all into empty Strings that will be garbage
>collected normally.  Be a bit careful though, make sure you backup the image
>and/or your packages first.

Interesting. Is there any reason to use String, or any other class
would have worked?

Also, is there a way to tell the GC to garbage collect now?

Fernando,

> Interesting. Is there any reason to use String, or any other class
> would have worked?

Good question,  I use String because "it's the way I've always done it".  I
would guess it's just because String is quite a primitive Object, and
similar classes would probably work as well, but I could well be wrong.

> Also, is there a way to tell the GC to garbage collect now?

MemoryManager current collectGarbage

It might not work in quite the way you expect (some objects may need a
number of garbage collection cycles before they disappear) so it might be
worth having a read of the class and method comment first.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian Bartholomew escribió:
> Fernando,
>>Interesting. Is there any reason to use String, or any other class
>>would have worked?

> Good question,  I use String because "it's the way I've always done it".  I
> would guess it's just because String is quite a primitive Object, and
> similar classes would probably work as well, but I could well be wrong.

Nothing more simpler and faster* than "Object new", that's one of
the few cases where i've found useful to instance Object.

The other is to peek or readUpTo: for an unexistent object (in
streams usually).


* About a half in Dolphin, and a quarter in VSE
Dolphin results:
Time millisecondsToRun: [10000000 timesRepeat: [String new]] -> 2511
Time millisecondsToRun: [10000000 timesRepeat: [Object new]] -> 1235
Of course... the impact is very low, unless you have millions of
objects :-) (where the problem may start to be the GC of them).

Regards,

--
Esteban A. Maringolo
[hidden email]

On Wed, 30 Mar 2005 12:21:12 -0300, "Esteban A. Maringolo"
<[hidden email]> wrote:


>> Good question,  I use String because "it's the way I've always done it".  I
>> would guess it's just because String is quite a primitive Object, and
>> similar classes would probably work as well, but I could well be wrong.
>
>Nothing more simpler and faster* than "Object new", that's one of
>the few cases where i've found useful to instance Object.

I was expecting ProtoObject to be slightly faster, but actually it was
the opposite.

On Wed, 30 Mar 2005 13:42:13 +0100, "Ian Bartholomew"
<[hidden email]> wrote:


>If not, and you don't want to track down what's causing the problem, you can
>try evaluating ...
>
>YourClassName allInstances do: [:each | each become: String new]

BTW, what are other wise usages of #become:?

Seems great to get in serious trouble, but there must be situations
where it's a good solution.

Fernando,

> I was expecting ProtoObject to be slightly faster, but actually it was
> the opposite.

Just a guess, but the VM might give special treatment to Object but not
ProtoObject??  Failing primitives with backup Smalltalk code would allow
things to work, though more slowly than if primitives doing the heavy
lifting.  I don't have an old image that will load right now, so I can't
check whether ProtoObject was present in 3.x - anybody?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

ProtoObject is in Dolphin 3.05. All methods in it are identical to Object
except debugPrintString and inspect (I would have though they all should be
identical).

John

"Bill Schwab" <[hidden email]> wrote in message
news:d2hgm5$1gk8$[hidden email]...

John,

> ProtoObject is in Dolphin 3.05. All methods in it are identical to Object
> except debugPrintString and inspect (I would have though they all should be
> identical).

At home, I have a machine that is still willing to run 3.06.  I think I
see what you are describing, but suspect the idea was to keep the
ProtoObject protocol as small/simple as possible.

Of course, it is still possible that failing primitives would explain
any performance hit, either because the VM treats Object more kindly
than ProtoObject, or perhaps because the leaner protocol avoids some
optimizations.  The latter occurs to me based on your observation.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill, et al,

> [...]

I don't see any difference between Object new and ProtoObject new, unless maybe
there's a very tiny difference at the very edge of resolution.

Times from D5.1.4 running on WinXP Pro. 1.5 GHz. Timings compensate for the
loop overhead, and the uncertainty is in the last digit, probably not more than
+/- 0.5 nanosecs.

    Object new                70.8 nanoseconds
    ProtoObject new        71.9 nanoseconds
    Utilities new               72.1 nanoseconds

(Utilities is just a randomly chosen subclass of Object with no instance
variables or initialisation)

OTOH:

    String new                  209.1 nanoseconds
    ByteArray new            207.8 nanoseconds

but that's mostly because String>>new doesn't immediately hit a VM primitive.
A more direct String creation expression:

    String new: 0                86.1 nanoseconds
    ByteArray new: 0          86.9 nanoseconds

is more comparable with Object.  Presumably there's some residual extra
complexity in the String creation primitive -- having to initialise a length
field somewhere internally and initialise the implicit null-terminator.

    -- chris

Fernando,

> BTW, what are other wise usages of #become:?
>
> Seems great to get in serious trouble, but there must be situations
> where it's a good solution.

[I've been meaning to reply to this for quite a long time...]

I doubt if there are any wise uses at the level of modelling some domain.
Objects just don't turn into other objects.  For instance I don't think it
would be a good idea for an UnpaidInvoice to #become: a PaidInvoice when it was
paid.  If things can change status, then its better to model that explicitly.

(But it would be tempting, if the domain were Caterpillars and Butterflies (and
Pupae) to use #become: to implement the changes ;-)

OTOH, #become: has many uses at the infrastructure level. You'll find several
examples in the image already.  Here are a few more:

A common pattern for accessing data held externally to the image, but which
will be represented as proper objects in the image, is to create the internal
objects lazily.  E.g. if the data is held in a SQL database (or in a OODB like
Omnibase), you can use proxy objects to stand for data that has not yet been
read into the image, and then (using #doesNotUnderstand: handling) arrange for
the data to be read in when that proxy object is first actually used.  On a
system with a working #become: (like Dolphin) it is then very natural to create
a new object from the data and use #become: to make all references to the
now-useless proxy point to the new "real" object.  (And the same technique
could be used in reverse to "swap out" objects that haven't been used for a
while.)

In my JNIPort, I build objects that represent Java classes, but there are
several options for exactly what kinds of objects will be used (with different
tradeoffs between space/simplicity/power/convenience).  The logic for
installing the new objects is /very/ complicated, and so I don't want to couple
it to the (variable) logic for actually building/populating the new objects
(especially since one option uses Proxies to postpone the expensive build logic
until first-use).  So the way I've implemented it is that the system creates a
basic object that "knows" enough to be installable and installs it, and /then/
notifies a (pluggable) "Observer" which can create a more complicated
replacement and use #become: to swap that into place.  (Incidentally, I haven't
said enough here to show clearly /why/ it's necessary to decouple the build and
install logics so strongly; just take it on faith that it /is/ necessary -- the
point is that #become: provides an ideal solution to the design problem that
that would otherwise cause)

Another, slightly hacky, example from JNIPort.  The connection to a running
Java JVM is called a JNIEnv, and that has /lots/ of methods for invoking
various operations that lie at the heart of JNIPort.  One problem is that the
JVM can close itself down, and -- once it has done so -- any use of the JNIEnv
will quite probably crash Dolphin.  The "correct" solution would undoubtedly be
to maintain a flag somewhere to say whether the JVM had closed down, and check
that before /every/ use of the JNIEnv.  But, since the JNIEnv is used
everywhere, that solution would be extraordinarily clumsy.  An alternative
solution of making the JNIEnv itself "know" whether the JVM had closed down and
doing the check internally on every access would also be very clumsy -- just
because there are hundreds of access methods and they'd all have to do that
check.  In any case the checks would add a performance overhead that I don't
want.  So instead, I use two kinds of JNIEnv object, one is a "real" JNIEnv
that talks to the JVM; the other is a dummy implementation of the same protocol
that does nothing (a "null object" in fact).  When the system discovers that
the JVM has closed down, it simply creates a dummy JNIEnv and uses #become: to
swap it into place.  It can then initiate normal closedown without needing
special code to prevent the normal clean-up attempting to use the JNIEnv to
release resources and so on.

I don't think there are any design problems that can be solved using #become:
that couldn't also be solved by using an extra level of indirection
somewhere -- or, more likely, using an extra level of indirection /everywhere/.
But careful use of #become: can -- in some cases -- allow you to avoid that
additional complexity.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:425ba6bf$0$38041$[hidden email]...
> OTOH, #become: has many uses at the infrastructure level. You'll find
several
> examples in the image already.  Here are a few more:

Without intention to start programming style war,  I think one of the bigger
issues with become is problems it raises in implementations, especially ones
that try to bne smart and squeeze some more performance out of Smalltalk. In
another words, even in situation when usage of become truly simplifies
application, it is probably way to strong agent to be applied.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/