Are JavaScript primitive types garbage collected?

Question

I know that in Java and C# the garbage collector is for only reference types (not for primitive types) and works only for heap because objects in Java and C# are stored in the heap.

What about JavaScript, the reference types (array, object, function) are stored in the heap and the primitive types (number, boolean, string, undefined, null) in the stack. Here is a link about that.

In JavaScript there are several garbage collector algorithms which main principle is the count of references. These algorithms are Mark-and-Sweep and Reference Counting (the modern one is Mark-and-Sweep). The algorithms count references and primitive types don't have references and my guess is they can't be garbage collected.

In articles there is no word about how JavaScript primitive types are freed. My opinion is that it's freed when the current execution context finishes its work.

So how does JavaScript actually manage memory for primitive type variables?

Answer 1

There is nothing in the ECMAScript Language Specification that says that Primitives aren't garbage-collected. Likewise, there is nothing in the Specification that says that Primitives are garbage-collected. There is, in fact, also nothing in the Specification that says that Objects are garbage-collected.

Really, the Specification doesn't say anything about memory management at all. An implementation that does not use a stack would be perfectly compliant, for example.

So, the short answer is: you can't know whether Primitives are garbage collected or not, because the specification allows both.

Answer 2

As @JörgWMittag, says, the spec does not tell us, except that there is no explicit free operation, so sometimes there will be no choice but automatic memory management (eg garbage collection).

JavaScript defines the following:

A primitive value is a member of one of the following built-in types: Undefined, Null, Boolean, Number, String, and Symbol

Undefined, Null, Boolean, and Number all have fixed sized format. Number, for example, is defined in terms of IEEE 64-bit floating point. It is most likely that for local variables, these fixed sized formats are represented directly on the stack rather than being heap allocated. JavaScript variables, however, are not typed the way Java variables are, so these variables can change their types during execution, meaning that sometimes the program will do something that asks what type the variable is, sometimes requiring the runtime to dynamically store the type as well as the value. Still, that information is also probably fixed in size (eg a pointer), meaning even the combination of type and Number, for example, could be stored in a fixed size, stack allocated storage.

JavaScript transfers these primitive types by copying; it does not provide a reference-to-primitive mechanism (which would complicate storage management for them). However, it does have closures, and they capture variables not values. This means that sometimes local variables have to outlive their local scope, which suggests that for them the heap is necessarily used.

The String type, on the other hand, probably involves dynamic heap allocation, since strings can, for example, be dynamically-sized temporary values generated in a called function and returned to the caller. There are probably be situations where strings are not heap allocated (eg literals), and thus not garbage collected.

Java, on the other hand, defines specific sized primitive types, and String is not one of them (String is an object type).