Re: Ada GC

hbaker@netcom.com (Henry Baker) writes:


    > A company that offers what people ask for will do ok. A company that
    > offers what people didn't realize they needed will do fantastically.
    > I'd be surprised if Sun's customers were blowing down their doors with
    > requests for a garbage-collected scripting language that masqueraded
    > as C++, at least until Sun showed them what it was good for...


    > The second approach is called 'market leadership'.


        I was not only involved in the language standard development in
the early eighties, I was also involved in more than one Ada compiler
development effort.


        First, one of the few groups of users who desperately wanted
garbage collection were the compiler developers, especially the
front-end people. Since 256K machines were big machines at the start
of the compiler developments,* most prototye Ada compilers soon
started thrashing. After looking at the technical problems of doing
GC well enough to be useful, most compiler efforts started managing
their own in memory storage, garbage collection, and disk swapping for
both symbol tables and abstract syntax trees.


        The real "killer" is the interaction between a general garbage
collection scheme and tasks running in different address spaces, or on
different processors. Honeywell Small Systems decided in favor of
good tasking performance, as did most Ada vendors. (The real gotcha
in Ada 83 was the abort statement. It turned out that getting the
semantics right meant that task creation and garbage collection had to
be done by the same thread of control. So far so good--but when the
abort suspends that thread it CAN'T do any allocations until the abort
completes, or it will block. This breaks all kinds of abstractions.)


    > BTW, I understand that the new Telecom Bill that just passed Congress
    > has outlawed the ab*rting of tasks (or at least the discussion of it
    > on Usenet). This process will heretofore be called 'termination
    > enhancement', and an ab*rted task will be considered
    > 'termination-enhanced'.


      Yes, very unfortunate, and probably unconstitutional. I certainly
refuse to call the private part of a package specification the
"enhanced privacy" section...


--
Robert I. Eachus
--

Return to the comp.compilers page.
Search the comp.compilers archives again.