Re: Support for GC.AddMemoryPressure()
Gonçalo Lopes <[email protected]> Wed, 6 Jun 2012 19:14:56 +0100
| Newsgroups | gmane.comp.gnome.mono.garbage-collection |
|---|---|
| Message-ID | <CAGV1SGKDfkJqHOXTc-Ok54hRezJ2-S+QqErDazwtAfeKobw+UQ@mail.gmail.com> |
--===============0449402208== Content-Type: multipart/alternative; boundary=e89a8fb2007c941eff04c1d1be91 --e89a8fb2007c941eff04c1d1be91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again, Actually, I was searching more about it and I really cannot find by googling or elsewhere (i.e. scrounging MSDN documentations) and I couldn't find an example of what would be a "proper" use of memory pressure apart from the one I described. The MSDN docs even mention " In the simplest usage pattern, a managed object allocates unmanaged memory in the constructor and releases it in the Dispose or Finalize method." Could you maybe give me a practical example of what you would find a good and valid use of memory pressure so I can have a better idea of what you have in mind? Thanks again, G P.S.: I just realized that by accident I was replying directly to a personal e-mail account rather than to the mailing list, so please consider the attached mailing history as well. On 5 June 2012 18:06, Gon=E7alo Lopes <[email protected]> wrote: > Sorry, just noticed an important typo.... where it reads " Conceptually, > they are every bit as valid for a GC as a native object..." should be rea= d "Conceptually, > they are every bit as valid for a GC as a *managed* object...". > > G > > On 5 June 2012 18:03, Gon=E7alo Lopes <[email protected]> wrote: > >> First for all, thanks for your input, I always love to discuss these >> things. >> >> I agree with most of your points but there are added difficulties which >> make the problem harder. First of all, just to make it clear that my >> specific problem concerns the design of a general-purpose and modular >> asynchronous data processing framework, so I can't benefit from >> application-specific or even composition-specific solutions that would >> address this problem. Second of all, the asynchronous nature of the >> framework makes it much harder to design a contract that would work >> seamlessly across all data types of the framework without making everyth= ing >> too cumbersome for the user. Simplicity and rapid prototyping are one of >> its main goals and tenets, and that's every bit as important for my >> scenario as performance. >> >> Sorry for not being clear about immutability, and I grant you your point >> about that property having nothing to do with a GC. However, there is >> indeed a reason why functional languages do require a GC for being of an= y >> use. I just have not seen any single example of a functional programming >> language that does not heavily use collection, even when operating very >> close to C++ like D. The reason is that if you want to allow for >> composition in the functionally elegant style you simply must let go of >> handling the transients. I would say that's one of the main points for >> these languages actually. >> >> That said, I am in fact concerned with performance, but my statements >> before were in the direction of claiming that the pressured GC can indee= d >> be performant under most of the scenarios in which the framework is and = has >> been used. Again, we're talking about transient intermediate objects, >> meaning objects that will most likely not survive a gen 0 collection. Th= is >> effectively means the pressured GC's decision to collect is more likely >> than not always correct and will target the right objects, by virtue of >> they being short-lived. >> >> Also, the argument for whether native resource management should be >> transparent or not, in my scenario the arguments for this are exactly th= e >> same as for why it's useful to have a GC in the first place. It is possi= ble >> to compose applications in C/C++ and other languages where you have to >> explicitly handle all the memory, but again, there is a reason why peopl= e >> tried to move beyond this, even under exactly performance-related >> criticism. My resources are not TCP connections, file handles or >> structures with other complex side-effects. Conceptually, they are every >> bit as valid for a GC as a native object, with the exception they do not >> live in the managed heap. Granted, this fact alone bears a whole host of >> potential implications, but following the tenet of "premature optimizati= on >> is the root of all evil" I have yet to see any performance related issue= s >> related specifically to this point after 5-years of heavily using this >> approach in .NET windows machines for everything from multi-sensory >> acquisition, computer graphics and computation-intensive processing. Agr= ee >> that that doesn't mean the problem is not there, just that it never show= ed >> up in the many difficult use cases we put it through. >> >> Finally, I have in fact considered many times in the past moving away >> from the current functional-oriented paradigm to a more explicit memory >> model where the user has to provide specific nodes for processing the >> images. However, this would make image processing such a deviant special >> case in the framework, and would make everything so much harder for the >> user, that I just couldn't bring myself to do it until I really see a ne= ed >> for it. But I'm still very much thinking of how it could be done and I'm >> sure it definitely can be done, just not in a form that I'm currently ha= ppy >> with. The one thing I'm fairly confident is that whatever the solution i= s >> it should not transpire back to the composer layer. At most, it will imp= ly >> a custom memory pool for image allocation and deallocation which will ha= ve >> its own GC-like strategy... >> >> All the best and thanks again for all the feedback, really appreciate it >> :-) >> G >> >> >> On 5 June 2012 16:19, Rodrigo Kumpera <[email protected]> wrote: >> >>> >>> >>> On Tue, Jun 5, 2012 at 11:56 AM, glopes <[email protected]> wrote= : >>> >>>> I understand completely why people would think that, I honestly do, bu= t >>>> I confess I'm at a loss why it should be a problem at a conceptual lev= el, >>>> or why it MemoryPressure shouldn't be used this way. >>>> >>>> We're talking about highly transient native resources (e.g. images), >>>> which are completely tied to a managed representation which I'm using = to >>>> compose modular high-throughput data processing pipelines. In the end = it's >>>> not as different from just allocating an array of bytes. >>>> >>> >>> This is precisely the problem. The GC deals with managed resources only >>> and the MemoryPressure API completely unties one from the other. >>> So, when should a collection based on the current managed and unmanaged >>> pressure? Will a minor collection be enough to alleviate the current >>> native one? Or should it perform a major GC? >>> >>> The only answer you can drawn from those design questions is that >>> AddMemoryPressure can increase collection frequency significantly, whic= h >>> does reduce throughput. >>> >>> Explicitly disposing is doable in almost all scenarios given one thinks >>> enough on the problem. I've seen this same story many times in all sort= s >>> of managed langages and having user code do its job always results in a >>> better solution. >>> >>> Also, from a functional perspective of composability, it's not just a >>>> mild convenience, as garbage collection is what allows the immutabilit= y of >>>> objects to be preserved across calls. >>>> >>> >>> I'm lost here. A garbage collector has nothing do to with >>> object immutability. User code that doesn't change such objects is. >>> >>> In a modular pipeline, there's no one who knows when it's safe to >>>> dispose an image, as it depends for how long this image will be thrown >>>> around, which in turn depends on the specific pipeline you're running = it >>>> through. It's the same with LINQ queries, when you handle transient >>>> intermediate projections during complex queries, you don't really want= to >>>> handle responsibility to anyone in particular as to how that projectio= n >>>> will end up being used, as this will screw modularity and composabilit= y. >>>> >>> >>> This grows from the wrong assumption that native resource management is >>> or should be transparent. If you extend resource management to be >>> part of the contract you expose, it will compose as well as everything >>> else. This works just fine with iterators, for example. >>> >>> >> >> > --e89a8fb2007c941eff04c1d1be91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi again,</div><div><br></div>Actually, I was searching more about it = and I really cannot find by googling or elsewhere (i.e. scrounging MSDN doc= umentations) and I couldn't find an example of what would be a "pr= oper" use of memory pressure apart from the one I described. The MSDN = docs even mention " <span style=3D"font-family:'Segoe UI',Verdana,Arial;font-size:13px;= text-align:left">In the simplest usage pattern, a managed object allocates = unmanaged memory in the constructor and releases it in the=A0</span><span s= tyle=3D"font-family:'Segoe UI',Verdana,Arial;font-size:13px;text-al= ign:left"><span class=3D"input" style=3D"font-weight:700">Dispose</span></s= pan><span style=3D"font-family:'Segoe UI',Verdana,Arial;font-size:1= 3px;text-align:left">=A0or=A0</span><span style=3D"font-family:'Segoe U= I',Verdana,Arial;font-size:13px;text-align:left"><span class=3D"input" = style=3D"font-weight:700">Finalize</span></span><span style=3D"font-family:= 'Segoe UI',Verdana,Arial;font-size:13px;text-align:left">=A0method.= "</span><div> <div style=3D"text-align:left"><font face=3D"Segoe UI, Verdana, Arial"><br>= </font></div>Could you maybe give me a practical example of what you would = find a good and valid use of memory pressure so I can have a better idea of= what you have in mind?</div> <div><br></div><div>Thanks again,</div><div>G</div><div><br></div><div>P.S.= : I just realized that by accident I was replying directly to a personal e-= mail account rather than to the mailing list, so please consider the attach= ed mailing history as well.</div> <div><br></div><div><br><div class=3D"gmail_quote">On 5 June 2012 18:06, Go= n=E7alo Lopes <span dir=3D"ltr"><<a href=3D"mailto:[email protected]= om" target=3D"_blank">[email protected]</a>></span> wrote:<br><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> Sorry, just noticed an important typo.... where it reads " <span>Conceptually, they are every bit as valid for a GC as a native object= ..." should be read "</span><span>Conceptually, they are every bi= t as valid for a GC as a <b>managed</b> object...".</span><span class= =3D"HOEnZb"><font color=3D"#888888"><div> <font color=3D"#222222" face=3D"arial, sans-serif"><br></font></div></font>= </span><div><span class=3D"HOEnZb"><font color=3D"#888888"><font color=3D"#= 222222" face=3D"arial, sans-serif">G<br></font></font></span><div><div clas= s=3D"h5"> <br><div class=3D"gmail_quote">On 5 June 2012 18:03, Gon=E7alo Lopes <span = dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">First for all, thanks for your input, I alwa= ys love to discuss these things.<div><br></div><div>I agree with most of yo= ur points but there are added difficulties which make the problem harder. F= irst of all, just to make it clear that my specific problem concerns the de= sign of a general-purpose and modular asynchronous data processing framewor= k, so I can't benefit from application-specific or even composition-spe= cific solutions that would address this problem. Second of all, the asynchr= onous nature of the framework makes it much harder to design a contract tha= t would work seamlessly across all data types of the framework without maki= ng everything too cumbersome for the user.=A0Simplicity and rapid prototypi= ng are one of its main goals and tenets, and that's every bit as import= ant for my scenario as performance.</div> <div><br></div><div>Sorry for not being clear about immutability, and I gra= nt you your point about that property having nothing to do with a GC. Howev= er, there is indeed a reason why functional languages do require a GC for b= eing of any use. I just have not seen any single example of a functional pr= ogramming language that does not heavily use collection, even when operatin= g very close to C++ like D. The reason is that if you want to allow for com= position in the functionally elegant style you simply must let go of handli= ng the transients. I would say that's one of the main points for these = languages actually.</div> <div><br></div><div>That said, I am in fact concerned with performance, but= my statements before were in the direction of claiming that the pressured = GC can indeed be performant under most of the scenarios in which the framew= ork is and has been used. Again, we're talking about transient intermed= iate objects, meaning objects that will most likely not survive a gen 0 col= lection. This effectively means the pressured GC's decision to collect = is more likely than not always correct and will target the right objects, b= y virtue of they being short-lived.</div> <div><br></div><div>Also, the argument for whether native resource manageme= nt should be transparent or not, in my scenario the arguments for this are = exactly the same as for why it's useful to have a GC in the first place= . It is possible to compose applications in C/C++ and other languages where= you have to explicitly handle all the memory, but again, there is a reason= why people tried to move beyond this, even under exactly performance-relat= ed criticism. =A0My resources are not TCP connections, file handles or stru= ctures with other complex side-effects. Conceptually, they are every bit as= valid for a GC as a native object, with the exception they do not live in = the managed heap. Granted, this fact alone bears a whole host of potential = implications, but following the tenet of "premature optimization is th= e root of all evil" I have yet to see any performance related issues r= elated specifically to this point after 5-years of heavily using this appro= ach in .NET windows machines for everything from multi-sensory acquisition,= computer graphics and computation-intensive processing. Agree that that do= esn't mean the problem is not there, just that it never showed up in th= e many difficult use cases we put it through.</div> <div><br></div><div>Finally, I have in fact considered many times in the pa= st moving away from the current functional-oriented paradigm to a more expl= icit memory model where the user has to provide specific nodes for processi= ng the images. However, this would make image processing such a deviant spe= cial case in the framework, and would make everything so much harder for th= e user, that I just couldn't bring myself to do it until I really see a= need for it. But I'm still very much thinking of how it could be done = and I'm sure it definitely can be done, just not in a form that I'm= currently happy with. The one thing I'm fairly confident is that whate= ver the solution is it should not transpire back to the composer layer. At = most, it will imply a custom memory pool for image allocation and deallocat= ion which will have its own GC-like strategy...</div> <div><br></div><div>All the best and thanks again for all the feedback, rea= lly appreciate it :-)</div><div><span><font color=3D"#888888">G</font></spa= n><div><div><br><br><div class=3D"gmail_quote">On 5 June 2012 16:19, Rodrig= o Kumpera <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><br><br><div class=3D"gmail_quote"><div>On T= ue, Jun 5, 2012 at 11:56 AM, glopes <span dir=3D"ltr"><<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>>= </span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I understand completely why people would think that, I honestly do, but I c= onfess I'm at a loss why it should be a problem at a conceptual level, = or why it MemoryPressure shouldn't be used this way.<div><br></div> <div> We're talking about highly transient native resources (e.g. images), wh= ich are completely tied to a managed representation which I'm using to = compose modular high-throughput data processing pipelines. In the end it= 9;s not as different from just allocating an array of bytes.</div> </blockquote><div><br></div></div><div>This is precisely the problem. The G= C deals with managed resources only and the MemoryPressure API completely u= nties one from the other.</div><div>So, when should a collection based on t= he current managed and unmanaged pressure? Will a minor collection be enoug= h to=A0alleviate=A0the current</div> <div>native one? Or should it perform a major GC?</div><div><br></div><div>= The only answer you can drawn from those design questions is that AddMemory= Pressure can increase collection frequency significantly, which</div><div> does reduce throughput.</div><div><br></div><div>Explicitly disposing is do= able in almost all scenarios given one thinks enough on the problem. I'= ve seen this same story many times in all sorts</div><div>of managed langag= es and having user code do its job always results in a better solution.</di= v> <div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div>Also, from a functional = perspective of composability, it's not just a mild convenience, as garb= age collection is what allows the immutability of objects to be preserved a= cross calls.</div> </blockquote><div><br></div></div><div>I'm lost here. A garbage collect= or has nothing do to with object=A0immutability. User code that doesn't= change such objects is.</div><div><div><br></div><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex"> <div>In a modular pipeline, there's no one who knows when it's safe= to dispose an image, as it depends for how long this image will be thrown = around, which in turn depends on the specific pipeline you're running i= t through. It's the same with LINQ queries, when you handle transient i= ntermediate projections during complex queries, you don't really want t= o handle responsibility to anyone in particular as to how that projection w= ill end up being used, as this will screw modularity and composability.</di= v> </blockquote><div><br></div></div><div>This grows from the wrong assumption= that native resource management is or should be transparent. If you extend= resource management to be</div><div>part of the contract you expose, it wi= ll compose as well as everything else. This works just fine with iterators,= for example.</div> <div>=A0</div></div> </blockquote></div><br></div></div></div> </blockquote></div><br></div></div></div> </blockquote></div><br></div> --e89a8fb2007c941eff04c1d1be91-- --===============0449402208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mono-gc-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-gc-list --===============0449402208==--