No support for HXCPP_GC_MOVING

[barisyild]

If you have an application that constantly allocate/deallocate and you think you are experiencing memory leak problems, the problem is that this feature is not supported by Lime.

This feature enables the memory moving feature; otherwise, if the existing memory blocks are not available to allocate, a new block is allocated, thus the memory is used very inefficiently.

This situation causes your application to run out of memory after a certain period of time and even makes you think that you have a memory leak problem.

And yes, I've been trying to fix the memory leak for months, so it's a memory leak that doesn't exist.

[BoloVEVO]

Lime must support this define. In my flixel project (on Windows) I tried allocating 160k objects to a haxe.ds.Vector and then emptied it by setting all its members to null, the openfl memory counter went down but in the windows task manager still indicates the same memory when the vector was full.

In Hashlink this doesn't happen, all deallocated memory is removed from both openfl and task manager memory counter.

Including the define to my project xml solved the issue on windows, and I think it does in all lime targets that use the Immix Garbage Collector.

[rainyt]

gc_moveing.log
This is the crash log caused by me turning on HXCPP_GC_MOVING.

[BoloVEVO]

gc_moveing.log

This is the crash log caused by me turning on HXCPP_GC_MOVING.

Yes there is a pointer issue with the Cairo Graphics, not sure why since I don't know anything how pointers work.

Btw how can I get the gc crash log in my flixel project?

[rainyt]

@BoloVEVO I am reading from the Android crash log, and I am not sure about the desktop. Is it possible to run your application through the command line and receive error messages when crashing?

[BoloVEVO]

Yes you can get the crash log for a specific line but for some reason with HXCPP_GC_MOVING it crashes without giving me any log on the command line, even with HXCPP_STACK_TRACE defined.

[rainyt]

If you are currently maintaining memory without using 'HXCPP_GC-MOVING', it is recommended to release the old memory through System.gc() before generating new memory.

Like this:
SceneA loaded > playing > SceneA released > System.gc() > SceneB loaded.

[dimensionscape]

If you are currently maintaining memory without using 'HXCPP_GC-MOVING', it is recommended to release the old memory through System.gc() before generating new memory.

Like this: SceneA loaded > playing > SceneA released > System.gc() > SceneB loaded.

Yes you can manage memory to some extent this way, just remember that calling GC this way is more appropriate for opportune moments such as what @rainyt outlines here. Calling it often will probably cause notable stutters in frame rate so, probably not good to use during moments when user experience is important.

There are other practices you can do to minimize excessive memory such as pooling or allocators and reuse of current allocation space in order to reduce overall heap fragmentation. There are probably things we can do in OpenFL to improve memory utilization and one day we will probably support compacting, but its a bit of a hurdle at the moment. For now, its probably advised to refrain from allocating and then freeing memory often or in small chunks, that's why loading everything you need for a scene together and then freeing it when you're done can be effective because then you can make sure you clean everything up before allocating new resources.