Fwd: Support for GC.AddMemoryPressure()

--===============1536349242==
Content-Type: multipart/alternative; boundary=e89a8fb1eaf897810504c1bb2fca

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

---------- Forwarded message ----------
From: Rodrigo Kumpera <[email protected]>
Date: Tue, Jun 5, 2012 at 12:19 PM
Subject: Re: [Mono-gc-list] Support for GC.AddMemoryPressure()
To: glopes <[email protected]>




On Tue, Jun 5, 2012 at 11:56 AM, glopes <[email protected]> wrote:

> I understand completely why people would think that, I honestly do, but I
> confess 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.
>
>  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, which
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 sorts
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 immutability 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 projection will end
> up being used, as this will screw modularity and composability.
>

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.

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

<br><br><div class=3D"gmail_quote">---------- Forwarded message ----------<=
br>From: <b class=3D"gmail_sendername">Rodrigo Kumpera</b> <span dir=3D"ltr=
">&lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;</span>=
<br>Date: Tue, Jun 5, 2012 at 12:19 PM<br>
Subject: Re: [Mono-gc-list] Support for GC.AddMemoryPressure()<br>To: glope=
s &lt;<a href=3D"mailto:[email protected]">[email protected]</a=
>&gt;<br><br><br><br><br><div class=3D"gmail_quote"><div class=3D"im">On Tu=
e, Jun 5, 2012 at 11:56 AM, glopes <span dir=3D"ltr">&lt;<a href=3D"mailto:=
[email protected]" target=3D"_blank">[email protected]</a>&gt;<=
/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&#39;m at a loss why it should be a problem at a conceptual level, =
or why it MemoryPressure shouldn&#39;t be used this way.<div><br></div>

<div>
We&#39;re talking about highly transient native resources (e.g. images), wh=
ich are completely tied to a managed representation which I&#39;m using to =
compose modular high-throughput data processing pipelines. In the end it&#3=
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&#39;=
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 class=3D"im">
<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&#39;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&#39;m lost here. A garbage collect=
or has nothing do to with object=A0immutability. User code that doesn&#39;t=
 change such objects is.</div><div class=3D"im"><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">

<div>In a modular pipeline, there&#39;s no one who knows when it&#39;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&#39;re running i=
t through. It&#39;s the same with LINQ queries, when you handle transient i=
ntermediate projections during complex queries, you don&#39;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>
</div><br>

--e89a8fb1eaf897810504c1bb2fca--

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

--===============1536349242==--