[Mono-dev] runtime assisted object pools

[Jonathan Shore]

When I am able to use an object pool I don't really rely on the GC and
don't really need weak references either.   In one real-time application, I
cycle through ~ 9 billion objects over the course of a few hours.   The
working set in this scenario is small.

In the application I was testing with sgen, it is a batch oriented process,
not real-time.  Hence I rely on the GC in that case.    For latency
sensitive work am largely using object pools for the objects used at high
frequency and some structs where appropriate.

On Mon, Sep 3, 2012 at 8:18 AM, Nicholas Frechette <zeno490 at gmail.com>wrote:

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



-- 
Jonathan Shore
http://tr8dr.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120903/546e767f/attachment.html>