Hi,
These weeks I fixed the final bugs of the new _d_arraycatnTX hook. When cleaning up the code, Razvan and I took a closer look at the extra lines produced by -profile-gc. They are referring to the new _d_arraycatnTX and seemed to indicate that it allocates some extra memory. In this forum post I asked how to deal with them. Following Max's advice, I did some digging and 2 things turned out:
- 
the old hook uses a private function called __arrayAlloc()to allocate the concatenated array, which is not instrumented, whereas the new one simply sets the.lengthof the resulting array. This expression is further lowered to_d_arraysetlengthTand this hook is instrumented. It is possible that this is the cause of the differences.
- 
My implementation of _d_arraycatnTXTrace()was buggy. This caused some unnecessary bytes to be allocated. After fixing this, I'll be able to better look into point 1 from above and be more certain regarding the newly added lines when-profile-gcis enabled.
Regarding _d_newitemU, we decided it would be more rational to move more of the lowering logic to the hook, as DRuntime already handles struct and context pointer initialisation in copyEmplace(). I am going to use the same logic in the new _d_newitemT (instead of _d_newitemU) hook, together with calling the struct's ctor. What's problematic with this approach is that I need to make the compiler create a "dummy" object before calling _d_newitemT, so the lowering would look like this:
// original expression:
S* s = new S(args);
// lowering:
S* s = (void[0] ctxPointerTmp, _d_newitemT!S(ctxPointerTmp))
I would like to be able to obtain the context pointer in the frontend of the compiler without having to allocate any other objects. I asked about this in this forum. I am looking forward that the community will help me find a cleaner solution.
Thanks,
Teodor
 Permalink
Permalink Reply
Reply