[Gc] GC crash on OSX 10.3.1 (7C103)
Tue, 11 Nov 2003 16:17:04 -0800
I hadn't fully appreciated what you're trying to do. You're loading
a library using our GC into a Java application running on a Sun-based
In general this is pretty hairy, and I would avoid it if there are
other feasible solutions. (I assume gcj won't work? A separate process? When it comes
to garbage collectors, two is a crowd.)
Other issues that may have to be addressed:
1) Depending on the platform and whether you explicitly tell it to or not,
our collector may want to trace the Java heap. This may be essential to
avoid dropping objects. Or it may be bad for performance. Or both.
2) If you do allow references from the Java heap, cycles crossing both GC heaps
can't really be reclaimed.
3) I haven't thought about deadlock issues if both collectors try to stop
the world to GC at the same time.
As far as thread stacks are concerned, as Brian pointed out, our collector
somehow needs to know about all thread stacks that may reference the collected heap.
On win32 there are the beginnings of an API for "attaching" threads after the fact.
It would be relatively easy to do the same on Posix platforms. (Up until now,
it was less necessary there.) But each relevant
thread would need to make an explicit call, and would need to get a pointer to
the "base" of the stack. (This doesn't need to be the real base, so long as
there are no pointers to the GC heap below it.)
> -----Original Message-----
From: email@example.com [mailto:firstname.lastname@example.org]On
Behalf Of Andrew Begel
Sent: Monday, November 10, 2003 10:49 PM
And now I've narrowed down the bug to the logic failure. The=20
GC_thr_init() function in pthread_support.c assumes it is running from=20
the main thread, maybe even before other threads are created. However,=20
when I link my library into a running Java image, it is certainly not=20
the main thread, and I can't control how many other threads have been=20
created already. And I can't even promise not to use the GC on those=20
other threads because I don't have control over which thread Java will=20
execute my code in.
This feels like a design impasse. Any ideas?