[Gc] Questions about threads with GC 6.8
jim.marshall at wbemsolutions.com
Tue Jul 3 21:01:33 PDT 2007
jim marshall wrote:
> First let me say I appreciate everyones help thus far in my journey to
> optimize our app using the GC! The results have been very good so far.
> Let me just outline our process. Our program is a server which
> dynamically loads shared objects from 3rd parties. Our core
> application uses the GC, and all the interfaces the shared objects use
> to communicate with us will use the GC (as they make up-calls to
> allocate objects they have to return to us). However; there is nothing
> preventing these shared objects from allocating memory on their own
> using the normal CRT malloc/free (we are very careful to not mix this
> memory with our memory). It is also possible for the shared objects to
> create their own threads to do background work.
> Currently our server is mostly single threaded, by that I mean we
> start a few 'services' in threads, which run in the background to
> monitor stuff but they mostly sit idle (they all use GC memory). We
> have one secondary thread which listens for requests from a client and
> then loads the shared object required. Right now this is the only
> thread that does this (e.g. only one client can talk to us at a time).
> We will be changing this behavior in the near future to allow multiple
> clients to communicate with us, each using their own thread.
> So I have a few questions about some flags and documentation I have
> been reading.
> 1 - https://www.hpl.hp.com/personal/Hans_Boehm/gc/simple_example.html
> This page shows using the following configure options for threaded
> apps "--enable-threads=posix --enable-thread-local-alloc
> --enable-parallel-mark" . It is unclear to me if these options are for
> the 7.0 alpha or also apply to 6.8 (The GC compiles and seems to work
> with these options n 6.8), however; the real question is, if this is
> valid for 6.8 should these options (sans posix threads) be enabled on
> Windows? If so what are the defines that need to be added to the
> 2 - On that same page it suggests using:
>> #define GC_REDIRECT_TO_LOCAL
>> #include "gc_local_alloc.h"
> Does this make sense for our application?
> 3 - REGISTER_LIBRARIES_EARLY
> What is this option and what does it do (I looked at mark_rts,c but it
> doesn't seem to do that much)? Previously I sent an email about a
> potential deadlock, when we compiled the Windows GC with this defined
> that hang seems to have gone away. But we don't really understand what
> it does. The weird thing is that the private/gcconfig.h says this
> option should be avoided on Win32 so I am very confused by it fixing
> our problem.
Probably should wait until this week is over as a lot of companies go on
vacation for July 4th, but I'll try again.
I don't really need a response for questions 1 & 2, but #3 is kind of
important to us so we can try and understand what is happening.
Basically without the above option we end up with one thread (which uses
malloc/free directly) owning the CRT heap lock, and then the GC stopping
the world and then getting stuck waiting for the CRT heap lock (as a
side note: this only happens on Windows)
here is a stack trace, this is just one example as it is completely
1) This is the thread that owns the _heap_lock. wcsftime is a CRT
function which is allocating memory
for the formatted date string; is uses malloc_crt()
2) This is the gc thread that initiates the world stop. Its waiting for
the heap lock but since the world is stopped and the first thread owns
the _heap_lock so the GC is basically deadlocked here.
_nh_malloc_dbg(unsigned int 8, int 0, int 1, const char * 0x00000000,
int 0) line 242 + 7 bytes
malloc(unsigned int 8) line 130 + 21 bytes
GC_add_current_malloc_heap() line 1265 + 8 bytes
GC_is_heap_base(char * 0x00010000) line 1307
GC_register_dynamic_libraries() line 896 + 30 bytes
> Again thanks for your perseverance and help!
Sr. Staff Engineer
WBEM Solutions, Inc.
More information about the Gc