[ENH] A better finalization support (VM & language side)
Locked
12
12
Re: [ENH] A better finalization support (VM & language side)
 
|
On Wed, 10 Mar 2010, Igor Stasenko wrote: > > On 10 March 2010 04:34, Levente Uzonyi <[hidden email]> wrote: >> >> On Tue, 9 Mar 2010, Igor Stasenko wrote: >> >>> >>> 2010/3/9 Levente Uzonyi <[hidden email]>: >>>> >>>> On Tue, 9 Mar 2010, Igor Stasenko wrote: >>>> >>>>> Well, if someone cares, then he actually can make own registry class, >>>>> which allows copying. But why we should care, by leaving a potential >>>>> security hole open? >>>>> I don't think that this is normal to rely on good manners of users and >>>>> expect them to not attempt to do something wrong. In contrast, a >>>>> protocols and interfaces should discourage user from abuse. At least, >>>>> an author could state where it is safe to use and where is not. >>>>> A copy protocol for weak registry is far from being safe. >>>>> In that situation is better to generate an error, indicating that such >>>>> use is not foreseen by author, rather than trying to implement >>>>> something which 'possibly could work' :) >>>> >>>> I still don't see how is it unsafe. >>>> >>> >>> A simple copy is fine. A copy, which then registered in weak >>> dependents creating a problem. >>> >>> I even think that weak registry should not behave as collection at all, >>> and having only #add: method, with no ability to remove items. >>> >>> The only use of #remove: i see is in Socket and StandardFileStream, >>> which implement #unregister: in own class side. >>> >>> Now , if you look at my implementation, you could see that there is a >>> way to completely avoid the need in removing items from a >>> valueDictionary which is pairs of <weakref> -> <executor>. >>> >>> A solution: >>> - add a 'finalizer' ivar to Socket/StandardFileStream >>> - by registering a socket in registry, retrieve an instance of >>> WeakFinalizerItem as a result of registration and store it into >>> 'finalizer' ivar. >>> >>> - on #destroy, simply nil-out all of the finalizer's ivars, so there >>> is no chances that once socket become garbage, it will trigger an >>> executor's #finalize method, which were registered previously in >>> registry. >>> >>> - forget about removing the finalizer manually from registry, because >>> an instance of WeakFinalizerItem which is held by 'valueDictionary' in >>> registry will eventually be reclaimed, once dictionary will discover >>> that corresponding key is nil. >>> >>> What you think? >> >> I took a deeper look and found that WeakFinalizationRegistry doesn't support >> multiple finalizers per object. It does what WeakRegistry did before: throw >> away the previous finalizer and replace it with a new one. >> >> I like the current features of WeakRegistry (removing, adding, multiple >> finalizers per object) and I think it's easy to modify it to use your vm >> support. >> > > Sure, support for multiple finalizers per object could be added. But > as to me, this looks like an over-engineering. > > Btw, the current implementation of WeakRegistry is buggy, because of > use non-identity based dictionary. implement #= as #== and #hash as #scaledIdentityHash. But I already responded to this here: http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003960.html > Try explore contents of it, after evaluating: > > 10 timesRepeat: [ registry add: (Array with:10) ]. > it adds only a single key/value pair into valueDictionary, > while i'd expect to have 10 entries, because i adding 10 distinct array objects. > The flaw in logic is easy to illustrate: > > array1 := Array with: 10. > array2 := Array with: 10. > > registry add: array1; array2. > array2 at: 1 put: 12. > registry add: array2. > > array1 := nil "remove strong reference to array1, while keep it for array2" > > The point is, that if two disctinct objects answering true on #= , > when we adding them to registry > it doesn't means that they will keep to be 'equal' after we added > them, because these objects can mutate. > So, if one of them eventually die, other(s) may still be in use, which > will lead to receiving a death notice to wrong recipient. > >> I don't really like your suggestion for files and sockets, but it's doable. >> >> I was thinking about a simpler registry which would use an OrderedCollection >> instead of a WeakKeyDictionary. It'd need a new instance variable in >> WeakFinalizerItem (though it can be another class/subclass too) which would >> store the index of the finalizer in this OrderedCollection. It wouldn't have >> #do:, #keys or #remove:ifAbsent: (though all of them could be implemented) >> and #add: wouldn't replace existing finalizers, but just add them to the >> registry. >> This would have a bit better performance, simpler implementation and less >> features. But if you don't need #remove:, i'm sure it'd fit your needs. >> (It's a bit tricky though. Your socket/file ideas wouldn't work out of the >> box, because all of the WeakFinalizerItems would have to be removed from the >> OrderedCollecion somehow to avoid leaking memory. One solution would be to >> add it to the list on "remove" (when replacing the ivars with nil), another >> would be to remove it from the OrderedCollection by index, but the items >> don't know their collection so it would need another ivar). >> >> All in all, I'd keep WeakRegistry with the current features and optionally >> add a new simpler and faster registry if needed. >> > > Yes, i'm also thought about different ways how to organize things in > less memory & CPU hungry manner. > The main role of weak registry is to receive a notification, when > particular object become garbage. > Obviously, for this, we need to store a reference to notification > handler (also known as executor) somewhere to > be able to handle it. That's why current implementation using WeakKeyDictionary. > Once such notification is handled, we usually no longer need to keep > this object as well (thus we have to remove/unlink it from registry). registries are notified when their objects are gone. Did I miss something? If not, then #finalizeValues is still sent by the finalization process of WeakArray when it's semaphore is signaled, so one just has to register it's registry there. Levente > > My implementation is not perfect, it was mainly a quick and dirty hack > (you pointed on not using semaphores already). > But my intent was mainly to show how to use new VM feature, i added. > So, once it will be approved (i hope) and adopted, we could implement > things properly. > >> >> Levente >> > > -- > Best regards, > Igor Stasenko AKA sig. > |
Re: [ENH] A better finalization support (VM & language side)
|
|
2010/3/10 Levente Uzonyi <[hidden email]>: > > On Wed, 10 Mar 2010, Igor Stasenko wrote: > >> >> On 10 March 2010 04:34, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Tue, 9 Mar 2010, Igor Stasenko wrote: >>> >>>> >>>> 2010/3/9 Levente Uzonyi <[hidden email]>: >>>>> >>>>> On Tue, 9 Mar 2010, Igor Stasenko wrote: >>>>> >>>>>> Well, if someone cares, then he actually can make own registry class, >>>>>> which allows copying. But why we should care, by leaving a potential >>>>>> security hole open? >>>>>> I don't think that this is normal to rely on good manners of users and >>>>>> expect them to not attempt to do something wrong. In contrast, a >>>>>> protocols and interfaces should discourage user from abuse. At least, >>>>>> an author could state where it is safe to use and where is not. >>>>>> A copy protocol for weak registry is far from being safe. >>>>>> In that situation is better to generate an error, indicating that such >>>>>> use is not foreseen by author, rather than trying to implement >>>>>> something which 'possibly could work' :) >>>>> >>>>> I still don't see how is it unsafe. >>>>> >>>> >>>> A simple copy is fine. A copy, which then registered in weak >>>> dependents creating a problem. >>>> >>>> I even think that weak registry should not behave as collection at all, >>>> and having only #add: method, with no ability to remove items. >>>> >>>> The only use of #remove: i see is in Socket and StandardFileStream, >>>> which implement #unregister: in own class side. >>>> >>>> Now , if you look at my implementation, you could see that there is a >>>> way to completely avoid the need in removing items from a >>>> valueDictionary which is pairs of <weakref> -> <executor>. >>>> >>>> A solution: >>>> - add a 'finalizer' ivar to Socket/StandardFileStream >>>> - by registering a socket in registry, retrieve an instance of >>>> WeakFinalizerItem as a result of registration and store it into >>>> 'finalizer' ivar. >>>> >>>> - on #destroy, simply nil-out all of the finalizer's ivars, so there >>>> is no chances that once socket become garbage, it will trigger an >>>> executor's #finalize method, which were registered previously in >>>> registry. >>>> >>>> - forget about removing the finalizer manually from registry, because >>>> an instance of WeakFinalizerItem which is held by 'valueDictionary' in >>>> registry will eventually be reclaimed, once dictionary will discover >>>> that corresponding key is nil. >>>> >>>> What you think? >>> >>> I took a deeper look and found that WeakFinalizationRegistry doesn't support >>> multiple finalizers per object. It does what WeakRegistry did before: throw >>> away the previous finalizer and replace it with a new one. >>> >>> I like the current features of WeakRegistry (removing, adding, multiple >>> finalizers per object) and I think it's easy to modify it to use your vm >>> support. >>> >> >> Sure, support for multiple finalizers per object could be added. But >> as to me, this looks like an over-engineering. >> >> Btw, the current implementation of WeakRegistry is buggy, because of >> use non-identity based dictionary. > > Buggy is a bit strong, it just doesn't support objects which don't implement #= as #== and #hash as #scaledIdentityHash. But I already responded to this here: http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003960.html > Okay. It is not buggy. It is wrong. :) >> Try explore contents of it, after evaluating: >> >> 10 timesRepeat: [ registry add: (Array with:10) ]. >> it adds only a single key/value pair into valueDictionary, >> while i'd expect to have 10 entries, because i adding 10 distinct array objects. >> The flaw in logic is easy to illustrate: >> >> array1 := Array with: 10. >> array2 := Array with: 10. >> >> registry add: array1; array2. >> array2 at: 1 put: 12. >> registry add: array2. >> >> array1 := nil "remove strong reference to array1, while keep it for array2" >> >> The point is, that if two disctinct objects answering true on #= , >> when we adding them to registry >> it doesn't means that they will keep to be 'equal' after we added >> them, because these objects can mutate. >> So, if one of them eventually die, other(s) may still be in use, which >> will lead to receiving a death notice to wrong recipient. >> >>> I don't really like your suggestion for files and sockets, but it's doable. >>> >>> I was thinking about a simpler registry which would use an OrderedCollection >>> instead of a WeakKeyDictionary. It'd need a new instance variable in >>> WeakFinalizerItem (though it can be another class/subclass too) which would >>> store the index of the finalizer in this OrderedCollection. It wouldn't have >>> #do:, #keys or #remove:ifAbsent: (though all of them could be implemented) >>> and #add: wouldn't replace existing finalizers, but just add them to the >>> registry. >>> This would have a bit better performance, simpler implementation and less >>> features. But if you don't need #remove:, i'm sure it'd fit your needs. >>> (It's a bit tricky though. Your socket/file ideas wouldn't work out of the >>> box, because all of the WeakFinalizerItems would have to be removed from the >>> OrderedCollecion somehow to avoid leaking memory. One solution would be to >>> add it to the list on "remove" (when replacing the ivars with nil), another >>> would be to remove it from the OrderedCollection by index, but the items >>> don't know their collection so it would need another ivar). >>> >>> All in all, I'd keep WeakRegistry with the current features and optionally >>> add a new simpler and faster registry if needed. >>> >> >> Yes, i'm also thought about different ways how to organize things in >> less memory & CPU hungry manner. >> The main role of weak registry is to receive a notification, when >> particular object become garbage. >> Obviously, for this, we need to store a reference to notification >> handler (also known as executor) somewhere to >> be able to handle it. That's why current implementation using WeakKeyDictionary. >> Once such notification is handled, we usually no longer need to keep >> this object as well (thus we have to remove/unlink it from registry). > > I didn't see any code in your changesets that changed the way how weak registries are notified when their objects are gone. Did I miss something? > If not, then #finalizeValues is still sent by the finalization process of WeakArray when it's semaphore is signaled, so one just has to register it's registry there. > Well, looks like you paying too much attention to implementation details and don't see the whole idea behind this. Its not really matter in what way you receiving such notification , what matters is that sometimes you need to be able to receive a notification when some object become garbage. This is the reason why we having a WeakRegistry. > > Levente > >> >> My implementation is not perfect, it was mainly a quick and dirty hack >> (you pointed on not using semaphores already). >> But my intent was mainly to show how to use new VM feature, i added. >> So, once it will be approved (i hope) and adopted, we could implement >> things properly. >> >>> >>> Levente >>> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > -- Best regards, Igor Stasenko AKA sig. |
Re: [ENH] A better finalization support (VM & language side)
|
|
On 10 March 2010 06:03, Igor Stasenko <[hidden email]> wrote: > 2010/3/10 Levente Uzonyi <[hidden email]>: >> >>> The main role of weak registry is to receive a notification, when >>> particular object become garbage. >>> Obviously, for this, we need to store a reference to notification >>> handler (also known as executor) somewhere to >>> be able to handle it. That's why current implementation using WeakKeyDictionary. >>> Once such notification is handled, we usually no longer need to keep >>> this object as well (thus we have to remove/unlink it from registry). >> >> I didn't see any code in your changesets that changed the way how weak registries are notified when their objects are gone. Did I miss something? >> If not, then #finalizeValues is still sent by the finalization process of WeakArray when it's semaphore is signaled, so one just has to register it's registry there. >> > > Well, looks like you paying too much attention to implementation > details and don't see the whole idea behind this. > Its not really matter in what way you receiving such notification , > what matters is that sometimes you need to be able to receive > a notification when some object become garbage. This is the reason why > we having a WeakRegistry. > Think of following potential implementation: SocketHandle>>initialize: ... .... socketHandle := self primSocketCreateNetwork: 0 type: socketType receiveBufferSize: 8000 sendBufSize: 8000 semaIndex: semaIndex readSemaIndex: readSemaIndex writeSemaIndex: writeSemaIndex. socketHandle ifNotNil: [ self onDeathDo: [ Socket primSocketDestroyGently: socketHandle. Smalltalk unregisterExternalObject: semaphore. Smalltalk unregisterExternalObject: readSemaphore. Smalltalk unregisterExternalObject: writeSemaphore. ] as simple as that. You just telling the system, that once socket object become garbage, evaluate the block - an argument of #onDeathDo: message. Do such pattern convincing you that what we talking here is about notification when particular object dies? Also, you may notice that given approach is much simpler and straightforward comparing to existing one, where you have to implement own #register:, #unregister: and #finalize? We could have such protocol (#myWill: , #cancelBurialCeremony ;) ) for all Objects in system, and don't pay attention anymore to speak directly to WeakRegistry. -- Best regards, Igor Stasenko AKA sig. |
Re: [ENH] A better finalization support (VM & language side)
|
|
In reply to this post by Igor Stasenko
On Wed, 10 Mar 2010, Igor Stasenko wrote: > > 2010/3/10 Levente Uzonyi <[hidden email]>: >> >> On Wed, 10 Mar 2010, Igor Stasenko wrote: >> >>> >>> On 10 March 2010 04:34, Levente Uzonyi <[hidden email]> wrote: >>>> >>>> On Tue, 9 Mar 2010, Igor Stasenko wrote: >>>> >>>>> >>>>> 2010/3/9 Levente Uzonyi <[hidden email]>: >>>>>> >>>>>> On Tue, 9 Mar 2010, Igor Stasenko wrote: >>>>>> >>>>>>> Well, if someone cares, then he actually can make own registry class, >>>>>>> which allows copying. But why we should care, by leaving a potential >>>>>>> security hole open? >>>>>>> I don't think that this is normal to rely on good manners of users and >>>>>>> expect them to not attempt to do something wrong. In contrast, a >>>>>>> protocols and interfaces should discourage user from abuse. At least, >>>>>>> an author could state where it is safe to use and where is not. >>>>>>> A copy protocol for weak registry is far from being safe. >>>>>>> In that situation is better to generate an error, indicating that such >>>>>>> use is not foreseen by author, rather than trying to implement >>>>>>> something which 'possibly could work' :) >>>>>> >>>>>> I still don't see how is it unsafe. >>>>>> >>>>> >>>>> A simple copy is fine. A copy, which then registered in weak >>>>> dependents creating a problem. >>>>> >>>>> I even think that weak registry should not behave as collection at all, >>>>> and having only #add: method, with no ability to remove items. >>>>> >>>>> The only use of #remove: i see is in Socket and StandardFileStream, >>>>> which implement #unregister: in own class side. >>>>> >>>>> Now , if you look at my implementation, you could see that there is a >>>>> way to completely avoid the need in removing items from a >>>>> valueDictionary which is pairs of <weakref> -> <executor>. >>>>> >>>>> A solution: >>>>> - add a 'finalizer' ivar to Socket/StandardFileStream >>>>> - by registering a socket in registry, retrieve an instance of >>>>> WeakFinalizerItem as a result of registration and store it into >>>>> 'finalizer' ivar. >>>>> >>>>> - on #destroy, simply nil-out all of the finalizer's ivars, so there >>>>> is no chances that once socket become garbage, it will trigger an >>>>> executor's #finalize method, which were registered previously in >>>>> registry. >>>>> >>>>> - forget about removing the finalizer manually from registry, because >>>>> an instance of WeakFinalizerItem which is held by 'valueDictionary' in >>>>> registry will eventually be reclaimed, once dictionary will discover >>>>> that corresponding key is nil. >>>>> >>>>> What you think? >>>> >>>> I took a deeper look and found that WeakFinalizationRegistry doesn't support >>>> multiple finalizers per object. It does what WeakRegistry did before: throw >>>> away the previous finalizer and replace it with a new one. >>>> >>>> I like the current features of WeakRegistry (removing, adding, multiple >>>> finalizers per object) and I think it's easy to modify it to use your vm >>>> support. >>>> >>> >>> Sure, support for multiple finalizers per object could be added. But >>> as to me, this looks like an over-engineering. >>> >>> Btw, the current implementation of WeakRegistry is buggy, because of >>> use non-identity based dictionary. >> >> Buggy is a bit strong, it just doesn't support objects which don't implement #= as #== and #hash as #scaledIdentityHash. But I already responded to this here: http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003960.html >> > > Okay. It is not buggy. It is wrong. :) > I added a fix to the trunk. :) >>> Try explore contents of it, after evaluating: >>> >>> 10 timesRepeat: [ registry add: (Array with:10) ]. >>> it adds only a single key/value pair into valueDictionary, >>> while i'd expect to have 10 entries, because i adding 10 distinct array objects. >>> The flaw in logic is easy to illustrate: >>> >>> array1 := Array with: 10. >>> array2 := Array with: 10. >>> >>> registry add: array1; array2. >>> array2 at: 1 put: 12. >>> registry add: array2. >>> >>> array1 := nil "remove strong reference to array1, while keep it for array2" >>> >>> The point is, that if two disctinct objects answering true on #= , >>> when we adding them to registry >>> it doesn't means that they will keep to be 'equal' after we added >>> them, because these objects can mutate. >>> So, if one of them eventually die, other(s) may still be in use, which >>> will lead to receiving a death notice to wrong recipient. >>> >>>> I don't really like your suggestion for files and sockets, but it's doable. >>>> >>>> I was thinking about a simpler registry which would use an OrderedCollection >>>> instead of a WeakKeyDictionary. It'd need a new instance variable in >>>> WeakFinalizerItem (though it can be another class/subclass too) which would >>>> store the index of the finalizer in this OrderedCollection. It wouldn't have >>>> #do:, #keys or #remove:ifAbsent: (though all of them could be implemented) >>>> and #add: wouldn't replace existing finalizers, but just add them to the >>>> registry. >>>> This would have a bit better performance, simpler implementation and less >>>> features. But if you don't need #remove:, i'm sure it'd fit your needs. >>>> (It's a bit tricky though. Your socket/file ideas wouldn't work out of the >>>> box, because all of the WeakFinalizerItems would have to be removed from the >>>> OrderedCollecion somehow to avoid leaking memory. One solution would be to >>>> add it to the list on "remove" (when replacing the ivars with nil), another >>>> would be to remove it from the OrderedCollection by index, but the items >>>> don't know their collection so it would need another ivar). >>>> >>>> All in all, I'd keep WeakRegistry with the current features and optionally >>>> add a new simpler and faster registry if needed. >>>> >>> >>> Yes, i'm also thought about different ways how to organize things in >>> less memory & CPU hungry manner. >>> The main role of weak registry is to receive a notification, when >>> particular object become garbage. >>> Obviously, for this, we need to store a reference to notification >>> handler (also known as executor) somewhere to >>> be able to handle it. That's why current implementation using WeakKeyDictionary. >>> Once such notification is handled, we usually no longer need to keep >>> this object as well (thus we have to remove/unlink it from registry). >> >> I didn't see any code in your changesets that changed the way how weak registries are notified when their objects are gone. Did I miss something? >> If not, then #finalizeValues is still sent by the finalization process of WeakArray when it's semaphore is signaled, so one just has to register it's registry there. >> > > Well, looks like you paying too much attention to implementation > details and don't see the whole idea behind this. > Its not really matter in what way you receiving such notification , > what matters is that sometimes you need to be able to receive > a notification when some object become garbage. This is the reason why > we having a WeakRegistry. WeakKeyDictionary, but I didn't. Levente > >> >> Levente >> >>> >>> My implementation is not perfect, it was mainly a quick and dirty hack >>> (you pointed on not using semaphores already). >>> But my intent was mainly to show how to use new VM feature, i added. >>> So, once it will be approved (i hope) and adopted, we could implement >>> things properly. >>> >>>> >>>> Levente >>>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
Re: [ENH] A better finalization support (VM & language side)
|
|
Guys, i need your opinion on this. What are you generally thinking about this idea? If it ok in general, and you want it to be in VM, then i will continue with my effort to fix all remarks, which Levente and others pointed out. But since only Levente and Andreas commented this so far, and i can't decide if this feature is accepted by others or not. If you think this is not the way to go, please explain why you think that. Sure thing i, as an author want this change to be integrated. -- Best regards, Igor Stasenko AKA sig. |
Re: [ENH] A better finalization support (VM & language side)
|
|
On Sat, Mar 13, 2010 at 3:45 PM, Igor Stasenko <[hidden email]> wrote:
I'm not sure I understand the semantics yet. Andreas and I discussed it a little today and we thought that is that it is a way of associating a finalizer with a specific object such that the such that the object is still alive when it is finalized. But now I reread your proposal it looks like the finalizer gets run only when its object has been collected.
The most important thing is for the finalization system not to be post-mortem (not run a finalization action when the object is already dead). Consider a buffered file. The finalization action should flush the buffer as well as close the file handle. If the finalization is post-mortem then one finalizes a copy of the file. Hence to ensure that the copy has the same buffer state one has to update the copy every time the real file's buffer changes state, and that's bad for performance.
If I've misunderstood the proposal then please try and write a more comprehensible specification. If however the proposal still does post-mortem finalization then IMO its not worth it and we should try and implement a pre-mortem scheme where the garbage collector detects when an object is about to be collected (usually implemented by the GC detecting when the object is only referenced from finalizers, and queueing the finalizers).
2¢ cheers Eliot
|
Re: [ENH] A better finalization support (VM & language side)
|
|
On 14 March 2010 03:25, Eliot Miranda <[hidden email]> wrote: > > > > On Sat, Mar 13, 2010 at 3:45 PM, Igor Stasenko <[hidden email]> wrote: >> >> Guys, i need your opinion on this. >> What are you generally thinking about this idea? >> If it ok in general, and you want it to be in VM, then i will continue >> with my effort to fix all remarks, which >> Levente and others pointed out. >> But since only Levente and Andreas commented this so far, and i can't >> decide if this feature is accepted by >> others or not. >> If you think this is not the way to go, please explain why you think that. >> Sure thing i, as an author want this change to be integrated. > > I'm not sure I understand the semantics yet. Andreas and I discussed it a little today and we thought that is that it is a way of associating a finalizer with a specific object such that the such that the object is still alive when it is finalized. But now I reread your proposal it looks like the finalizer gets run only when its object has been collected. > The most important thing is for the finalization system not to be post-mortem (not run a finalization action when the object is already dead). Consider a buffered file. The finalization action should flush the buffer as well as close the file handle. If the finalization is post-mortem then one finalizes a copy of the file. Hence to ensure that the copy has the same buffer state one has to update the copy every time the real file's buffer changes state, and that's bad for performance. Its not very good example to show an advantage of pre-mortem finalization over post-mortem. You could implement a correct finalization scheme of the above using post-mortem finalization, by simply keeping a buffer state in a separate object, to which both, an object (which is going to die) and finalizer (or executor) referencing: weak ref -> file (buffer, handle) strong ref -> finalizer of file (buffer , handle) in case , when file collected, you still having a valid reference to its buffer in finalizer, which having the very same state (since it is the same object), and so, you could flush that buffer and then close the handle without losing data. > If I've misunderstood the proposal then please try and write a more comprehensible specification. If however the proposal still does post-mortem finalization then IMO its not worth it and we should try and implement a pre-mortem scheme where the garbage collector detects when an object is about to be collected (usually implemented by the GC detecting when the object is only referenced from finalizers, and queueing the finalizers). I think you understood it well. Its a small modification to current post-mortem finalization, which allows us to react directly only on those objects, which been collected. To describe it primitively: Suppose that you having a number of weak references, held by a single container (WeakArray or other, not really matter). Now at some point you want to find out, how many of objects in it is collected after a while (you could choose to do a check immediately after each GC, or can do it periodically - not really matters). In current implementation it is possible to do it only by scanning a full contents of container , in order to find which references replaced by nil. In scheme which i proposed, you could avoid a full scan, which is in a linear dependency from container size, and react directly only on those elements which collected. This means that if your container size is X , old scheme implies to loop through X elements to find those who collected, while new scheme is always O(n), where n is the number of elements which being collected. > 2¢ > cheers > Eliot >> >> -- >> Best regards, >> Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |