From 688043a2c7b5990865cbd6fe9e53c4e5116415d6 Mon Sep 17 00:00:00 2001
From: Simon Brooke <simon-brooke@users.noreply.github.com>
Date: Sat, 19 Jan 2019 11:03:28 +0000
Subject: [PATCH] Updated memory management (markdown)

---
 memory-management.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/memory-management.md b/memory-management.md
index ca90a26..25fd70c 100644
--- a/memory-management.md
+++ b/memory-management.md
@@ -71,4 +71,8 @@ Even the 'separate freelists for different sized objects' idea won't prevent vec
 
 There are several possible approaches to optimising garbage collection. I want to try as many as possible of these approaches, although I'm not convinced that any of them will prove in the end better than a conventional generational garbage collector. Still, they're worth trying.
 
-What we need to do is build a system into which different memory management subsystems can be plugged, and to develop a set of benchmarks which aggressively test memory allocation and deallocation, and then see how the different possibilities perform in practice.
\ No newline at end of file
+What we need to do is build a system into which different memory management subsystems can be plugged, and to develop a set of benchmarks which aggressively test memory allocation and deallocation, and then see how the different possibilities perform in practice.
+
+## Further reading
+
+I've written a [number of essays](https://blog.journeyman.cc/search/label/Memory%20management) on memory management, of which I'd particularly point you to [Reference counting, and the garbage collection of equal sized objects](https://blog.journeyman.cc/2013/08/reference-counting-and-garbage.html).
\ No newline at end of file