• Dylan Graham (36/36) Sep 22 2021 [Source Code](https://github.com/hmmdyl/LWDR)
• Dylan Graham (8/11) Sep 22 2021 Also, a big thank-you to Adam D. Ruppe for his mentorship and

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.