[prev in list] [next in list] [prev in thread] [next in thread]
List: mono-gc-list
Subject: [Mono-gc-list] Fwd: Support for GC.AddMemoryPressure()
From: Rodrigo Kumpera <kumpera () gmail ! com>
Date: 2012-06-05 15:20:08
Message-ID: CACmR+BBbEXvSMSvo6MOMA-vCT08n6SOaMomrfX2MxmyrG8KHzw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
---------- Forwarded message ----------
From: Rodrigo Kumpera <kumpera@gmail.com>
Date: Tue, Jun 5, 2012 at 12:19 PM
Subject: Re: [Mono-gc-list] Support for GC.AddMemoryPressure()
To: glopes <goncaloclopes@gmail.com>
On Tue, Jun 5, 2012 at 11:56 AM, glopes <goncaloclopes@gmail.com> 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.
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b \
class="gmail_sendername">Rodrigo Kumpera</b> <span dir="ltr"><<a \
href="mailto:kumpera@gmail.com">kumpera@gmail.com</a>></span><br>Date: Tue, Jun 5, \
2012 at 12:19 PM<br>
Subject: Re: [Mono-gc-list] Support for GC.AddMemoryPressure()<br>To: glopes <<a \
href="mailto:goncaloclopes@gmail.com">goncaloclopes@gmail.com</a>><br><br><br><br><br><div \
class="gmail_quote"><div class="im">On Tue, Jun 5, 2012 at 11:56 AM, glopes <span \
dir="ltr"><<a href="mailto:goncaloclopes@gmail.com" \
target="_blank">goncaloclopes@gmail.com</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> 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.<div><br></div>
<div>
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.</div>
</blockquote><div><br></div></div><div>This is precisely the problem. The GC deals \
with managed resources only and the MemoryPressure API completely unties one from the \
other.</div><div>So, when should a collection based on the current managed and \
unmanaged pressure? Will a minor collection be enough to alleviate the 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 AddMemoryPressure can \
increase collection frequency significantly, which</div><div>
does reduce throughput.</div><div><br></div><div>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</div><div>of managed langages and having user code do \
its job always results in a better solution.</div> <div class="im">
<div><br></div><blockquote class="gmail_quote" style="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 garbage \
collection is what allows the immutability of objects to be preserved across \
calls.</div>
</blockquote><div><br></div></div><div>I'm lost here. A garbage collector has \
nothing do to with object immutability. User code that doesn't change such \
objects is.</div><div class="im"><div><br></div><blockquote class="gmail_quote" \
style="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 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.</div>
</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 will compose as well \
as everything else. This works just fine with iterators, for example.</div>
<div> </div></div>
</div><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