Telemetry updates (GC_MOVING, finalizers -> mark/sweep, gcoverhead)

[jcward]

A couple of updates to HXCPP_TELEMETRY:

1. Compatibility with HXCPP_GC_MOVING
2. Changed deallocation tracking from finalizers to post-mark ID-check sweep
3. The above allowed easy measurement of GC telemetry overhead (which I'll later report in hxScout)

@larsiusprime - you mentioned running your code through hxScout soon -- if you want to use this hxcpp branch (jcward/telemetry_update) that might be a nice smoke test. If not, no worries. :)

[madrazo]

Hi. I have try it (windows 10, vs2015, without M64 flag) but got a crash in Debug.cpp line 2524 ( allocation_data->push_back(obj_id); may be de above line). It happens when loading game level.

It is called from __hxt_new_hash (Debug.cpp)

called from Hash.h line 251: if (is_new) __hxt_new_hash(bucket, inNewCount*sizeof(ELEMENT *));
called from allocElement, TSet,
Hash cpp. set (line 270)
Anon.cpp line 102
Fast.cpp line 194 (in haxe Fast.hx HX_STACK_LINE(166), - HX_STACK_LINE(172))
Dynamic tmp57 = nodeFrame->get_elements();

In haxe, it is something like:
myFast:Fast received as parameter

                        for ( myFastElement in myFast.elements )
                        {
                        }

Maybe a buffer is full? Thanks.

[jcward]

One more update I forgot -- the name parameter that Hugh implemented wasn't being passed from Object.h's new to telemetry allocation tracking. These were showing up as _non_class, and will now have names, e.g. Float.

@madrazo - Hmm, I haven't seen this, I'll give it a try on Windows. The alocation_data access is protected by a mutex, so it shouldn't get in a bad state. As for a full buffer -- perhaps it could have run out of ram?

[madrazo]

Thanks for your reply.

It does not crash if I do not open hxScout.
I closed all other applications and still crashes so it is not the RAM.
Changed variable name and used GC reserve memory, without luck.

It always crashes at nearly same location, at a "allocation_data->push_back" in Debug.cpp
(allocation_data->push_back((int)inSize);
allocation_data->push_back(stackid); )

It also crashes without GC_MOVING which I think confirms that the issue is from threading.
I am also using "URLLoader" in Lime legacy.

Thanks

[jcward]

@madrazo thanks for the additional information. Did you tesd telemetry prior to this PR (on master branch)? I wonder if the bug is new for this PR. Thanks again!

[madrazo]

Sorry, with the haxelib's hxcpp version (without these) it also crashes. So its not a bug from this.
I try it a time before and was OK, but now the number of assets has increased and it was before the changes of the GC.

Now the error also appeared at alloc_map[obj_id] = this; (Debug.cpp, line 2500) , obj_id is 834515052.

I noticed that hxScout crashes sometimes before my application.

Thanks

[madrazo]

I think that the issue has to do with that the xml files use elements with the same name.

[jcward]

@madrazo / @hughsando - FYI, I filed #333 as a separate issue for the crash (since it existed before this PR.) We can continue the investigation there.

[hughsando]

Hey Jeff - do you want this one merged as-is?

On Tue, Nov 17, 2015 at 7:53 AM, Jeff Ward notifications@github.com wrote:

@madrazo https://github.com/madrazo / @hughsando
https://github.com/hughsando - FYI, I filed #333
#333 as a separate issue
for the crash (since it existed before this PR.) We can continue the
investigation there.

—
Reply to this email directly or view it on GitHub
#332 (comment).

[jcward]

@hughsando yes, please. We decided the above issue was pre-existing, and I'm still investigating.