eh@astbe.UUCP (H.Dr.Ehling) (06/25/89)
As Subject is mentioned permanently in the garbage collection
discussion in this group -- could someone please mail me a pointer to a
UUCP accessible source of that programm ?
Many Thanks,
Juergen Ehling
--
Hans-Juergen Ehling | Europe: eh@astbe.uucp, USA: ...!pyramid!tub!astbe!eh
| Voice: +49 30/828-2497 Fax: +49 30/828-2483
GEI Software-Technik, Hohenzollerndamm 150, D1000 Berlin 33, FRGbeard@ux1.lbl.gov (Patrick C Beard) (06/26/89)
Me too! I would really like to see this. __________________ Patrick Beard PCBeard@lbl.gov BSI, Berkeley, CA ___________________
boehm@flora.rice.edu (Hans Boehm) (06/28/89)
The garbage collector has been sent for posting to comp.sources.unix.
I do not know where it is in that queue. In the meantime it can be obtained
by anonymous ftp from
titan.rice.edu:~ftp/public/gc.shar.0[12]
or by sending the following two messages to archive-server@rice.edu:
send public gc.shar.01
send public gc.shar.02
I believe the problem that Jim Adcock recently wrote about is tracable
to essentially infinite recursion in the program itself. The collector
happened to be the piece of code that actually exceeded the stack limit.
(I'm sure lots of people will correct me if I'm wrong ...)
The collector is not completely portable, though it comes reasonably close,
at least for machines with 32 bit pointers. You do still need to specify
constants like the starting address of the stack,
and a few others. On some machines you need to specify a few lines of
assembly code to mark from certain registers. It currently runs on
VAXen, some HP machines, SUNs, PC/RTs, MIPS M/120s and a few others.
The approach does work much better in sparsely populated address spaces.
It works fine on an 80386 based Sequent machine. I suspect it won't work
very well in an MS-DOS environment with 16 bit pointers. (As distributed,
it won't work at all in this environment, for several reasons.)
There are currently no hooks for invoking destructors or the like. All
that is supplied are malloc and free replacements and a number of hooks for
performance tuning.
This collector is copyrighted, but the restrictions imposed are rather
liberal. They are not intended to prevent redistribution.
Hans-J. Boehm
boehm@rice.edujima@hplsla.HP.COM (Jim Adcock) (07/06/89)
> I believe the problem that Jim Adcock recently wrote about is tracable >to essentially infinite recursion in the program itself. The collector >happened to be the piece of code that actually exceeded the stack limit. >(I'm sure lots of people will correct me if I'm wrong ...) I also believe the problem was in my program. Sorry. [I provided more details in a previous retraction.]