[Gc] Re: Win32 hang with MPROTECT_VDB
hans.boehm at hp.com
Fri May 22 11:08:22 PDT 2009
I fixed the ChangeLog. I didn't fix the check-in message, mostly because it would involve my figuring out how to do so.
Your patch generally looks fine, but I'll try to check in some earlier patches first. I suspect this wouldn't apply as is since the line numbers are way off.
The answer to question 3 is no, so that part is OK as is. In fact, for a normal X86 configuration, I believe pointer-free blocks should not be protected either, so an alternate patch might have been to make the thread descriptors pointer-free and to explicitly trace them. But that depends on page and hblk sizes being the same, which makes it a bit brittle, so I decided to go with this approach instead.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Thursday, May 21, 2009 11:53 PM
> To: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Re: Win32 hang with MPROTECT_VDB
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > I just checked in a patch to os_dep.c and win32_threads.c.
> This appears to fix the MPROTECT_VDB problem, leaving the
> potential GWW_VDB issue, which is unfortunately far harder to
> 1. ChangeLog:
> 2009-05-21 Hans Boehm <Hans.Boehm at hp.com> (really Ivan Maidanski)
> -> ;)
> 2009-05-21 Hans Boehm <Hans.Boehm at hp.com> (really Hans Boehm)
> 2. win32_threads.c: GC_start_world():
> UNPROTECT(t) should also be added for GC_win32_dll_threads case.
> 3. Q: should we unprotect also non-heap pages (eg. before
> changing last_info, marker_last_stack_min)?
> 4. win32_threads.c: GC_get_next_stack():
> UNPROTECT(some_t) should also be added for (see the patch in
> my next post):
> /* Remember current stack_min value. */
> *plast_stack_min = *lo;
> > Hans
> > > -----Original Message-----
> > > ...
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc