[Gc] RE: VC++ build files

Hans Boehm Hans.Boehm at hp.com
Mon Jun 30 21:10:52 PDT 2008

On Tue, 1 Jul 2008, DrPizza wrote:

>> The current Windows Makefiles are not in great shape.
>> The problem with project files is that they're a single platform,
>> completely nonportable, solution.  They tend to be hard to edit for
>> anyone not on a Windows platform.  And we've been short a volunteer to
>> maintain them.  Certainly updated versions would be appreciated, but
>> they tend to deteriorate to a basis for a do-it-yourself project in the
>> absence of a maintainer.
> I think all of that is true of the nmake Makefiles too, isn't it?  And 
> nmake has the disadvantage that no-one really uses it anyway these days. 
> My feeling was that at least by having a project file, it would be 
> somewhat more approachable.
I agree that new peoject files would be good.

>From my perspective,
nmake has the big advantage that the Makefiles are editable on another
platform.  The syntax at least is more or less compatible with other make
implementations, which are ubiquitous.  The commandline options aren't,
but that's easier to live with.

>>> DLL builds:    GC_DLL
>>> Static builds: GC_NOT_DLL,
>>>                THREAD_LOCAL_ALLOC
>> That's an interesting and unfortunate tradeoff.  I would expect
>> THREAD_LOCAL_ALLOC to be appreciably faster.  But it doesn't work with
>> DllMain-based implicit thread registration.  If you know that all
>> clients will be using the normal portable GC interface, I'd recommend
>> turning on THREAD_LOCAL_ALLOC for DLL builds, though that may not have
>> been well tested.
> I wasn't sure about this one.  It felt safer to me to use DllMain-based 
> registration, just because it feels more "automatic"; you link against 
> the library and it does (more or less) the Right Thing.  Is there any 
> kind of a benchmark that would make a case one way or the other?
I think even just allocating small objects (e.g. 32 bytes) in a tight loop 
would give you some idea.  I haven't measured this carefully on Windows.
On Linux, the lock acquisition per object is a big deal.  My impression is 
that Windows CriticalSections are no cheaper.  It's probably more of an 
issue on P4s than it is on more modern processors.
> OK.  IS the best way to proceed to figure out how to generate a patch 
> and then send it to the mailing list?
That works.

> Peter

More information about the Gc mailing list