Manual memory management. HXCPP

[Dmitry Hryppa]

Hey ;)

Is there a way for manual memory management on cpp targets?

I saw that function:

Gc.enable(false);

But can't find any way to remove objects from memory manually while GC is disabled. Is it possible? If no, why we need Gc.enable()?

Thanks!

[Juraj Kirchheim]

Just guessing here, but I would say disabling GC gives you the possibility to avoid your program being stopped unpredictably.

As for manual memory management, I'm not sure. I think Haxe-generated code always is managed and it's hard (and probably unwise) to break out of that. That said, object pooling is a form of manual memory management that works for any managed runtime environment.

Best,

Juraj

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Robert Konrad]

I guess object pooling doesn't help too much without generational garbage collection because the objects still have to be traversed repeatedly.

Gc.enable(false) I think is mostly for cpp interop - objects can't just disappear while GC is disabled which is very useful when you have some actual pointers around.
But maybe I'm totally wrong with both, only Hugh can tell.

[Juraj Kirchheim]

On Sat, Jun 17, 2017 at 12:22 AM, Robert Konrad <rob...@gmail.com> wrote:

I guess object pooling doesn't help too much without generational garbage collection because the objects still have to be traversed repeatedly.

I'm gonna go with "it depends" on that one. Depending on your use case, pooling can reduce actual allocation to a minimum, meaning the time between GC runs can be increased significantly. However if your whole memory is filled with dead objects lying around in pools, then the GC pauses will be longer. Tweaking the pool size may help find a sweet spot. But yes, it certainly isn't a one-size-fit-all solution for your memory problems. As always: measure ;)

Best,

Juraj

[Hugh]

This call stops the garbage from being collected - it will just pile up until you re-enable collection again, or it runs out and crashes.

You can use it for debugging or to prevent the collection happening at a pause-critical time.

You can use cpp.Stdlib.nativeMalloc and nativeFree to allocate bytes natively but you are really on your own here - and these can't contain haxe objects.

If your goal is to stop garbage collection overhead, then you might want to look at hxScout to profile where the allocations are happening and make some manual changes to your code.

It might be there are only a few places then need tweaking go get the collection frequency down significantly.

Hugh

[Dmitry Hryppa]

Thank you all guys for replied!

Well, it's just a thought... but is it theoretically possible to implement nativeMalloc and nativeFree for Haxe objects in HXCPP future? 

And possibility to disable GC at all.

That thing will be very useful, especially if you making libraries with Haxe (static or dynamic, or even plain source code), which should be used in plain C++ projects. 
Also, C++ guys don't very happy when you give them something with GC :D

понедельник, 19 июня 2017 г., 7:33:57 UTC+3 пользователь Hugh написал:

[Hugh]

The short answer is no, nativeMalloc/nativeFree are not going to work with normal haxe objects.

For interacting, there are a few possibilities:

1. You can use a GCRoot to hold the haxe pointer in native code. "freeing" the object is zeroing out the GCRoot - although it will not go away until later.

   This would generally involve the native code "seeing" the haxe and hxcpp headers, and would need careful management of the compile flags.

2. You can use the cffi interface and gc roots to hold opaque references to haxe objects

3. Create a native object and hold a reference to it in haxe.  You can use a hxcpp finalizer to delete it

4. You can use "nativeGen" interfaces which creates header files that can be included without depending on hxcpp compile flags. There is a GCRoot helper to allow these to be stored in native code.

Hugh