=================================================================== RCS file: /home/cvs/OpenXM_contrib2/asir2000/gc/README.QUICK,v retrieving revision 1.2 retrieving revision 1.3 diff -u -p -r1.2 -r1.3 --- OpenXM_contrib2/asir2000/gc/README.QUICK 2000/04/10 08:31:30 1.2 +++ OpenXM_contrib2/asir2000/gc/README.QUICK 2001/04/20 07:39:18 1.3 @@ -1,7 +1,7 @@ Copyright 1988, 1989 Hans-J. Boehm, Alan J. Demers Copyright (c) 1991-1995 by Xerox Corporation. All rights reserved. Copyright (c) 1996-1999 by Silicon Graphics. All rights reserved. -Copyright (c) 1999 by Hewlett-Packard. All rights reserved. +Copyright (c) 1999-2000 by Hewlett-Packard. All rights reserved. THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED OR IMPLIED. ANY USE IS AT YOUR OWN RISK. @@ -12,32 +12,59 @@ Permission to modify the code and to distribute modifi provided the above notices are retained, and a notice that the code was modified is included with the above copyright notice. - For more details and the names of other contributors, see the -README file and gc.h. This file describes typical use of +doc/README* files and include/gc.h. This file describes typical use of the collector on a machine that is already supported. +For the version number, see doc/README or version.h. + INSTALLATION: -Under UN*X, type "make test". Under OS/2 or Windows NT, copy the -appropriate makefile to MAKEFILE, read it, and type "nmake test". -Read the machine specific README if one exists. The only way to -develop code with the collector for Windows 3.1 is to develop under -Windows NT, and then to use win32S. +Under UN*X, type "make test". Under OS/2 or Windows 95, 98, Me, NT, or 2000, +copy the appropriate makefile to MAKEFILE, read it, and type "nmake test". +(Under Windows, this assumes you have Microsoft command-line tools +installed, and have DOS configured with enough environment space to run them.) +Read the machine specific README in the doc directory if one exists. +The only way to develop code with the collector for Windows 3.1 is +to develop under Windows NT or 95+, and then to use win32S. -If you wish to use the cord (structured string) library type +If you need thread support, you will need to either follow the special +platform-dependent instructions (win32), or add a suitable define +option as described in Makefile. + +If you wish to use the cord (structured string) library, type "make cords". (This requires an ANSI C compiler. You may need -to redefine CC in the Makefile.) +to redefine CC in the Makefile. The CORD_printf implementation in +cordprnt.c is known to be less than perfectly portable. The rest +of the package should still work.) If you wish to use the collector from C++, type "make c++". These add further files to gc.a and to the include -subdirectory. See cord/cord.h and gc_c++.h. +subdirectory. See cord/cord.h and include/gc_cpp.h. TYPICAL USE: -Include "gc.h" from this directory. Link against the appropriate library -("gc.a" under UN*X). Replace calls to malloc by calls to GC_MALLOC, -and calls to realloc by calls to GC_REALLOC. If the object is known -to never contain pointers, use GC_MALLOC_ATOMIC instead of -GC_MALLOC. +Include "gc.h" from the include subdirectory. Link against the +appropriate library ("gc.a" under UN*X). Replace calls to malloc +by calls to GC_MALLOC, and calls to realloc by calls to GC_REALLOC. +If the object is known to never contain pointers, use GC_MALLOC_ATOMIC +instead of GC_MALLOC. Define GC_DEBUG before including gc.h for additional checking. + +More documentation on the collector interface can be found at +http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html, +in doc/README, and in include/gc.h . + +WARNINGS: + +Do not store the only pointer to an object in memory allocated +with system malloc, since the collector usually does not scan +memory allocated in this way. + +Use with threads may be supported on your system, but requires the +collector to be built with thread support. See Makefile. The collector +does not guarantee to scan thread-local storage (e.g. of the kind +accessed with pthread_getspecific()). The collector does scan +thread stacks though, so generally the best solution is to ensure that +any pointers stored in thread-local storage are also stored on the +thread's stack for the duration of their lifetime.