This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

GUILE's GC - why we struggling to solve already solved problems ? (was Re: finding the top of the stack in linux)


17-Jul-00 15:33 you wrote:

> Wouldn't it be much easier to require that the GUILE initialization
> function is passed a pointer to argc?

If you have access to such pointer then probably you can access to main() as
well. For true embeddable language it's important to work with EXISTING
binary-only interface (like apache modules interface). But why the hell we
are inventing our own GC with a lot of limitations and not even using clearly
appropriate parts (like stack placement finding subroitine) from ALREADY
existing and TESTED solutions. Why to reinvent the wheel ? What's
wrong with Boehm's GC ? It's fast (usually), it handles circular structures,
it can be used with C/C++ programs with minimal care (I've used it in
"malloc-replacement mode" to make Netscape less memory hundgry, for example;
even without sources for Netscape!), it does not require changes in main()
and it works with threads (6.0alpha version even can use multiple processors
to speedup garbage colletion itself) while current Guile's GC with threads
will be nightmare (or must you do usual main() trick with pthread_create()
as well ? With EACH AND EVERY THREAD created in program ? Gosh). Oh, and it's
copyright is REAL unrestrictive:
-- cut --
Copyright 1988, 1989 Hans-J. Boehm, Alan J. Demers
Copyright (c) 1991-1996 by Xerox Corporation.  All rights reserved.
Copyright (c) 1996-1999 by Silicon Graphics.  All rights reserved.
Copyright (c) 1999 by Hewlett-Packard Company. All rights reserved.

THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED
OR IMPLIED.  ANY USE IS AT YOUR OWN RISK.

Permission is hereby granted to use or copy this program
for any purpose,  provided the above notices are retained on all copies.
Permission to modify the code and to distribute modified code is granted,
provided the above notices are retained, and a notice that the code was
modified is included with the above copyright notice.
-- cut --
Looks compatible with GPL to me. Even if we can not use full GC (why?) we
still can use parts of it to determine stack placement on different systems.

Portability ?
-- cut --
The collector is not completely portable, but the distribution
includes ports to most standard PC and UNIX platforms. Win32, win32s,
OS/2, and UNIX environments are supported on Intel-based PCs, as are
all common UNIX workstations, MacOS, and AmigaDOS. Some ports are more
polished than others.

Irix pthreads, Linux threads, Solaris threads (old style and pthreads)
and PPCR threads are supported in the most recent versions, though
this version of the collector itself is only active in one thread at a
time. Win32 thread support appears to be getting more solid in the
most recent versions.
-- cut --

PLEASE take look on http://www.hpl.hp.com/personal/Hans_Boehm/gc/ and
say what's wrong with Boehm's GC and why we need to reinvent the wheel
duplicationg few man-years of reserach.

P.S. Boehm's GC is used by libgcj (library for GNU Compiler for Java - GCJ).




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]