[Mono-dev] runtime assisted object pools

[Nicholas Frechette]

Have you thought about using weak pointers? Those are already handled
as a special case by the GC.
In your pool, you keep weak references such that if a GC happens and
no real references exist on an object outside of weak references, the
object will be GCed and all weak references will be invalidated. In
the event that a real reference exists, nothing changes.

Then in your pool you can check for any invalidated entries and reuse
those, you could trigger a GC manually in hope of freeing some or you
could allocate new ones. As you see fit.

Implementing a cache isn't very hard and I believe some might already
exist in .net (using more or less what I just described).

In .net, weak references are called: System.WeakReference.

As discussed above, a cache like this mostly only makes sense if the
allocation cost is very large or if you want a maximum fixed amount of
objects allocated.

Cheers,
Nicholas

On Fri, Aug 31, 2012 at 7:45 PM, Jonathan Shore
<jonathan.shore at gmail.com> wrote:
>
> 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
>>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>