[Gc] Platform Idiosyncrasies
hans.boehm at hp.com
Tue Jun 7 16:57:48 PDT 2005
I don't believe there is a document listing platform idiosyncracies.
The ones that immediately occur to me:
1. You probably shouldn't rely on correct scanning of thread-local data
on any platform. If you need thread-local data to point directly to
collectable memory, also have it referenced from elsewhere.
2. There is no portable way to register threads after the fact. For
win32, there is sort of a hook to do that. This is improving in 7.0
3. Under win32, there is still some risk that malloced memory will be
treated as roots, though that's gotten smaller. (That's actually not
necessarily a bad thing, but consistency across platforms seems more
4. Win32 thread support has some other idiosyncracies.
5. Support of incremental and parallel GC is platform-specific. It is
platform specific whether incremental GC write-protects pointer-free
objects (which matters for some otherwise desirable usage patterns).
6. Support for thread-local allocation is platform-specific.
NPTL threads should be fine.
From: gc-bounces at napali.hpl.hp.com [mailto:gc-bounces at napali.hpl.hp.com]
On Behalf Of Nye, Jason
Sent: Friday, June 03, 2005 7:34 AM
To: gc at napali.hpl.hp.com
Subject: [Gc] Platform Idiosyncrasies
I am very interested in using your garbage collector for all further
C/C++ development at my company. I am trying to learn as much about it
as possible for evaluation purposes. Is there a document or collection
of documents that summarize(s) the platform idiosynchrasies (as one
example, whether scanning thread-specific data is supported on a
specific platform or not).
Also, is the garbage collector updated to support the new native
threading library for Linux 2.6x?
Thanks in advance!
More information about the Gc