[Gc] Fix for Win32 PARALLEL_MARK
Hans.Boehm at hp.com
Wed Nov 12 08:32:54 PST 2008
On Wed, 12 Nov 2008, Ivan Maidanski wrote:
> "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
>> 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