1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
<!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">
<meta name="published-on" content="2022-07-28T22:40:00+02:00">
<link rel="icon" type="image/png" href="favicon.png">
<link rel="stylesheet" href="style.css">
<title>Guilty Pleasure of Dirty Memory</title>
<header>
<nav><a href="https://ignore.pl">ignore.pl</a></nav>
<time>28 July 2022</time>
<h1>Guilty Pleasure of Dirty Memory</h1>
</header>
<article>
<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>
|
