Method #release: Intention and Sender?
Locked
Method #release: Intention and Sender?
 
|
Hello. |
Re: Method #release: Intention and Sender?
|
|
IME, the method #release is used to let go of resources that
are registered and allocated while an object is expected to meet its
obligations. So, for example, if you have a UI that has dependents in
terms of events, #release is a good place to break such dependencies. In
some other cases, #release can be used to deallocate OS
resources.
Perhaps you are thinking of #finalize and #mourn instead
of #release. However, note that the garbage collector does not send these
messages. Rather, the image sends them. Weak objects and ephemerons
are put on a queue by the GC. This queue is drained from the image, and it
is up to the image to send #finalize and/or #mourn to these objects when
necessary.
As usual, automatic GC removes weak objects and ephemerons
when they are no longer referenced (not even from, for example, the finalization
queue). Typically, what happens with ephemerons is that the finalization
action also removes references to them after they are triggered and stop being
active ephemerons. Hence, they get collected in the next GC cycle.
Weak references are zeroed out by the GC before weak objects are placed in the
finalization queue. Weak objects themselves, like any other objects, are
collected when they are no longer referenced strongly. From: [hidden email] [mailto:[hidden email]] On Behalf Of Gruenewald, Tom Sent: Tuesday, April 27, 2010 8:37 AM To: vwnc Subject: [vwnc] Method #release: Intention and Sender? Hello. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Method #release: Intention and Sender?
|
|
In reply to this post by Gruenewald, Tom
Yes, your impression was wrong. By default, the system will
not send any message to objects which are garbage collected. Part of what
makes the garbage collection fast is that it doesn't even look at the
garbage objects - it goes over the live objects, and anything which
wasn't live is dead, and is left behind in the previous space to be
written over. Well, it's a little more complicated than that, but that's
the essence.
It is possible to register objects for finalization, with two different mechanisms, the older WeakArray method, which requires you to keep a copy of the object around to be send the message once the original is dead, and the newer Ephemeron method which sends it directly to the original object. But neither of these sends #release by default. In general, once your application is done with an object you can send release to it. Some parts of the framework do this automatically, e.g. releasing window sub-components when the parent closes. But most of the time it's not necessary because the garbage collector will take care of it, and it's only required for cases where you have to do something like release operating system memory, or tell the database that you're done with the connection. At 11:36 AM 2010-04-27, Gruenewald, Tom wrote: Hello. --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Method #release: Intention and Sender?
|
|
In reply to this post by Gruenewald, Tom
Weaklings package has some nice methods for handling expiring objects, for instance you can register something for cleanup when it's about to be GCed,
initialize super initialize. self mourn: [:dying | dying cleanup]. -Boris (via BlackBerry) From: [hidden email] <[hidden email]> To: Gruenewald, Tom <[hidden email]>; vwnc <[hidden email]> Sent: Tue Apr 27 09:25:18 2010 Subject: Re: [vwnc] Method #release: Intention and Sender? It is possible to register objects for finalization, with two different mechanisms, the older WeakArray method, which requires you to keep a copy of the object around to be send the message once the original is dead, and the newer Ephemeron method which sends it directly to the original object. But neither of these sends #release by default. In general, once your application is done with an object you can send release to it. Some parts of the framework do this automatically, e.g. releasing window sub-components when the parent closes. But most of the time it's not necessary because the garbage collector will take care of it, and it's only required for cases where you have to do something like release operating system memory, or tell the database that you're done with the connection. At 11:36 AM 2010-04-27, Gruenewald, Tom wrote: Hello. --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Method #release: Intention and Sender?
|
|
In reply to this post by Gruenewald, Tom
Tom Over 20 years ago, #release
assisted the garbage collector in collecting objects. As part of its
#release method, the object would nil out its references. Old garbage
collectors did not deal well with garbage reference cycles. Terry From: [hidden email] [mailto:[hidden email]] On
Behalf Of Gruenewald, Tom Hello. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Method #release: Intention and Sender?
|
|
In reply to this post by Alan Knight-2
Currently I find that if I use huge Byte Arrays for
PDF printing or LOB attachement my image increases in size (lost space not being
reclaimed ?).
Are the things discussed here the ways to clean
things properly.
Regards,
@+Maaten,
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Method #release: Intention and Sender?
|
|
If you use large byte arrays that do not fit in large
space, then you will create large old segments. After the large
segments are created, chances are objects other than the large byte
arrays will find a nice home there. If data compaction does not
free the large segments completely, they won't be deallocated. Thus, it
may seem as if you are not "cleaning stuff up". However, this scenario is
normal and, typically, the memory policy will eventually take care of
it. From: [hidden email] [mailto:[hidden email]] On Behalf Of Maarten MOSTERT Sent: Tuesday, April 27, 2010 12:32 PM To: vwnc Subject: Re: [vwnc] Method #release: Intention and Sender? Currently I find that if I use huge Byte Arrays for
PDF printing or LOB attachement my image increases in size (lost space not being
reclaimed ?).
Are the things discussed here the ways to clean
things properly.
Regards,
@+Maaten,
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: Method #release: Intention and Sender?
|
|
In reply to this post by Gruenewald, Tom
One of the places where it is necessary to implement #release are the Views (DependentPart to be more exact) and various ProtocolAdaptor classes. They are dependent on the model, and they are being held strongly in the dependents field of the model, so if you just close the window, they are still being referenced from the model. Therefore, DependentPart >> #release sends a 'model removeDependent: self' in order to break this dependency. In more complicated situations (like reusing several subcanvases for displaying appropriate UIs for editing properties of some items in a list), breaking these dependencies correctly can become a serious pain. Is there any reason these dependencies are not weak? Taking care of references manually reminds me of my C++ days, and I can't exactly say I remember them with a joyful nostalgia :)
Best regards, Tomas Dvorak On Tue, 27 Apr 2010 17:36:43 +0200, Gruenewald, Tom <[hidden email]> wrote: > > > Hello. > What is the actual intention of the method #release? And who should send > or > perform it? > > For me #release was always the last action, performed by the garbage > collector, before it send an object from the working memory (RAM) to the > ultimate nirvana. > Alternatively I understood the #release method as opportunity, to force > the > garbage collector to release an object from the working memory. > > The comment in class Object says: > "Remove references to objects that may refer to the receiver. Answers > self. > This message should be overridden by subclasses with any cycles, in > which > case the subclass should also include the expression super release." > > Now I am confused. Had I a wrong understanding of the release method all > the time? And the release method has in fact nothing to do with the > memory > release? Instead it simply breaks cycle dependents? > Must I be more concerned about the memory release? Until now I had relied > (in most cases) on the automatic garbage collector. > > Thank you for your answers. Maybe you can point me to any documentation. > > Best regards, > Tom Grünewald > > ________ > > Carl Zeiss Industrielle Messtechnik GmbH > Softwareentwicklung/Software Development > > T o m G r ü n e w a l d > > 73446 Oberkochen, Germany > tel: +49.7364.20-8541 > fax: +49.7364.20-4800 > email: [hidden email] > http://www.zeiss.de/imt > > Carl Zeiss Industrielle Messtechnik GmbH, Carl-Zeiss-Straße 22, 73447 > Oberkochen > Aufsichtsratsvorsitzender: Dr. Dieter Kurz > Geschäftsführer: Dr. Rainer Ohnheiser, Felix Hoben, Hanspeter Mürle > Sitz der Gesellschaft: 73446 Oberkochen, Deutschland > Handelsregister: Amtsgericht Ulm, HRB 501561 > USt-IdNr.: DE 811 515 346 > > ---------------------------------------- > This message is intended for a particular addressee only and may contain > business or company secrets. If you have received this email in error, > please contact the sender and delete the message immediately. Any use of > this email, including saving, publishing, copying, replication or > forwarding of the message or the contents is not permitted. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |