This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: debugging threads vs processes
- To: "'tromey at redhat dot com'" <tromey at redhat dot com>, Jeff Sturm <jsturm at one-point dot com>
- Subject: RE: debugging threads vs processes
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Fri, 13 Jul 2001 09:25:53 -0700
- Cc: Per Bothner <per at bothner dot com>, java-discuss at sources dot redhat dot com
> From: Tom Tromey [mailto:tromey@redhat.com]
> It might be worse than that. boehm-gc overrides various pthread_*
> functions so that it can keep track of what is going on. Apache might
> need to be recompiled so that it calls these functions. At least, if
> Apache uses threads and if it can create new threads that use libgcj
> without notifying the GC. This is all platform dependent. Offhand I
> don't know which platforms use overrides and which use other methods.
>
On Unix-like platforms it uses overrides implemented with macros in gc.h.
With GNU ld, the collector should also be able to implement the overrides
with --wrap instead of using macro definitions. This might make it
unnecessary to recompile other code in situations like this, but I don't
think the libgcj build process currently supports it. Nor has it received a
lot of testing.
Any threads created without the wrapper for pthread_create will not be
stopped, not will the corresponding stack be scanned by the gc. There may
be other issues if they are, for example, joined by a thread the gc knows
about.
With win32 threads, DllMain is used to watch for new threads. That
mechanism seems to work unless there are threads already running when the
collector dll is loaded.
Hans