[Gc] Re[4]: Patch for "GC stack problem on Win32"

Ivan Maidanski ivmai at mail.ru
Sat Oct 25 14:30:09 PDT 2008


Hi!

"Boehm, Hans" <hans.boehm at hp.com> wrote:

> Thanks.
> 
> I finally checked in the attached patch, which is loosely based on yours.  I retained the simpler interface for GC_get_stack_min, but added GC_may_be_in_stack as a separate function.  I also simplified GC_get_next_stack.  And I think the thread pushing code could fail for more cases than the original, so I changed that, too.  I think the basic algorithm is the same as what you had.

I've compare Your solution against old mine one.
Two bugs found in Your's one:
- wrong actual params order for GC_get_next_stack() call in GC_get_next_stack() (dyn_load.c file) - see proto;
- no definition of GC_may_be_in_stack() for MSWINCE target.

And one performance drawback found:
- VirtualQuery() is called first in GC_may_be_in_stack() and, if successful, immediately called again with same args in GC_get_stack_min() (in fact, under normal conditions (when last_stack_min is rarely changed) - You double the amount of VirtualQuery() invocations when the world is stopped against my suggested solution).

The rest things are ok.

> 
> So far, this has only been minimally tested under Cygwin.  I'd appreciate if someone could test more thoroughly, and verify that it also still solves the original problem.

I've tested it (minimally too) long ago but with my patch.

I have another trouble with test.c on cygwin - it deadlocks sometimes if compiled with GC_THREADS (regardless of THREAD_LOCAL_ALLOC, PARALLEL_MARK, USE_MMAP). I've failed to figure out anything about it (because gdb can't do "bt" well for threads interrupted in a system call).

> 
> This patch also includes some build-time junk that I needed for a Cygwin build in a directory with blanks in the path name.  That's separable, and can be ignored, if you prefer.
> 
> Hans
> 

Bye.




More information about the Gc mailing list