Re: [Mono-dev] Reference queue
2012/1/24 Konrad M. konrad.kruczyn...@gmail.com Even if performance was backed in, it would not help a lot since you have the large bottleneck of file backed. As I said, I would rather not delete file directly on the callback's thread, but queue its deletion. Also the mentioned approach can be useful for other kinds of resources. I feel quite unease with publishing the current code as an API as it would require us to support it, which means we can't change it at all. I expect it to be exposed to further internal usage and which will better shape it. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
On Wed, 2012-02-01 at 22:04 -0200, Rodrigo Kumpera wrote: I expect it to be exposed to further internal usage and which will better shape it. I totally agree on this point. Maybe I could have some use on this via p/invoke to itself (using __Internal). What do you think? -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
On 2012-01-24 02:32, Robert Vesse wrote: If it is the case that you have unmanaged resources that you need to clean up that you should really be using the IDisposable interface and calling Dispose() on the class when you are done with it. If it is possible for code paths to 'forget' to call Dispose() then you can include a finalizer as well, if you do this you need to make sure that when Dispose() is explicitly called you call GC.SuppressFinalize() on that object so the finalizer can be skipped Ths MSDN has very comprehensive guidelines on implementing IDisposable and finalizers correctly: http://msdn.microsoft.com/en-us/library/system.idisposable.aspx There is also a simpler guide at http://msdn.microsoft.com/en-us/library/fs2xkftw.aspx without using a finalizer, which is enough if you have only managed resources. Best Regards, D. Rob On Jan 23, 2012, at 4:22 PM, Konrad M. Kruczyński wrote: Thanks for the answer. Here is the case: Let's say I have a class which contains some data in temporary file (for example some kind of cache which should not stay in memory). I'd like to have this file removed when object of this class dies. I can implement a finalizer but if I do this, object will be reclaimed later than it should, also putting additional pressure on GC. Problems of objects with finalizers which are not manually invoked are generally known. And this is scenario where such object can be shared and does not fit into any kind of using block. I think that mentioned API can resolve that kind of problems, because I can set up a callback which deletes temporary file *after* object's death. Therefore it is processed like any other object, without being in special collection for disposable objects. I think it would bring significant performance gain, especially if objects are created often and we expect they die soon. It should be measured, but for that I need some kind of API. What do you think? We've thought about exporting such interface, but the maintenance burden made us back off. This interface has some short-coming and exposing it to managed code has it's problems. For example, it doesn't support unregistering. But, if you make your case on why such a feature would help you, I can look into it. -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
Hi all, I think I was misunderstood. This is not beginner's question on how to write classes with Disposable pattern (you mentioned) -- believe me, I know that very well. Problem is rather as follows. Let's say we have an object whose life is short - it is collected on first GC scan after creation. But then if it has a finalizer it is not collected. Instead, it is marked for finalization. After some time its finalizer is called. And it is finally collected after next GC scan - so much more later than in the first case. Things will get worse if it will be promoted to next generation in the meantime. In other words such kind of object with finalizer will stay in memory longer than it should and that is the source of performance problems I mentioned. It can also hold reference to another (fully managed) objects, that one to another and so on. This is well known problem with objects implementing finalizers and one of the reasons (among unpredictability) for recommending explicit (via Dispose) release. But how can one do that if object is shared (the thing you would, for instance in C++, do with reference counting)? Finalizers are best as back-ups for such release, not the main mean, as you have written. I think that callback after death mechanism is the solution here. About the I/O operation invoked - I would not put it in the callback directly, rather enqueue it in thread pool. Oh, I've just found an article which talks about what I exactly meant: http://www.bluebytesoftware.com/blog/2011/11/12/ABriefNoteOnObjectMortality.aspx Apparently this is possible in Java. It could be therefore useful also for IKVM, as it has to be provided by it. I do not know how it is implemented in it currently - probably using small objects with finalizers on which they make proper notifications. I hope it is clearer now. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
On Mon, 2012-01-23 at 23:35 -0200, Rodrigo Kumpera wrote: There is no specially collector for finalizable objects. The finalizer will be called around the same time the callback for such an object would be. I meant the sgen equivalent of the f-reachable queue. Callback will be called around the same time, I agree, but the object itself (with the one it points) can stay in memory longer. Even if performance was backed in, it would not help a lot since you have the large bottleneck of file backed. As I said, I would rather not delete file directly on the callback's thread, but queue its deletion. Also the mentioned approach can be useful for other kinds of resources. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Reference queue
Hi, I've just noticed that runtime offers mono_gc_reference_queue_new function, which can be used to register callback executed after object is collected. Is there a possibility of exporting this functionality to class library to have it available from C# code? (Mono.Runtime or sth like that). Btw, I would also like to bump on my thread Stopwatch's frequency at which no one responded. -- Regards, Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
We've thought about exporting such interface, but the maintenance burden made us back off. This interface has some short-coming and exposing it to managed code has it's problems. For example, it doesn't support unregistering. But, if you make your case on why such a feature would help you, I can look into it. 2012/1/23 Konrad M. Kruczyński konrad.kruczyn...@gmail.com Hi, I've just noticed that runtime offers mono_gc_reference_queue_new function, which can be used to register callback executed after object is collected. Is there a possibility of exporting this functionality to class library to have it available from C# code? (Mono.Runtime or sth like that). Btw, I would also like to bump on my thread Stopwatch's frequency at which no one responded. -- Regards, Konrad __**_ Mono-devel-list mailing list Mono-devel-list@lists.ximian.**com Mono-devel-list@lists.ximian.com http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
Thanks for the answer. Here is the case: Let's say I have a class which contains some data in temporary file (for example some kind of cache which should not stay in memory). I'd like to have this file removed when object of this class dies. I can implement a finalizer but if I do this, object will be reclaimed later than it should, also putting additional pressure on GC. Problems of objects with finalizers which are not manually invoked are generally known. And this is scenario where such object can be shared and does not fit into any kind of using block. I think that mentioned API can resolve that kind of problems, because I can set up a callback which deletes temporary file *after* object's death. Therefore it is processed like any other object, without being in special collection for disposable objects. I think it would bring significant performance gain, especially if objects are created often and we expect they die soon. It should be measured, but for that I need some kind of API. What do you think? We've thought about exporting such interface, but the maintenance burden made us back off. This interface has some short-coming and exposing it to managed code has it's problems. For example, it doesn't support unregistering. But, if you make your case on why such a feature would help you, I can look into it. -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Reference queue
If it is the case that you have unmanaged resources that you need to clean up that you should really be using the IDisposable interface and calling Dispose() on the class when you are done with it. If it is possible for code paths to 'forget' to call Dispose() then you can include a finalizer as well, if you do this you need to make sure that when Dispose() is explicitly called you call GC.SuppressFinalize() on that object so the finalizer can be skipped Rob On Jan 23, 2012, at 4:22 PM, Konrad M. Kruczyński wrote: Thanks for the answer. Here is the case: Let's say I have a class which contains some data in temporary file (for example some kind of cache which should not stay in memory). I'd like to have this file removed when object of this class dies. I can implement a finalizer but if I do this, object will be reclaimed later than it should, also putting additional pressure on GC. Problems of objects with finalizers which are not manually invoked are generally known. And this is scenario where such object can be shared and does not fit into any kind of using block. I think that mentioned API can resolve that kind of problems, because I can set up a callback which deletes temporary file *after* object's death. Therefore it is processed like any other object, without being in special collection for disposable objects. I think it would bring significant performance gain, especially if objects are created often and we expect they die soon. It should be measured, but for that I need some kind of API. What do you think? We've thought about exporting such interface, but the maintenance burden made us back off. This interface has some short-coming and exposing it to managed code has it's problems. For example, it doesn't support unregistering. But, if you make your case on why such a feature would help you, I can look into it. -- Konrad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
