Re: C++ Garbage Collector on VMS?

Johann 'Myrkraverk' Oskarsson wrote:
David J. Dachtera <djesys...@xxxxxxxxxxxxxxxx> writes:

Johann 'Myrkraverk' Oskarsson wrote:
David J. Dachtera <djesys...@xxxxxxxxxxxxxxxx> writes:

I have to ask: Why does a programming language (other than an
interpretive environment) need a "garbage collector"??!!
Maybe I'm implementing one in C++ and don't want to write my own
garbage collector? Boehm GC, afaict, is very popular among such
projects.
...which illustrates the difference in paradigm.

You're looking for something you think you need.

I'm asking why you need something that should never be needed. If a
compiled/linked program still needs garbage collection, either the
run-time, the program or both are seriously deficient.

You assume a GC should never be needed. I don't know what kind of
applications you're thinking of, but as I'm creating a lisp engine,
and the language is designed for a GC (and I believe the first GC was

I am not sure why you need a system based garbage collection scheme
or how it relates to what you are doing in lisp. I don't know much
about the Boehm GC nor what triggers its doing a garbage collection
so please excuse my ignorance if the following is not relevant.

Lisp wasn't designed for a GC. The GC was a necessity because of the
way Lisp functioned. As atoms and expressions were created, their
definitions and pointers were given "memory" from a free area.
There were no "alloc" functions available at that time. A running
application was loaded by the system into memory and given the
memory area it requested. Lisp was loaded into memory with a defined
contiguous area it used as a free space.

As Lisp continues executing, atoms/expressions are allocated. When
these "objects" were no longer pointed to, they were not placed back
into the free area. Doing so would have involved to much maintenance
code to keep track of what was being referenced.

When memory needed to be allocated and there wasn't any left to give,
lisp hiccuped and went into a garbage collection mode tracking down
all the referenced memory areas and then chaining everything else
into a new free list.

If you are creating a lisp engine and you are doing it the same way as
original lisp, you do need a garbage collector. Your other options are
to painfully code to keep track of what is in use and what isn't using
counters to keep track of pointers to a object and adding it back to the
free list when the count went to zero. I don't think you can use system
allocate and deallocate calls and let the system keep track of memory usage
since you still would need to know when to tell the system to free up
memory.

Of course, your lisp machine is probably being designed to not have a
maximum memory limitation. That complicates things. The original lisp
died when you ran out of memory.

written for the first lisp engine, but I can be wrong). There are
several run time environments that do GC that work on VMS. Java is
one, Oberon is another. There are probably more that I can't name
righ now? Are those run-time environments *wrong*? Or do you just
want them gone from VMS?

This is a toy project right now, and doesn't deserve the effort of a
custom built GC. I'd like it to work on VMS, but the lack of aparent
VMS support of the Boehm GC has me stomped.

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

The GC needs some system dependent details, such as register contents,
stack and heap locations, and so forth to function properly. I don't
know enough about VMS to supply and port Boehm right now.


Johann


.

Relevant Pages

  • Re: tagged/untagged data in lisp system programming
    ... How will you do memory ... What you can do is design an assembler that has Lisp syntax and write ... memory management systems that are hostile against garbage collection, ... its own data areas which are not subject to garbage collection. ...
    (comp.lang.lisp)
  • Re: where is the lisp operating system?
    ... It consists of low level interface code such as device drivers, ... dynamic memory and have to deal with pesky reclamation problems. ... They in fact implement garbage collection, ... The second misconception is that Lisp always requires garbage collection. ...
    (comp.lang.lisp)
  • Re: General method for dynamically allocating memory for a string
    ... memory and everything will work as expected. ... Garbage collection is too important to be left to the system - or, at least, in comp.lang.c it is. ... The Lithp people will no doubt have a different opinion, ... "Lithp" you mean Lisp, yes, they use a GC, as do other languages ...
    (comp.lang.c)
  • Re: Python syntax in Lisp and Scheme
    ... Pascal Costanza: ... programming have been and can be explored in a current Lisp. ... memory XY between X and Y and XZ between ... Consider also a "persistent memory" server running in C ...
    (comp.lang.python)
  • Re: Python syntax in Lisp and Scheme
    ... Pascal Costanza: ... programming have been and can be explored in a current Lisp. ... memory XY between X and Y and XZ between ... Consider also a "persistent memory" server running in C ...
    (comp.lang.lisp)