On memory management

[Matthew Tuck]

Ursula Dreier wrote:

> 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.

Automatic memory management should be the norm in any language by now. 
What I'm not sure of is whether we should allow for a dynamic delete if
the programmer really wants to.

There is actually a garbage collection mailing list if anyone's
interested.

> 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.

General persistence also needs to be able to recognise pointers in an
arbitrary memory block.

> 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

By "type", do you mean pointer to metaclass object?

> 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.

Are these exceptions integers, characters, etc.?  Why is there the need
for this distinction?

> 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 sounds like you're doing a partial persistent dump.  I'm not
exactly sure what you mean here though.

> 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.

I guess I've missed the plot of this.  I know Smalltalk does something
with keeping the program and development environment together.  The main
advantage of the run program with development environment I can see is
for debugger and profiler modes.  And you can changed code at run-time,
but I'd call this a debugger feature.  Is that basically what it
allows?  I'm not too sure how this would work with heavily optimised
code, but I guess you could turn off the feature or the optimisation.

I assume the "access restrictions" you're referring to are a form of
sandboxing - I'd use a similar box for the editor views as I mentioned
before.

> 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.

By resemblance are you referring to the memory model or the ability to
change itself?

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/