[Mono-dev] runtime assisted object pools

[Jonathan Shore]

On Aug 31, 2012, at 7:39 PM, Rodrigo Kumpera wrote:

> 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.
> 

I guess I'm searching for some solution that is at least as good as boehm for my working set, but without the current memory size limitations.

I achieve much better performance when using object pools, of course because of the explicit object release, avoiding the cost of 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:
> 
> whenever new <someobject> () is invoked, the runtime will attempt to pull from an existing object in pool
> 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.
> 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/8c83806a/attachment.html>