[prev in list] [next in list] [prev in thread] [next in thread]
List: mono-gc-list
Subject: Re: [Mono-gc-list] Support for GC.AddMemoryPressure()
From: glopes <goncaloclopes () gmail ! com>
Date: 2012-06-08 6:07:23
Message-ID: CAGV1SGKOP1oE+WwkbtRm9dop4dL7mqVGAiivvNmn+twqfiHfmg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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] <
ml-node+s1490590n4649773h73@n4.nabble.com> 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&i \
> d=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabb \
> le.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcru \
> mbs=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.
[Attachment #5 (text/html)]
Thanks for the feedback David, that's exactly the way how I always thought about \
it :-)<div><br></div><div>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.</div> <div><br></div><div>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.</div> <div><br></div><div>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...</div> \
<div><br></div><div>Is there anything else problematic with the memory pressure \
methods you guys are aware of that contradicts this \
interpretation?</div><div>Thanks,</div><div>G<br><br><div class="gmail_quote">On 7 \
June 2012 17:05, jeske [via Mono] <span dir="ltr"><<a \
href="/user/SendEmail.jtp?type=node&node=4649780&i=0" target="_top" rel="nofollow" \
link="external">[hidden email]</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">
<p><br>
On Jun 5, 2012 7:16 AM, "Rodrigo Kumpera" <<a \
href="http://user/SendEmail.jtp?type=node&node=4649773&i=0" rel="nofollow" \
link="external" target="_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 \
designed to solve.</p><div class="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 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. </p>
<p>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. </p>
<p>Memory pressure simply offers a mechanism for managed objects referencing native \
data to operate similarly to managed objects holding large managed arrays.</p> \
<br></div><div class="im">_______________________________________________ \
<br>Mono-gc-list maillist - <a \
href="http://user/SendEmail.jtp?type=node&node=4649773&i=1" rel="nofollow" \
link="external" target="_blank">[hidden email]</a> <br><a \
href="http://lists.ximian.com/mailman/listinfo/mono-gc-list" rel="nofollow" \
link="external" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-gc-list</a><br>
<br>
<br>
<hr noshade size="1" color="#cccccc">
</div><div style="color:#444;font:12px \
tahoma,geneva,helvetica,arial,sans-serif"><div class="im"> <div \
style="font-weight:bold">If you reply to this email, your message will be added to \
the discussion below:</div> </div><a \
href="http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemoryPressure-tp4649713p4649773.html" \
target="_blank" rel="nofollow" \
link="external">http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemoryPressure-tp4649713p4649773.html</a>
</div><div class="HOEnZb"><div class="h5">
<div style="color:#666;font:11px \
tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em">
To unsubscribe from Support for GC.AddMemoryPressure(), <a href="" target="_blank" \
rel="nofollow" link="external">click here</a>.<br>
<a href="http://mono.1490590.n4.nabble.com/template/NamlServlet.jtp?macro=macro_view \
er&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicName \
space-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace& \
amp;breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" \
rel="nofollow" style="font:9px serif" target="_blank" link="external">NAML</a> \
</div></div></div></blockquote></div><br></div>
<br/><hr align="left" width="300" />
View this message in context: <a \
href="http://mono.1490590.n4.nabble.com/Support-for-GC-AddMemoryPressure-tp4649713p4649780.html">Re: \
Support for GC.AddMemoryPressure()</a><br/> Sent from the <a \
href="http://mono.1490590.n4.nabble.com/Mono-Garbage-Collection-f1553555.html">Mono - \
Garbage Collection mailing list archive</a> at Nabble.com.<br/>
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-gc-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic