digitalmars.D - LWDR SAOC Milestone 1, Weekly Report for 15th SEP to 22nd SEP 2021
Dylan Graham <dylan.graham2000 gmail.com> writes:
[Source Code](https://github.com/hmmdyl/LWDR) [Plan](https://github.com/hmmdyl/SAoC2021/blob/main/plan.md) [Proposal](https://github.com/hmmdyl/SAoC2021/blob/main/proposal.md) [SAOC Projects](https://dlang.org/blog/2021/08/30/saoc-2021-projects/) Light Weight D Runtime. 22nd September, 2021. Symmetry Autumn of Code, Week 1 of Milestone 1. Hi all, Sadly, this week has not been very productive. My university is 3/4 through the semester and our "mid" semester break is *next week*, so my tutors have been cramming assignments into this week. Fortunately, next week I will have ample time, and in the final 1/4 of the semester I only have two assignments. My workload will be easier and I can achieve more. During the week I worked through items for task 3 - manual deallocation of delegates/closures. Delegates [may store some stack context information on the heap](https://tour.dlang.org/tour/en/basics/delegates), and it is exposed via a delegate's `ptr` property. It may or may not be context information - it could instead be a class reference or struct pointer, etc. Thus LWDR discriminates between what the `ptr` actually stores and only frees the stack context information. This heap space is allocated with `_d_allocmemory`. Normally, the GC would be responsible for freeing this space, instead LWDR will provides a function so the programmer can manually free the allocation. The supporting code is in the module [`lifetime.delegate_`](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/li etime/delegate_.d). The system is opt-in via the compile time version [`LWDR_ManualDelegate`](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/lifet me/delegate_.d#L6). `_d_allocmemory` was implemented. LWDR stores a pointer to the allocated memory in an internal list. When the programmer is done with the delegate, they can call [`lwdr.LWDR.freeDelegateContext`](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/ wdr/package.d#L62), which calls an [internal function](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/lifet me/delegate_.d#L38) that checks if the pointer is in its list, and if so, frees the memory via a call to `_d_delmemory`. This means that any delegate can be passed to this function - it will only delete copies of the stack context information. Initialisation and de-initialisation code (invoked at runtime [start](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source lwdr/package.d#L69) and [stop](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/ wdr/package.d#L78)) is implemented to allocate space for the list, and to deallocate the list and any residual delegate allocations. As for the keeping track of the allocations, an [array](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/ wdr/internal/arr.d) is allocated. Insertions and deletions are handled with atomic compare-and-swap operations, as multiple threads and even multiple cores can concurrently allocate and deallocate. If the list is full, LWDR panics. The pointers are stored as `size_t`s, as CAS operations don't work with `void*`. A singly-linked list was also considered, but rejected as it could cause memory fragmentation issues on memory-constrained systems. The caveat of the current approach is that there is a limit on the number of delegate contexts LWDR can keep track of ([selectable](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/life ime/delegate_.d#L8) at compile-time). I think a singly-linked list of arrays may be a suitable tradeoff between the two approaches, but looks like it could rely on thread blocking operations. I will look into this after tasks 1 and 2 are complete. Due to linker issues, I have attempted to make [functions ` nothrow` where possible](https://github.com/hmmdyl/LWDR/commit/06920ce4086abeb088af7b d8a6b33cb33bbd10d). The root was code that [calls destructors](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/li etime/array_.d#L98) in arrays. Once exception handling is implemented, this behaviour will/may(??) need to be selectable, since ` nothrow` functions won't run destructor calls on an exception path, unless a way around is found. Unless, I implement the stub the linker was complaining about and avoid trying to make things ` nothrow`, as I'm probably just making more work for myself. As you can tell, this area needs to be fleshed out. All the best, Dylan Graham.
Dylan Graham <dylan.graham2000 gmail.com> writes:
On Wednesday, 22 September 2021 at 13:41:42 UTC, Dylan Graham wrote:Light Weight D Runtime. 22nd September, 2021. Symmetry Autumn of Code, Week 1 of Milestone 1.Also, a big thank-you to Adam D. Ruppe for his mentorship and assistance, Mike Parker for his organising and communication in this Autumn of Code, the D Language Foundation and Symmetry Investments for hosting the SAOC and giving me this opportunity, and everyone in the community for developing this fantastic language.