diff options
| author | Aki <please@ignore.pl> | 2022-07-28 22:41:12 +0200 |
|---|---|---|
| committer | Aki <please@ignore.pl> | 2022-07-28 22:46:31 +0200 |
| commit | 68551c18384ce9fc2036c70fc9c2196c7019a593 (patch) | |
| tree | e1ccbd1cd6859c5af1d4abb167f68e632ee69ec8 | |
| parent | 6fee55b6b086afb4f568e2a23ab1ad65b5fc8444 (diff) | |
| download | ignore.pl-68551c18384ce9fc2036c70fc9c2196c7019a593.zip ignore.pl-68551c18384ce9fc2036c70fc9c2196c7019a593.tar.gz ignore.pl-68551c18384ce9fc2036c70fc9c2196c7019a593.tar.bz2 | |
Published memory deallocation article
| -rw-r--r-- | guilty_pleasure_of_dirty_memory-1.png | bin | 0 -> 2128 bytes | |||
| -rw-r--r-- | guilty_pleasure_of_dirty_memory.html | 49 | ||||
| -rw-r--r-- | index.html | 2 |
3 files changed, 51 insertions, 0 deletions
diff --git a/guilty_pleasure_of_dirty_memory-1.png b/guilty_pleasure_of_dirty_memory-1.png Binary files differnew file mode 100644 index 0000000..3e384cb --- /dev/null +++ b/guilty_pleasure_of_dirty_memory-1.png diff --git a/guilty_pleasure_of_dirty_memory.html b/guilty_pleasure_of_dirty_memory.html new file mode 100644 index 0000000..37123d8 --- /dev/null +++ b/guilty_pleasure_of_dirty_memory.html @@ -0,0 +1,49 @@ +<!doctype html> +<html lang="en"> +<meta charset="utf-8"> +<meta name="viewport" content="width=device-width, initial-scale=1"> +<meta name="author" content="aki"> +<meta name="tags" content="free, allocate, deallocate, memory"> +<link rel="icon" type="image/png" href="favicon.png"> +<link rel="stylesheet" href="style.css"> + +<title>Guilty Pleasure of Dirty Memory</title> + +<nav><p><a href="https://ignore.pl">ignore.pl</a></p></nav> + +<article> +<h1>Guilty Pleasure of Dirty Memory</h1> +<p class="subtitle">Published on 2022-07-28 22:40:00+02:00 +<p>"Remember to free the allocated memory!" That's what we usually teach everyone when they start their journey with +manual memory management. Of course, it's the rightful way. The one and only, isn't it? +<p>Well, yes but no.</p> +<img src="guilty_pleasure_of_dirty_memory-1.png" alt="bucket"> +<p>Let's start with the basics - why do we deallocate the memory? It's because we, or rather the program that we +implement, does not own it. Instead the memory is requested from the Operating System or otherwise some kind of +allocator. It provides part of the memory to the program. It's natural to give it back after we are done since that's a +part of the contract (although it's an unwritten one usually). +<p>The thing is - we can ignore this contract. OS will reclaim any memory allocated for the process after the process is +done. It will consume its corpse and leave nothing behind. There are rules and exceptions, so let's write a formal +sentence describing this approach. +<p><strong>When implementing a short-lived userspace program, you don't need to pay attention to freeing memory +allocations.</strong> There is literally no point to it. You don't risk any memory leaks this way. What is a +"short-lived program", and are there things I need to pay attention to? +<p>I'm gonna answer the first one in a vague way. For me, this means something like a thing I would execute from shell +and expect "immediate" response. For you it might be something completely different and I honestly don't care. The whole +point is to be free once in a while. If thinking about whether you should do it or not takes too long, then it's +probably better to do the usual thing. If you have a hunch that you can do it and there is no real cost, then what are +you waiting for? For sure don't do it in daemons (unless you are old PHP). +<p>As for things to pay attention to - first off, anything that's not owned by the process or that live longer than it. +Of course, these are not "allocated memory", but use this as a reminder to not get too careless. This is an opportunity +to have fun right at the boundaries of the "correct" implementation and not beyond them. +<p>Another potential problem is growing rate. Even a short-lived program can try to allocate a lot of memory. This can +easily accumulate in loops or similar situations, so keep an eye on that. As a good rule of thumb it's easier to just +deallocate the memory that was allocated in a loop. +<p>Now, now, before you comment that it's a stupid idea. Yeah, it is. That's exactly why you should try it at least +once. This is an exercise about manual memory management: "can you guess which things are actually worth deallocating?" +This is a fun activity if you like programming and enjoy trying things in a completely unusual way. This is a liberating +approach that let's you focus on solving some problem instead of being correct. This is an excuse when you simply forgot +to free memory and someone pointed it out. +<p>It's all of it, and also a stupid idea. Everything depends on the point of view and what you have in hands. Try it! +</article> +<script src="https://stats.ignore.pl/track.js"></script> @@ -37,6 +37,8 @@ software and hardware engineering. I post here my projects, experiments, and wha <section id="posts"> <h2>Posts</h2> <ul> +<li> <a href="guilty_pleasure_of_dirty_memory.html">Guilty Pleasure of Dirty Memory</a><br> + <time>2022-07-28</time> <li> <a href="lets_not_store_versions_in_versioned_files.html">Let's Not Store Versions in Versioned Files</a><br> <time>2022-07-02</time> <li> <a href="using_pacman_to_manage_emscripten_packages.html">Using pacman to Manage Emscripten Packages</a><br> |
