LWDR SAOC Milestone 1, Weekly Report for 15th SEP to 22nd SEP 2021

[Dylan Graham]

[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/lifetime/delegate_.d). The system is opt-in via the compile time version [`LWDR_ManualDelegate`](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/lifetime/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/lwdr/package.d#L62), which calls an [internal function](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/lifetime/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/lwdr/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/lwdr/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/lifetime/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/06920ce4086abeb088af7bad8a6b33cb33bbd10d). The root was code that [calls destructors](https://github.com/hmmdyl/LWDR/blob/e1c2fa4c09d72ceea7f3fa9778c6cad5dc471354/source/lifetime/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.