[Gc] Fix for Win32 PARALLEL_MARK

Hans Boehm Hans.Boehm at hp.com
Wed Nov 12 08:32:54 PST 2008

On Wed, 12 Nov 2008, Ivan Maidanski wrote:

> Hi!
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
>> 1) I think we need a definition of AO_ASSUME_WINDOWS98 if we're on 
>> Windows and PARALLEL_MARK is defined.  Otherwise we get a correct 
>> complaint that CAS isn't available.
> -DAO_ASSUME_WINDOWS98 should be added to VC++ build scripts only. I 
> don't think it's correct to add it to some header file.
I'd be inclined to define it in gcconfig.h when PARALLEL_MARK is defined.
I think mark.c still needs compare_and_swap, so we would have to
document that the PARALLEL_MARK version doesn't work on Windows 95,
which seems OK.  My impression is that this is not compiler specific?
It's a question of a missing routine in the runtime library for cmpxchg?
Thus it doesn't seem right to handle this in a VC++ script?

>> 2) I'm seeing a failure on win64 with PARALLEL_MARK that I haven't 
>> debugged.  Is that still expected?
> I've never expected it. Are You talking about "Unexpected heap growth"? 
> If not, tell me the failure detailed info.
I think it was something else.  I'll debug.
>> Should configure.ac be updated to handle --enable-parallel-mark for cygwin?
> Yes. It works (but not tested too much). The algorithm is really same for pthread_support.
>> More below:
>>> Still some questions remain:
>>> - should we scan markers in GC_get_next_stack()?;
>> I think so.  This is used to skip thread stacks.  And we certainly 
>> don't want to mark the marker thread stacks.
> Ok. I'll do it.
>>> - should we use .._full() version (or weaker) of CAS in
>>> GC_acquire_mark_lock()?
>> I think you want to use _acquire versions whenever this is used to 
>> acquire a lock, and _release in GC_release_mark_lock.  I did not study 
>> the logic there carefully enough to claim that it is correct.  But I 
>> also didn't immediately see any problems.  Mark_mutex_event is set up 
>> so that signaling it is remembered, even if there are currently no 
>> waiters, right?
> At present, I don't use CAS anymore. As for inc/dec, their 
> release/acquire versions are redirected to full version in libatomics 
> for msvc/gcc x86/amd64, so let me leave it as is.
Yes.  But eventually someone will use this code with either win64 on 
Itanium or WinCE on ARM, where it will matter.  I can fix it if you like.
>> One minor issue is that I would like to see corrected is that the 
>> statistics variables should also be accessed through AO_ operations. 
>> Otherwise it's very hard to tell whether they're trustworthy.  You can 
>> easily get into situations in which such counters are off by a factor 
>> of two or more due to contention.  I've been bitten by this.  (...)
> I'll do it here and for pthread_support too.


More information about the Gc mailing list