Test hxcpp gc moving objects

[jcward]

You can define HXCPP_GC_MOVING and call cpp.vm.Gc.compact() from haxe code

See: https://github.com/HaxeFoundation/hxcpp/blob/0d0dd2a2797ffa7196a889679ba059aa67d380da/src/hx/gc/Immix.cpp#L2305-L2314

[jcward]

More of the conversation:

Hugh Sanderson [10:13 PM]
If you are tracking creation count, you don't need to do anything in the collection
If you are tracking lifetimes, then you need to do something
I think the fastest way is to iterate over your live object list immediately after marking and check to see if it is still marked.
This should be a simple byte offset an lookup per pointer.
If you only wanted to track the creation of Double/Int/StringData and assume they are not live after next next collect, you probably would not be too far wrong, and you could save some time.

Jeff Ward [5:27 PM]
Thanks, @hugh - so iterating over my live object list would look something like this?
https://github.com/HaxeFoundation/hxcpp/blob/master/src/hx/gc/Immix.cpp#L3214-L3226 (edited)

Hugh Sanderson [10:28 PM]
Yes, you would be basically doing exactly what this finalizers do - except you already have your list of pointers.

 unsigned char mark = ((unsigned char *)obj)[ENDIAN_MARK_ID_BYTE];
      if ( mark!=gByteMarkID ) // Old

Hugh Sanderson [10:39 PM]
Yes - I've added defragging and compacting (for 'memory low' messages), but this is currently not enabled by default because you need the HXCPP_GC_MOVING define.
I'm wondering if the telemetry code is ready for moving blocks. The "movespecial" code handles this
One possibility is to not allow moving with telemetry on

Jeff Ward [10:44 PM]
Hmm, I vaguely recall doing something wrt moving or reallocation, not sure if that's the same thing. Not sure how well it's tested.

Hugh Sanderson [10:48 PM]
Probably not tested because this code has not been active for a while. Although, it appears to mostly follow the pattern, so could be ok.

Jeff Ward [10:50 PM]
Yeah, it looks like it handles the finalizer, but it looks like it doesn't inform the Debug.cpp of the changed pointer, there's a todo here:
https://github.com/HaxeFoundation/hxcpp/blob/0d0dd2a2797ffa7196a889679ba059aa67d380da/src/hx/gc/Immix.cpp#L2305-L2314 (edited)
I can do some testing -- is there any way to force this to happen more often?
smaller memory parameters or some trigger?

Hugh Sanderson [10:53 PM]
You can define HXCPP_GC_MOVING and call cpp.vm.Gc.compact() from haxe code

Jeff Ward [10:54 PM]
ok, great, I'll look into it, then. I might expect perhaps to see those printf's with HXCPP_GC_MOVING and HXCPP_TELEMETRY both defined

Hugh Sanderson [10:56 PM]
There are some other possibilities depending on how things are done.
One woud be to attach the telemetry data pointer to the allocation directly by using some space at the end of the buffer
Then this would be moved when the allocation is moved
You would then need to walk over all the objects that were active since the last collect to find out what has been collected

Jeff Ward [10:58 PM]
Oh, and another topic -- if I change the interface of telemetry in Debug.cpp and need to detect that in hxtelemetry.hx, since I didn't put a version in to start with -- can I do something like:
Debug.cpp:
#define TELEMETRY_VERSION=2
Hxtelemetry.hx (@Header or something):
#ifndef TELEMETRY_VERSION
#define TELEMETRY_VERSION=1
Would this work with older (undefined) and newer (ver=2) hxcpp?

Jeff Ward [10:58 PM]
Or is there a different/better way to detect hxcpp version?

Hugh Sanderson [11:00 PM]
You can change toolchain/common-defines.xml to define HXCPP_TELEMETRY=2 if you like - this will be visible in the generated .cpp code
But not the .hx code

Jeff Ward [11:01 PM]
Can my HxTelemetry library be compatible with both versions?

Hugh Sanderson [11:02 PM]
It depends on if you need to change the haxe code
You could do something like inject "version=2" FROM the haxe code (via build.xml) and then check in Debug.cpp and do some kind of wrapepr for the old code

Jeff Ward [11:04 PM]
Ok, thanks for the info!

James Gray [11:08 PM]
is the plan to define HXCPP_GC_MOVING by default?

Hugh Sanderson [7:23 AM]
I think so - it only really adds overhead if its needed (which is fair enough I think) but also adds a bit to "get object id" and objecthash on 32 bit systems, since we can no longer use the raw pointer.
It also allows for memory compaction which can be useful on mobile

[jcward]

While moving support was added here (HaxeFoundation/hxcpp#332) there is still a crash being investigated here (come back to this when time allows): HaxeFoundation/hxcpp#333