Feedback: lime.utils.ObjectPool<T>

Hey guys,

Yesterday I struck out to create a simple API for creating an ObjectPool. There aren’t good examples that I can find of popular APIs people use already, so I would really appreciate help and feedback to discover how you guys would want to have an ObjectPool work.

In Flixel, an FlxGroup can add() and remove() objects, and getFirstAvailable() for objects that are added, but unused.

I like the idea of being able to easily add and remove objects, but I fear this doesn’t work well if someone wants to have the ObjectPool allocate for them, or have a set size.

I currently have this API, but again, feedback is welcome

var pool = new ObjectPool<Sprite> (function () return new Sprite (), 20);
trace (pool.size); // 20
var sprite1 = pool.get ();
var sprite2 = pool.get ();
pool.release (sprite1);
var sprite3 = pool.create ();

The size argument is optional. An ObjectPool with no size will allow growth. The get() method will return null if the size number of objects is already used. create() will always return an object, even if it exceeds the number of objects for the pool.

One downside is that when you get() an object, it’s flagged for use and counts toward the size. If you lose your reference to the object, it remains in the pool forever.

If we were to not use a size, we could have get() return an object, and the pool could not retain a reference. If you get() and forget to release(), at least it would be garbage collected, though you might miss that you are causing extra GC activity this way.

Please help me know if you think we should change this (before it is released in Lime), if both create() and get() is good, name preferences, etc, etc

Thank you :grinning:

2 Likes

Can the object pool be made out of any kinds of objects, like some .swf files for instance ?
Asking this because have been getting some problems with hitting ram size issues with some not so big .swf files that bloat up in memory, crashing flash.

Yep, it should work for (conceivably) any type of object, so long as you can return the object to the pool and don’t have to rely on garbage collection

1 Like

It’s about animations played repeatedly at certain points of a match so I wouldn’t need to count on gc.
I don’t know if it is even possible to generate a 64 bit exe, that would certainly fix it with higher memory limits. Some swf files go from 2 MB to using upwards of one GB when playing and it blows flash out, will try if this runs for c++ compile.

We do 32-bit Windows builds for simpler backward compatibility, but 64-bit Windows builds are planned. I think you can do it now in the tools, but we don’t distribute 64-bit builds ourselves

2 Likes

Hello!

ObjectPool leads to frequent crashes on the android platform. This is also not fixed in the latest (8.0.1) version of lime.
Crashes happen in different places where ObjectPool.get() returns a null object, for example:

  • openfl.display.DisplayObjectContainer.__getBounds (openfl/display/DisplayObjectContainer.hx line 725)
  • openfl.display.Bitmap.__getBounds (openfl/display/Bitmap.hx line 137)
  • openfl.display.DisplayObject.__dispatchWithCapture (openfl/display/DisplayObject.hx line 1462)

This usually happens when working in combination with Actuate.
From time to time we get such reports (via crashdamper) from different players:

openfl.display.DisplayObjectContainer.__getBounds (openfl/display/DisplayObjectContainer.hx line 725)
openfl.display.DisplayObjectContainer.__getBounds (openfl/display/DisplayObjectContainer.hx line 727)
openfl.display.DisplayObjectContainer.__getBounds (openfl/display/DisplayObjectContainer.hx line 727)
openfl.display.DisplayObjectContainer.__getBounds (openfl/display/DisplayObjectContainer.hx line 727)
openfl.display.DisplayObjectContainer.__getBounds (openfl/display/DisplayObjectContainer.hx line 727)
openfl.display.DisplayObject.__getLocalBounds (openfl/display/DisplayObject.hx line 1533)
openfl.display.DisplayObject.get_height (openfl/display/DisplayObject.hx line 1957)
...
Reflect.callMethod (/usr/local/lib/haxe/std/cpp/_std/Reflect.hx line 63)
motion.actuators.GenericActuator.complete (motion/actuators/GenericActuator.hx line 155)
motion.actuators.SimpleActuator.update (motion/actuators/SimpleActuator.hx line 529)
motion.actuators.SimpleActuator.stage_onEnterFrame (motion/actuators/SimpleActuator.hx line 608)
openfl.events.EventDispatcher.__dispatchEvent (openfl/events/EventDispatcher.hx line 402)
openfl.display.DisplayObject.__dispatch (openfl/display/DisplayObject.hx line 1399)

Since Actuate is using Reflect api, I would check if id’s (classes, properties, etc) really exists at runtime, then add appropriate meta to save them from dce like @:keep, @:keepInit or @:keepSub

Hi, T1mL3arn!

Thanks but I use -dce no.
I believe this has nothing to do with the issue under discussion.

Maybe it’s a thread race.
I wrote about it here: Multithreading and Matrix.__pool and Rectangle.__pool · Issue #2567 · openfl/openfl · GitHub
Check callbacks from Java for JNISafety: lime/JNI.hx at 9ebe6f3b6042e95b3e72635bedf1b8e0b3169acc · openfl/lime · GitHub
In debug mode, during a thread race, there will be the following traces: lime/ObjectPool.hx at 80f83f69c7874644c8229bb3a15687d1920203f4 · openfl/lime · GitHub