[Gc] Re: Determining alignment constraints
hans.boehm at hp.com
Tue May 9 18:07:31 PDT 2006
> > Are there other properties that it would be useful to
> export as a macro?
> Yes: the version number. Ideally, both via macro(s) and C
> symbol(s) so that one can check that the headers that were
> used correspond to the shared library at hand (zlib uses this
That's actually mostly there, but I think the header is not currently installed. See version.h in the main directory. This does result in a GC_version symbol you can check dynamically.
> > I guess my view is that you shouldn't install a nongeneric build
> > someplace where autoconf can find it. On the other hand, the
> > build-time options do seem to be useful for some applications that
> > include the library, and do not install it separately (of which we
> > currently probably have too many).
> For 7.x, are there plans to limit compile-time switches in
> order to reduce the need to bundle the library within
> application packages?
That has been a long term goal. I think it's now mostly OK, except I'm not entirely enthusiastic about some of the compromises.
A major reason the GC is bundled with gcj is that it avoids a dynamic library call on the allocation path, which would otherwise be significant. Version 7 has a hopefully more usable in-line allocation facility that I would hope would eliminate that need.
Things like GC_all_interior_pointers can already be set dynamically, though they need to be set at start up, i.e. before other GC calls, since they do alter GC data structures.
I would like to see the debugging stuff always compiled in, but that requires some more major changes, to avoid significant performance problems, and it's a slightly different problem.
gc7 does have better logging support built in by default.
Now if I could actually get to the sourceforge cvs server ...
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc