Re: Support for GC.AddMemoryPressure()

--===============0290869700==
Content-Type: multipart/alternative; boundary=20cf30050c30efb01204c1e40b4e

--20cf30050c30efb01204c1e40b4e
Content-Type: text/plain; charset=ISO-8859-1

On Jun 5, 2012 7:16 AM, "Rodrigo Kumpera" <[email protected]> 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.

--20cf30050c30efb01204c1e40b4e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p><br>
On Jun 5, 2012 7:16 AM, &quot;Rodrigo Kumpera&quot; &lt;<a href=3D"mailto:k=
[email protected]">[email protected]</a>&gt; wrote:<br>
&gt; This is a classic example of what the memory pressure API is not for. =
You&#39;re simply not disposing your native resources and the GC has<br>
&gt; no business in doing it for you. For forcing it to do for you, you&#39=
;re trading higher latencies for a mild convenience.</p>
<p>I either don&#39;t understand or don&#39;t agree with this. Glopes&#39; =
use case seems to me to be exactly the problem memory pressure was designed=
 to solve.</p>
<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&#39;t &#39;break&#39; 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 &#39;broken&#39; 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>

--20cf30050c30efb01204c1e40b4e--

--===============0290869700==
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

--===============0290869700==--