Path: utzoo!attcan!uunet!jarthur!usc!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcupt1!thomasw From: thomasw@hpcupt1.HP.COM (Thomas Wang) Newsgroups: comp.object Subject: Re: Re: C++ and garbage collection (long, but interesting :->) Message-ID: <-283749997@hpcupt1.HP.COM> Date: 2 Oct 90 19:36:27 GMT References: Organization: Hewlett Packard, Cupertino Lines: 37 / hpcupt1:comp.object / chased@rbbb.Eng.Sun.COM (David Chase) / 5:35 pm Oct 1, 1990 / >Can you elaborate on this somewhat? Is this a compacting collector, >a non-compacting collector, or a conservatively (Bartlett-style) >compacting collector? Do you believe that your code is safe in a >preemptively scheduled multi-threaded system (if you don't say >"volatile" somewhere, I'll claim that it isn't.) Do you deal with the >full language, or do you impose restructions on casting or use of >reference parameters (operations that can generate internal offset >pointers). It's a non-compacting collector. It is not conservative. The code is not safe in a multi-threaded system unless some locks or semaphores are used. I imagine there are some critical sections in the GC code. I have not looked at adapting the GC code in a multi-threaded system yet. I impose restrictions on the programmer to use my pointer ADT only. This way, every GC pointer reference in the system can be tracked. GC operations are hidden in ADTs, the implementation does not use pointer tricks, or scanning of stack space. So the implementation will continue to work independent of any compiler change. The disadventage with this collector is that you have to re-write code to use the pointer ADT. You can mail the library for a thesis request information. California Polytechnic University Library San Luis Obispo, CA 93407 USA "The 'MM' Garbage Collector for C++", master thesis, computer science, 1989. -Thomas Wang (Everything is an object.) wang@hpdmsjlm.cup.hp.com thomasw@hpcupt1.cup.hp.com