tag:blogger.com,1999:blog-29153919.post4341506086433169654..comments2024-03-27T17:08:01.671+00:00Comments on MonoTorrent: Alanhttp://www.blogger.com/profile/17518005985877464643noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-29153919.post-403391128653108362006-11-28T21:42:00.000+00:002006-11-28T21:42:00.000+00:00Well, i've been giving this a lot of thought and i...Well, i've been giving this a lot of thought and i've come to realise that what i really want is a real-time garbage collector. One that collects as soon as all references to an object are dropped.<br /><br />Of course, i have no idea of the logistics involved in that, so i wont even pretend to know how hard it'd be to do right. Still, it would be nice... :pAlanhttps://www.blogger.com/profile/17518005985877464643noreply@blogger.comtag:blogger.com,1999:blog-29153919.post-64575537819547105862006-11-28T00:37:00.000+00:002006-11-28T00:37:00.000+00:00There is another optimization where potentially lo...There is another optimization where potentially long lived objects are promoted straight into the mature part of the heap (generations 2 and 3 in the MS collector). This is called pretenuring; check out <a href="http://www.cc.gatech.edu/classes/AY2002/cs8803f_fall/pretenure.pdf">Pretenuring for Java</a>.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-29153919.post-59618759533958206942006-11-27T04:41:00.000+00:002006-11-27T04:41:00.000+00:00When doing something similar on the .NET platform ...When doing something similar on the .NET platform with BeginReceive & other sundry long-running IO routines that take byte buffers, I allocate slices of buffers out of manually managed heaps, where the byte buffers are large enough to force allocation from the LOH (large object heap, anything >80000 bytes in .NET).<br /><br />That way, there's no GC needed since GC allocations aren't being made.Barry Kellyhttps://www.blogger.com/profile/10559947643606684495noreply@blogger.comtag:blogger.com,1999:blog-29153919.post-47552046616001224432006-11-27T01:28:00.000+00:002006-11-27T01:28:00.000+00:00You don't know if MyObject (now or at some point i...You don't know if MyObject (now or at some point in the future is modified to) save a reference to it self in some class variable or give a reference of itself away. Think singleton pattern, object cache or pool. Therefor you probably need to go to a full GC algorithm to check if the object is truly free and short lived.<br /><br />I think your observation is addressed by the new GC that is being developed. It is (among other things) a Generational Collector and treat short lived objects differently than long lived objects (defined as objects that have survived a single collection). Here the assumption is that objects are either very short lived or they are quite long lived and most objects are very short lived. Therefore, if an object isn't very short lived, there is no need to try to GC it as often. http://www.mono-project.com/Compacting_GCUnknownhttps://www.blogger.com/profile/16298898435309335743noreply@blogger.comtag:blogger.com,1999:blog-29153919.post-34083863026841280642006-11-26T23:43:00.000+00:002006-11-26T23:43:00.000+00:00Well I guess you know the saying: Never try to out...Well I guess you know the saying: Never try to outsmart the GC ;)<br />I doubt that you would get a lot from it. A more simple method for improvement would be making some of the classes structs (for some it should be possible without much hassle). Structs don't put pressure on the GC...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-29153919.post-9753574158588489212006-11-26T22:56:00.000+00:002006-11-26T22:56:00.000+00:00Well, that's why you need an algorithm to test wha...Well, that's why you need an algorithm to test what objects can actually be fast collected. If DoACalculation passed a reference outside the scope of the method, then that object would definately *not* be fast collectable.<br /><br />However if the object were defined like this:<br /><br />public MyObject()<br />{<br /> private int number;<br /><br /> public MyObject(int number)<br /> {<br /> this.number = number;<br /> }<br /><br /> public int DoACalculation()<br /> {<br /> return this.number*this.number;<br /> }<br />}<br /><br />then this object would definitely be fast collectable.<br /><br /><br />Another scenario: Assume MethodA creates the object above and passes it to MethodB which performs the calculation there. This object would still be fast collectable at the end of MethodA (assuming that MethodB doesn't pass the object completely out of its scope).Alanhttps://www.blogger.com/profile/17518005985877464643noreply@blogger.comtag:blogger.com,1999:blog-29153919.post-29024508747879104772006-11-26T22:19:00.000+00:002006-11-26T22:19:00.000+00:00Mmmmm, wait a moment:
public void Example()
{
MyO...Mmmmm, wait a moment:<br /><br />public void Example()<br />{<br />MyObject a = new MyObject(15);<br />a.DoACalculation();<br />Console.WriteLine(a.ResultFromCalculation);<br />return;<br />}<br /><br />What happens if DoACalculation function creates a new thread that launches and passes it the reference to the a variable? Then we would be in the case where reaching the return statement, the a object should not be collected.<br /><br />Is it really possible to fast-collect an object?Anonymousnoreply@blogger.com