If a variable requires more than one byte, it'll be spread across multiple bytes in the heap; physically they are still just bytes, but in a logical sense (to the language's runtime) they are "a single variable". EG, a 64 bit int is built from 8 bytes in many cases.
If you allocate 3 big variables in that huge array, and destroy the 2nd, there is then an empty, unneeded space between 1st and 3rd which could conceivably be reused. If you need to allocate a larger variable, it cannot be fit into that empty gap left by the destruction of the 2nd, but you can put it after the 3rd.
You could successively put larger variables at the end and end and end - until the heap has no remaining contiguous byte subregions. Or you can do a "garbage collection" (GC) to pack the needed stuff together (or at least closer) and create a larger, unused space that can be used for larger variables.
Languages with automatic memory management like Java or Python use garbage collection. Languages like C with manual memory management do not.
If you originally needed a small variable between the 1st and 3rd, you could use that without adding at the end of the used regions or garbage collection. But note that using the closest fit is often a poor strategy that yields a lot of heap fragmentation.
The best garbage collection routines tend to be "generational". That is, they have some idea how long an object has been in the heap; the longer it's been there, the less often the heap will consider compacting it, because the memory associated with the most-recently created variables are more likely to be compactable.
Note that any healthy language has multiple implementations available,
(Java: Oracle JVM, IBM JVM, OpenJDK, gcj, et cetera; Python: CPython,
Pypy, Jython, IronPython, et cetera) and hence multiple runtimes, and
hence probably multiple different kinds of garbage collection going on
behind the scenes. Writing code that makes assumptions about what kind
of GC will be used is generally a poor idea.
You can e-mail the author with questions or comments: