If you already have a subscription, you can sign in.
Enjoy free content straight from your inbox 💌
00:00
A critical fact worth knowing about JavaScript is its automatic memory management. Unlike low-level programming languages like CNC plus plus, we are not directly responsible for managing memory in JavaScript as it is done automatically by the built-in garbage collector browsers do not expose the underlying garbage collector. However, we can access it in a server environment like node js as an example. We can determine how much memory is being used by the JavaScript heap by using process memory usage. Additionally, we can even trigger a garbage collection manually if we wanted to. Let's just note the heap used before we trigger the garbage collection then
00:36
trigger a garbage collection using the node builtin global dot GC function, and then node the heap used afterwards. Using the before and after values, we can actually determine how much memory was freed up by that call to Global DOT GC. To demonstrate the garbage collector in action, we create a class heavy that creates a very large array consisting of a hundred thousand characters. Additionally, we create a function called consume that takes a character as an input and then creates a 2,500 array of heavies. Note that we create an array within consume and then return it.
01:12
So if we never store a reference to this array, when we call this function, then it should be available for garbage collection and the JavaScript GC should be able to free up that memory with this heavy infrastructure and utilities created. Let's just write on our code within a main function. First up, let's demonstrate the garbage collector in action by invoking the function, consume with different characters, but not storing that resulting array in any variable. We note on the memory that is currently being used by the process and consume a lot of memory for the trash emoji and then note on the memory being used
01:46
afterwards and then invoke the garbage collector. The garbage collector should be able to free up all the memory that the consume occupies and therefore we can do this as many times as we want and it should all work perfectly fine. Let's consume the memory with a few different emojis and every time we've made a consume call, we should see the memory consumption rise, and after the garbage collection, the memory consumption should decrease again. If however, we store the resulting array from consume into a variable, that would mean that the array is still within scope and the garbage collector will not be able to collect it.
02:19
And we should see our memory continue to rise after every single consume call where we are storing the results into different variables. As long as the variables Uno duo and tray are pointing to those arrays, the arrays will need to stay in memory and the garbage collector can't do anything. And now for the moment of truth that you have been waiting for, let's just execute this code and demonstrate it in action. Within our fire and forget version, we will do not store the result of consume. You can see that every single time the garbage collection call has been made, we have managed to free up a thousand mb. However,
02:52
when we keep the result into a variable, the memory consumption just keeps going up and up and the garbage collector Has not not been able to free any memory. Now, within JavaScript, we don't actually have to call the garbage collector ourselves. JavaScript would have jumped in and done that smartly depending upon how busy the code is and how much memory is available. But in node js, since it is a server environment, it does provide a hook to trigger it manually if you wanted to. If we keep allocating resources but do not free them up, eventually we will run out of memory and in the browser our tab will crash. Here we have the same utilities pasted into the browser console.
03:29
We have a class that creates a heavy character array and a consumed utility that creates a massive array consisting of heavy items. If he makes six different calls to consume, it's going to be perfectly fine because every single time a consume call is made, we discard the result, which means that that memory that has been allocated can be deallocate by the built-in garbage collector. However, if we start to store these results into different variables, that will mean that all of this memory will still hang around. The garbage collector can't do anything about it, and we will eventually run out of memory and the browser dev tools will actually
04:03
even pause pointing out that we are about to exhaust our resources. If we ignore this warning and push through with the code execution, we will eventually run out of memory and the browser tab has crashed. As you can see on the left hand side, of course, on a production site, the user is probably not going to have the dev tools open, so they will not get any warning. The website will just crash. The takeaway lesson is pretty simple. Whenever we are done with the value, we shouldn't keep a reference to it anymore. This will happen automatically if a variable goes out of scope. But if you still have the variable,
04:35
we can do simple things like assigning it to now. So we start again by pasting in the utilities for heavy and consume, and we will still make consume calls and store the results in different variables. This means that we can use the results, for example, to look at the first character, but after we are done with it, we will assign that variable to know and this will allow JavaScript to clear up that memory that was previously being occupied by that variable. So now if you run the code, even though the memory allocation might be high, we will not run out of memory because it'll be available for the garbage collected to collect as soon as the value is no longer referenced from our code.
05:13
Scap comes with an excellent garbage collector, and because of the browser wars, it's probably one of the best in the business, and you mostly don't need to think about memory management. As always, thank you for joining me and I will see you in the next one.