Re: Support for GC.AddMemoryPressure()
glopes <[email protected]> Thu, 7 Jun 2012 23:07:23 -0700 (PDT)
| Newsgroups | gmane.comp.gnome.mono.garbage-collection |
|---|---|
| Message-ID | <CAGV1SGKOP1oE+WwkbtRm9dop4dL7mqVGAiivvNmn+twqfiHfmg@mail.gmail.com> |
--===============1277042228== Content-Type: multipart/alternative; boundary="----=_Part_27833_13709609.1339135643864" ------=_Part_27833_13709609.1339135643864 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the feedback David, that's exactly the way how I always thought about it :-) Also, I have more observations pertaining to the semantics of AddMemoryPressure. Rodrigo mentioned the API was obscure and it wasn't clear how exactly it operates. Well, from the name itself and from having used it a lot in the past, I think I can offer a couple of guesses. While operating, a GC has basically to make two decisions: when to collect and what to collect. I think it's clear to assume AddMemoryPressure only concerns itself with the former, since it's a static method that receives no information whatsoever about any object. The decision of when to collect must be closely tied to the amount of memory allocated by the managed process at a given moment in time, so it's natural to assume there's some fast way in the GC to measure how much memory is currently in use and that variable is used in the decision process. Since AddMemoryPressure receives as input a number of bytes, I always imagined it was simply directly adding up to this variable, perhaps in some thread-safe way, but thereby making the pressure automatically meaningful to the GC decision process. The only point which for me could raise ambiguity is actually the converse of the method: RemoveMemoryPressure. Since memory pressure is only applied externally to the GC, adding it always represents, at the user's discretion, a meaningful semantics. However, my question relates to what would happen if the user calls RemoveMemoryPressure when all memory pressure has already been removed. Can you actually start delaying collection? I would expect not, although I never tried it. My guess would be the memory pressure is kept in a separate variable which is always lower-bounded at 0 to avoid this kind of mischief. However, a couple of nice unit tests could probably determine this easily... Is there anything else problematic with the memory pressure methods you guys are aware of that contradicts this interpretation? Thanks, G On 7 June 2012 17:05, jeske [via Mono] < [email protected]> wrote: > > On Jun 5, 2012 7:16 AM, "Rodrigo Kumpera" <[hidden email]<http://user/SendEmail.jtp?type=node&node=4649773&i=0>> > wrote: > > This is a classic example of what the memory pressure API is not for. > You're simply not disposing your native resources and the GC has > > no business in doing it for you. For forcing it to do for you, you're > trading higher latencies for a mild convenience. > > I either don't understand or don't agree with this. Glopes' use case seems > to me to be exactly the problem memory pressure was designed to solve. > > The purpose of the memory pressure api is to tell the gc about the real > memory consumption of managed objects, so references to unmanaged memory > don't 'break' the geneational colletors behavior. You can read about the > problems of not having this on some of the java apache projects, such as > cassandra and hbase. > > There is nothing 'broken' about expecting the gc to handle object > lifetime. Without this we are degenerated to c-like manual refcounting or > other fixed lifetime strategies, and should seriously consider authoring in > c++ instead. > > Memory pressure simply offers a mechanism for managed objects referencing > native data to operate similarly to managed objects holding large managed > arrays. > > _______________________________________________ > Mono-gc-list maillist - [hidden email]<http://user/SendEmail.jtp?type=node&node=4649773&i=1> > http://lists.ximian.com/mailman/listinfo/mono-gc-list > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemoryPressure-tp4649713p4649773.html > To unsubscribe from Support for GC.AddMemoryPressure(), click here<http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4649713&code=Z29uY2Fsb2Nsb3Blc0BnbWFpbC5jb218NDY0OTcxM3w1Nzg4Mzk1OTY=> > . > NAML<http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemoryPressure-tp4649713p4649780.html Sent from the Mono - Garbage Collection mailing list archive at Nabble.com. ------=_Part_27833_13709609.1339135643864 Content-Type: text/html; charset=UTF8 Content-Transfer-Encoding: quoted-printable Thanks for the feedback David, that's exactly the way how I always thou= ght about it :-)<div><br></div><div>Also, I have more observations pertaini= ng to the semantics of AddMemoryPressure. Rodrigo mentioned the API was obs= cure and it wasn't clear how exactly it operates. Well, from the name i= tself and from having used it a lot in the past, I think I can offer a coup= le of guesses.</div> <div><br></div><div>While operating, a GC has basically to make two decisio= ns: when to collect and what to collect. I think it's clear to assume A= ddMemoryPressure only concerns itself with the former, since it's a sta= tic method that receives no information whatsoever about any object. The de= cision of when to collect must be closely tied to the amount of memory allo= cated by the managed process at a given moment in time, so it's natural= to assume there's some fast way in the GC to measure how much memory i= s currently in use and that variable is used in the decision process. Since= AddMemoryPressure receives as input a number of bytes, I always imagined i= t was simply directly adding up to this variable, perhaps in some thread-sa= fe way, but thereby making the pressure automatically meaningful to the GC = decision process.</div> <div><br></div><div>The only point which for me could raise ambiguity is ac= tually the converse of the method: RemoveMemoryPressure. Since memory press= ure is only applied externally to the GC, adding it always represents, at t= he user's discretion, a meaningful semantics. However, my question rela= tes to what would happen if the user calls RemoveMemoryPressure when all me= mory pressure has already been removed. Can you actually start delaying col= lection? I would expect not, although I never tried it. My guess would be t= he memory pressure is kept in a separate variable which is always lower-bou= nded at 0 to avoid this kind of mischief. However, a couple of nice unit te= sts could probably determine this easily...</div> <div><br></div><div>Is there anything else problematic with the memory pres= sure methods you guys are aware of that contradicts this interpretation?</d= iv><div>Thanks,</div><div>G<br><br><div class=3D"gmail_quote">On 7 June 201= 2 17:05, jeske [via Mono] <span dir=3D"ltr"><<a href=3D"/user/SendEmail.= jtp?type=3Dnode&node=3D4649780&i=3D0" target=3D"_top" rel=3D"nofollow" link= =3D"external">[hidden email]</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"><div class=3D"im"> =09<p><br> On Jun 5, 2012 7:16 AM, "Rodrigo Kumpera" <<a href=3D"http://u= ser/SendEmail.jtp?type=3Dnode&node=3D4649773&i=3D0" rel=3D"nofollow= " link=3D"external" target=3D"_blank">[hidden email]</a>> wrote:<br> > This is a classic example of what the memory pressure API is not for. = You're simply not disposing your native resources and the GC has<br> > no business in doing it for you. For forcing it to do for you, you'= ;re trading higher latencies for a mild convenience.</p> </div><p>I either don't understand or don't agree with this. Glopes= ' use case seems to me to be exactly the problem memory pressure was de= signed to solve.</p><div class=3D"im"> <p>The purpose of the memory pressure api is to tell the gc about the real = memory consumption of managed objects, so references to unmanaged memory do= n't 'break' the geneational colletors behavior. You can read ab= out the problems of not having this on some of the java apache projects, su= ch as cassandra and hbase. </p> <p>There is nothing 'broken' about expecting the gc to handle objec= t lifetime. Without this we are degenerated to c-like manual refcounting or= other fixed lifetime strategies, and should seriously consider authoring i= n c++ instead. </p> <p>Memory pressure simply offers a mechanism for managed objects referencin= g native data to operate similarly to managed objects holding large managed= arrays.</p> <br></div><div class=3D"im">_______________________________________________ <br>Mono-gc-list maillist =C2=A0- =C2=A0<a href=3D"http://user/SendEmail.jt= p?type=3Dnode&node=3D4649773&i=3D1" rel=3D"nofollow" link=3D"extern= al" target=3D"_blank">[hidden email]</a> <br><a href=3D"http://lists.ximian.com/mailman/listinfo/mono-gc-list" rel= =3D"nofollow" link=3D"external" target=3D"_blank">http://lists.ximian.com/m= ailman/listinfo/mono-gc-list</a><br> =09 =09<br> =09<br> =09<hr noshade size=3D"1" color=3D"#cccccc"> =09</div><div style=3D"color:#444;font:12px tahoma,geneva,helvetica,arial,s= ans-serif"><div class=3D"im"> =09=09<div style=3D"font-weight:bold">If you reply to this email, your mess= age will be added to the discussion below:</div> =09=09</div><a href=3D"http://mono.1490590.n4.nabble.com/Support-for-GC-Add= MemoryPressure-tp4649713p4649773.html" target=3D"_blank" rel=3D"nofollow" l= ink=3D"external">http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemory= Pressure-tp4649713p4649773.html</a> =09</div><div class=3D"HOEnZb"><div class=3D"h5"> =09<div style=3D"color:#666;font:11px tahoma,geneva,helvetica,arial,sans-se= rif;margin-top:.4em;line-height:1.5em"> =09=09 =09=09To unsubscribe from Support for GC.AddMemoryPressure(), <a href=3D"" = target=3D"_blank" rel=3D"nofollow" link=3D"external">click here</a>.<br> =09=09<a href=3D"http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp= ?macro=3Dmacro_viewer&id=3Dinstant_html%21nabble%3Aemail.naml&base= =3Dnabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNam= espace-nabble.view.web.template.NodeNamespace&breadcrumbs=3Dnotify_subs= cribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_ins= tant_email%21nabble%3Aemail.naml" rel=3D"nofollow" style=3D"font:9px serif"= target=3D"_blank" link=3D"external">NAML</a> =09</div></div></div></blockquote></div><br></div> =09 <br/><hr align=3D"left" width=3D"300" /> View this message in context: <a href=3D"http://mono.1490590.n4.nabble.com/= Support-for-GC-AddMemoryPressure-tp4649713p4649780.html">Re: Support for GC= .AddMemoryPressure()</a><br/> Sent from the <a href=3D"http://mono.1490590.n4.nabble.com/Mono-Garbage-Col= lection-f1553555.html">Mono - Garbage Collection mailing list archive</a> a= t Nabble.com.<br/> ------=_Part_27833_13709609.1339135643864-- --===============1277042228== 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 --===============1277042228==--