[Gc] Back to "GC Stack problem on Win32"

Boehm, Hans hans.boehm at hp.com
Wed Nov 12 17:09:10 PST 2008

Ivan -

Thanks.  However, I don't think I understand the problem here correctly. The old code should in nearly all cases only invoke GC_may_be_in_stack(thread -> last_stack_min).  This should be cheap, since it only walks a page or so of the stack, right?

It seems like it would usually result in exactly one extra VirtualQuery call, as it walks off the end of the stack.  Since GC_may_be_in_stack() makes one call anyway, it seems to me that it should at most double the time spent there.

I don't like the reference to last_info in the patch, since that relies on side effects of GC_may_be_in_stack that I would like to keep as a private implementation detail of  GC_may_be_in_stack and GC_get_stack_min.  Is there a reason not to use thread -> last_stack_min instead of last_info.BaseAddress?


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Saturday, November 01, 2008 5:47 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Back to "GC Stack problem on Win32"
> Hi!
> "Boehm, Hans" <hans.boehm at hp.com wrote a week ago:
> > 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.
> >
> > 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 already pointed out some bugs.
> Now I've just run the same test (having Your patch applied)
> as I had run for my patch... And it turns out that Yours
> doesn't solve the problem as it was originally stated (to say
> more precisely, it doesn't reduce time for the first
> collection after stack growth).
> Look into the things You had advised me before:
> > 1) Initially call VirtualQuery on the sp.  If the stack
> base is in the same region, we know we're OK, and don't need
> GC_get_stack_min.  Hopefully this will be true about 100% of the time.
> So I did it for Your code now. It works.
> The patch is attached.
> Bye.

More information about the Gc mailing list