[Mono-dev] runtime assisted object pools

[Rodrigo Kumpera]

Unless you use explicit memory management or some other trick, such scheme
is not any better than what both collectors already do.

Both use a size-segregated allocator for the major heap which works very
much like an object pool based on size.

Object pools work when allocating memory is very expensive. With an modern
GC, the major cost is not allocation, but tracing.


On Fri, Aug 31, 2012 at 8:18 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:

> I use object pools where I have control over the lifecycle of objects used
> with high frequency.    In the application I was discussing with respect to
> sgen, it is very hard to explicitly use object pools (nor can I use structs
> in this case).
>
> I think Miguel mentioned briefly in a blog, but would be interesting to
> have a non-MS compatible extension or special Mono namespace library /
> runtime support for automatic object pooling.    I have a number of
> applications that need to deal with billions of objects cycled through.
> Instead of bending over backwards to try to fit in an explicit ObjectPool
> model, would love to be able to designate a maximum fixed size pool that
> would be handled as a special case by the GC:
>
>
>    1. whenever new <someobject> () is invoked, the runtime will attempt
>    to pull from an existing object in pool
>       1. if the pool is full, a GC sweep is done to determine whether any
>       of the objects / slots in the pool are now garbage, perhaps compacting or
>       just marking.
>    2. when an object becomes garbage, nothing explicit happens, is only
>    marked & reused on the next new.
>
>
> I realize this is not part of the MS CLR spec, but is *very* useful for
> all sorts of high throughput services and processing.   It seems like a
> much simplified form of what sgen or beohm would be doing.
>
> Thoughts?
>
> Jonathan
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120831/ae5953c0/attachment.html>