Re: [Gc] Back to "GC Stack problem on Win32" - refinement
ivmai at mail.ru
Tue Mar 3 08:08:17 PST 2009
"Boehm, Hans" <hans.boehm at hp.com> wrote:
> Thanks. I committed something very similar to that patch for now. All indications so far are that my problems are unrelated to the patch.
> I'll see if I can track down what's going on. It may be a GetWriteWatch issue with incremental GC.
> > Subject: Re: [Gc] Back to "GC Stack problem on Win32" - refinement
> > Hi!
> > "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > > I've had a patch (attached, against CVS) in my tree for a
> > while that I
> > > think started with Ivan's diff36 and diff37, and then made
> > yet another
> > > attempt to restructure the surrounding code. (Diff36 and
> > diff37 are
> > > Ivan's originals.)
> > > ...
> > > Hans
Some issues on GC_push_stack_for().
First, please add parenthesis (around "&&") to newly-added GC_ASSERT() to suppress compiler warning about the order of "||" and "&&" operations.
Question 1: Why did You reject this portion of code (in the "else" branch of "if (sp < thread -> stack_base && sp >= thread -> last_stack_min)")?
/* In the current thread it is always safe to use sp value. */
if (GC_may_be_in_stack(thread -> id == me &&
sp < thread -> last_stack_min ?
sp : thread -> last_stack_min)) ...
Question 2: And why did You reject the successive portion of code?
stack_min = last_info.BaseAddress;
/* Do not probe rest of the stack if sp is correct. */
if (sp < stack_min || sp >= thread->stack_base)
stack_min = GC_get_stack_min(thread -> last_stack_min);
Both of these code portions can shorten world-stopped time in some situations (but rare, of course) as in the test case I've posted in this thread.
One issue on GC_get_next_stack():
*lo = GC_get_stack_min(current_min-1)
I think we should not substract 1 here (eg., for case when GC_get_stack_min(current_min) == current_min). Not sure this changes something in practice, but...
More information about the Gc