Now that we understand the Recycler Object for Object Pool Pattern, we can build the logic for managing the object pool. An object pool is a simple API that manages recycling and fetching recyclable objects. There are two common models for object pools, one with a fixed number of objects that errors if too many objects are requested, and the other (more flexible approach) is to use the object pool for a fixed number of objects, but allow additional recyclable objects beyond that limit which won’t be recycled (never use an unbounded pool).

Both approaches solve a slightly different problem. For example, a table that always contains exactly 50 rows of replaceable data might use the more rigid object pool, while a framework returning recyclable event wrapper objects would need to be more flexible (20 events firing at once seems like a reasonable limit, but wouldn’t want to error if there were more).

We’ll implement the second approach, but discuss how it might be modified for the first approach.

With the object pool pattern, it is important not to recycle the same object twice. When double recycling is suspected, adding a recycled boolean to the recyclable object and adding a check to the recycle function of the pool can be helpful:

//...
this.recycle = function(oRecyclable) {
if (!oRecyclable instanceof this._fnConstructor) {
throw new Error("Trying to recycle the wrong object for pool.");
}
if (oRecyclable._bRecycled) {
throw new Error("The recyclable object was already recycled.");
}
// The same can be done without adding the _bRecycled boolean, but
// this is non-performance and should not be used in production.
for (var i = this._iSize; 0 <= i; i--) {
if (oRecyclable === this._aObjects[this._iSize]) {
throw new Error("The recyclable object was already recycled.");
}
}
if (this._iSize < this._iLimit) {
oRecyclable.recycle();
this._aObjects[this._iSize] = oRecyclable;
this._iSize++;
} else {
// The pool is full, object will be deferred to GC for cleanup.
}
};
//...

Lastly, when debugging, you may want to track the high water point of the recycle pool, to better assess what a reasonable limit is (start high, use the application for a while, then adjust down to the high water value):

How it works…

The recycle pool is a simple API for obtaining and recycling recyclable object instances. Underneath the hood it manages a pool of recycled object from which it first attempts to fetch an object instance, before instantiating new objects. As objects are recycled they are added to the pool until a maximum is reached; we let the GC handle any overflow objects. This pattern helps normalize the memory thrash of a process. Usually the limit used to instantiate the pool won’t be exceeded, so we have a good idea of the maximum memory expectation. But more importantly we don’t continually create and delete objects from the memory space. Instead we step up to the limit as more objects are added to the pool and stay there.

The biggest gotcha with this pattern is accidentally recycling an object more than once. Doing so can lead to bizarre results if the object is simultaneously modified. A production system can prevent this by monitoring the recycled state of the recyclable object, or a debug system can iterate through the objects in the pool and check for equality.

In this JavaScript implementation the recycle function uses an instanceof of check to make sure the correct recyclable object is being recycled. A statically typed language would prevent the need for this instance of by throwing a compile-time error. In JAVA, for example the ObjectPool class could be instantiated using Generics and that generic class would be required to be passed into the recycle method.

When implementing in another language, you may also need to consider threading issues. If multiple threads will be pulling from the object pool at the same time, then make sure you synchronize (or language equivalent) the obtain and recycle functions.

To build a fixed length object pool, just modify the obtain function to keep track of the number of objects it has instantiated and raise an exception if the number exceeds the limit. Then decide if it makes sense to pay the cost of instantiating the entire pool up front, or when they are first needed.

Creating or destroying an object is never free and JavaScript is no exception. Generally, the cost of creating/destroying an object in JIT-optimized JavaScript runtimes doesn't affect performance, but other languages will have a performance hit as well. The real culprit is the increase in your application's memory footprint (watch the memory tab in a developer tool while running the tests below for an illustration). This is why, in most cases, reusing a single object is ...

When a JavaScript object can be configured in a variety of ways, it is best-practice to include a configuration object in the constructor, where all configuration values are optional. This way, the developer can configure an object when it is instantiated, without having to provide parameters that are common to most instances of an object.

I have said this before and will probably say it again, "I love CustomEvent". This was one of the major reasons why I chose YUI as my preferred JavaScript framework. Using CustomEvent you are able to create a subscribable event for anything you might want an event for, and fire that event programmatically. I find this most useful when leveraging the Module Pattern, as I can keep the event management and all ...

Okay, I still havent finished my event package yet, but I do have short article about a variation on the module pattern. I learned this from the conference this Saturday and Douglas Crockfords talk. In my last article I showed the begetObject method; the technique today will user a similar structure.