It’s probably not doable to explain Extempore’s memory allocation story without a detour into xtlang types, so we’ll cowl a few of that as well. The 2 languages hosted by the Extempore compiler, xtlang and Scheme, have completely different approaches to allocating & managing memory. Each languages ultimately share the same Memory Wave-the stack and heap associated with the Extempore process-but through completely different mechanisms. Broadly talking, with Scheme code Extempore manages memory for you, while in xtlang it's a must to do it yourself. This is a typical trade-off, and each has its advantages (in performance, programmer productiveness, and many others.) and disadvantages. So if you’re principally going to be writing Scheme code (e.g. you’re making music using the built-in instruments) then you probably don’t have to learn this (although understanding how issues work beneath the hood is still generally useful). To work successfully in xtlang, although, you’ll need to now a bit more about memory in Extempore. Scheme objects (lists, closures, numbers, etc.) are mechanically garbage collected by the Extempore run-time rubbish collector (GC).

Because of this when new objects are created, memory is automatically allotted to retailer these objects, and as objects are destroyed or exit of scope (that is, there are not any references to them) the memory is robotically freed up for re-use. Let’s do essentially the most primary memory allocation possible: simply binding a numerical worth to a symbol. The truth that we can use the image a and have it consider to 5 (as it should) implies that the worth (5) must be stored in memory someplace. It doesn’t matter the place in memory (what the handle is), because we will all the time refer to the worth using the symbol a. However it’s good to do not forget that the define kind is allocating some memory, storing the value 5 in that Memory Wave Method, and binding a reference to the value in the image a. We are able to redefine the image a to be some other Scheme object, say, an inventory.
wikipedia.org

The three-aspect checklist (1 2 3) takes up more memory than the number 5. So outline can’t simply write the brand new worth of a excessive of the old one. What it does (and in fact what re-defining issues all the time does) is allocate some new memory to retailer the new value into, and change the variable a to level to that new worth. But what occurs to the old value of 5 in memory? Effectively, it sits there untouched, a minimum of for some time. However we can’t reach it-the one ‘handle’ we needed to consult with it with was the symbol a, and that’s now bound to another worth as a substitute. The value 5 in memory is ‘unreachable’. So there’s no point having it sitting around, taking up house. That’s the place the garbage collector comes in. Every now and then the rubbish collector checks all of the Scheme objects on this planet, determines which of them are no longer reachable, after which frees up that memory to be used for different things.

While I don’t advocate this harsh utilitarian approach to dealing with kin who are down on their luck, it is good idea in a pc program. Memory is a finite resource, and the more effectively we are able to do away with memory that’s not getting used the higher. Basically, having a GC implies that when you’re writing Scheme code, you don’t have to fret about memory. The GC takes care of all of the allocation/deallocation bookkeeping for you. The fee is that this bookkeeping requires CPU cycles-cycles which you could possibly be utilizing to do different cool things. Also, every so often the GC has to briefly ‘stop the world’ (freeze the execution of all Scheme code) to do its job. This takes time, and introduces a component of uncertainty (non-determinism) to the execution of your code-you by no means know precisely when the GC goes to freeze things to do it’s job, and there’s a risk that it’ll occur at a extremely inconvenient time so far as your program is worried (Murphy’s regulation and all that).