On memory management

[Ursula Dreier]

I as a user would not like to be bothered with memory management at all.
If an object is not being referenced any more, it should be discarded
automagically. No stack. No heap. No malloc. No delete. No dangling
pointers. No need to copy things before they go out of scope. No care
about memory leaks.

To achive this, there is no way but to have automatic garbage collection
(GC). This in turn leds to the neccessity to be able to recognize links
(pointers or the like) between allocated memory blocks.

Here's my suggestion for a memory layout:

You have storage allocated from the OS in big "chunks". It will be
divided into smaller clocks, each containing one object. Each object has
a length, a type (which is a pointer to another object), some
information for memory management and a contents. The contents can be of
two categories: Nodes and Atoms, depending on the type of the object.

Atoms contain binary stuff and are used to implement machine dependent
things like byte codes, machine code, numbers, strings, structures for
use by the OS.

Nodes contain pointers to objects and (sometimes, as an exception to the
rule) binary stuff, marked by some prefix and (if of unknown length)
accompanied by a length.

Both categories should be easily distinguishable by the garbage
collector.

Note that nothing has been said about how code is being executed - it
could be P-Code, machine code, byte codes, you name it. Of course, there
has to be an interface to the real machine somewhere. You would have a
special object type (I call it MC for machine code), which usually has a
compiler recognizable parameter description attached to it. It is
referenced by the corresponding method description as well as by
generated P-Code. It contains a pointer somewhere into executable code.

While you are developing an application, it (source, comments, compiled
code, graphical resources, etc.) resides in memory in the form of
objects as well as the development environment, the runtime and any
included package.
When you produce a version for shipment to the customer, the objects
containing the source code and the development environment will be
discarded as far as they are not referenced by the compiled code (their
references being chopped off by deleting to names of their name spaces
and the memory being recycled by GC).

This means that you have a truly INTEGRATED environment where your
application and your development tools can run together in the same
process at the same time. It means that you would even be able to view
and modify the development environment while it is running, if you
choose. Of course, normally your application project, the runtime and
the development environ would be separated by means of different name
space entries as well as access restrictions to avoid accidental damage.



It's all very similar to LISP, maybe except for the fact that a node
object in LISP usually consists of only two pointers (car & cdr) whereas
node objects here are intended to contain any number of pointers, their
semantics depending on the object type.


Hans-Dieter Dreier