will.basicMemoryManager

flash.Memory opens up some very exciting possibilities for flash developers.

However, at any one time only a single ByteBuffer can be selected.

Therefore, if two classes or libraries use flash.Memory, they can conflict with each other.

will.basicMemoryManager is a simple memory manager for the allocation of parts of a single ByteBuffer, so that all classes can safely use flash.Memory without conflicting with other independent pieces of code in the same program.

Code using flash.Memory should call will.basicMemoryManager.Heap.Alloc(size) instead of flash.Memory.select(). The memory manager manages a single shared ByteBuffer where all allocations are stored.

The Alloc() return value is an Int which is the base offset of the allocation in the shared heap. This can be used as a base offset for all flash.Memory functions e.g.

var addr = will.basicMemoryManager.Heap.Alloc(100*4); // allocate 100 ints
var ofs = addr;
for(i in 0...100) {
   flash.Memory.setI32(ofs,0x00000000);
   ofs += 4;
}
...
will.basicMemoryManager.Heap.Free(addr);

It is important that code explicitly calls will.basicMemoryManager.Heap.Free() when the buffer is no longer needed, as these are not automatically garbage-collected by the Flash Runtime.

Basic c-style Alloc(), Realloc() and Free() are provided. A Memcpy() utility function is also included.

Additonally, specific functions for accessing pixels in BitmapData objects are available: GetPixels() and SetPixels().

Compilation

Compile your swf with -swf9, -swf-version 10 and -lib basicMemoryManager.

Implementation Details

A single ByteBuffer is used. A double-linked list of 'cells' tracks the used and unused parts of this buffer.

There is no attempt at wilderness, best-fit nor size-ordering of the free cells; rather the cells are stored in strict sequential order so all allocation and freeing will require walking the list using a first-fit algorithm.

Managing the allocations is not especially expensive, but it is not free! It is not optimised for small nor short-lived allocations, but rather a small number of long-lived allocations.

The buffer is never compacted and allocations are never repacked within the buffer; the ByteBuffer will stick at the 'high tide' of usage.

version #7901, modified 2010-01-12 00:02:21 by willvarfar