home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
- Subject: Re: Garbage Collection for C++
- Message-ID: <1992Aug16.052233.23166@ucc.su.OZ.AU>
- Sender: news@ucc.su.OZ.AU
- Nntp-Posting-Host: extro.ucc.su.oz.au
- Organization: MAXTAL P/L C/- University Computing Centre, Sydney
- References: <1992Aug13.153211.16572@ericsson.se> <1992Aug14.101226.6929@ericsson.se> <1992Aug15.005542.3104@news.mentorg.com>
- Date: Sun, 16 Aug 1992 05:22:33 GMT
- Lines: 45
-
- In article <1992Aug15.005542.3104@news.mentorg.com> bcannard@hppcb36.mentorg.com (Bob Cannard @ PCB x5565) writes:
- >
- >Reference counting suffers serious drawbacks:
- >
- >1. It can't handle cyclic data structures
- >
- >2. It is one of the most inefficient forms of garbage collection known to man.
- >
- >The main reason I'm pushing for true garbage collection is that I consider
- >reference counting (which I already have) to be an unacceptably poor solution.
-
- Mm. Reference counting used to implement 'write on demand' in
- copy contructors is supposedly inefficient. But this is not at all
- the same as reference counting for garbage collection. In copy contructors,
- you have to check the reference count before each write operation,
- and if its not 1, clone off a copy of the object. Thats slow.
-
- But for GC you only have to increment the reference count
- when you take the address of the object to form a GC pointer,
- decrement it when the pointer is destroyed, and destroy the
- object when the count goes to 0. That doesn't seem to be so slow
- to me: please correct me if I'm wrong.
-
- The basics of GC are that each object must be rooted.
- Rooted normally means accessible via a static or auto pointer,
- directly or indirectly. Non-rooted objects are garbage.
-
- The definition of rooted above is useless, however,
- in modern Windowing systems. In Windows 3 for example,
- the objects may be rooted in the operating system memory
- for a Window, typically between events the user program
- has no stack at all.
-
- In such systems we would have to be very careful using
- stack scanning garbage collectors: they would fail totally.
-
- Interestingly, objects allocated under Windows
- are already subject to automatic compaction, and even garbage
- collection on a task by task basis.
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-