[Gc] GC7.0

Jim Marshall jim.marshall at wbemsolutions.com
Mon Jul 9 16:41:18 PDT 2007


Boehm, Hans wrote:
> Thanks.  These look uncontroversial to me.  I put them in my source
> trees, and will check them in after I get a chance to test on Windows.
>
> I have now been testing with Visual Studio 2005, though I have not fixed
> all warnings that arose from that switch.  I did try to fix the those
> were the new warnings seemed to me to be clearly correct and unlikely to
> break builds on older versions.  I obviously missed in at least one
> case.
>   
Well you can't be expected to support old compiler versions forever, 
VS2005 is probably the standard Windows development platform now. We 
just haven't made the move yet, so it made sense to figure out if we 
could fix it.

Thanks for incorporating the changes.
-Jim
> Hans
>
>   
>> -----Original Message-----
>> From: jim marshall [mailto:jim.marshall at wbemsolutions.com] 
>> Sent: Tuesday, July 03, 2007 9:30 AM
>> To: Boehm, Hans
>> Cc: gc at napali.hpl.hp.com
>> Subject: Re: [Gc] GC7.0
>>
>> I could not get GC 7.0 to compile with VC 6. With the help of 
>> a co-worker we came up with the following changes to 3 files
>>
>> include/gc.h
>> msvc_dbg.c
>> libatomic_ops-1.2/src/atomic_ops/sysdeps/msftc/x86.h
>>
>> This allowed us to compile the gc (gctest would not compile 
>> due to an unresolved external) and cords compiled fine.
>>
>> I have not tested the resulting dll, so I do not know if it 
>> works or not
>> - sorry
>>
>> Hope this helps someone else.
>> Jim
>>
>> p.s.
>>  Here is the error with gctest with VC6
>>
>> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
>> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
>>
>>         link.exe @C:\DOCUME~1\jmars\LOCALS~1\Temp\nma07064.
>> test.obj : error LNK2001: unresolved external symbol 
>> _GC_lock_holder Debug/gctest.exe : fatal error LNK1120: 1 
>> unresolved externals NMAKE : fatal error U1077: 'link.exe' : 
>> return code '0x460'
>> Stop.
>>
>> Boehm, Hans wrote:
>>     
>>> I finally made gc version 7.0 available as
>>>
>>> http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.0.tar.gz
>>>
>>> (Note the hyphen; the naming convention changed slightly.)
>>>
>>> The CVS tree is now labelled as 7.1alpha1.
>>>
>>> I tested this on some of the most common platforms (various Linux, 
>>> Windows versions, Solaris, HP/UX, MacOS X).  I did not get 
>>>       
>> a chance to 
>>     
>>> test on AIX or Irix.
>>>
>>> There has been a report that this does not build on MacOS 
>>>       
>> 10.3.9, but 
>>     
>>> it seems to work on most other MacOS X versions.
>>>
>>> The Cygwin port does not support dynamic libraries.  
>>>       
>> (Neither did 6.8, 
>>     
>>> but the documentation is now more clear about that.  I suspect this 
>>> actually isn't hard to fix.)
>>>
>>> Changes relative to 6.8 include, in no particular order:
>>>
>>>  - Change C code to require at least C89.  Clean up code in various 
>>> outher
>>>    respects.
>>>  - Win64 port.
>>>  - Always count how much live data there is in the heap.  Add more
>>>    robust heap expansion heuristic which relies on this.
>>>  - Remove old-style Solaris threads support and some other obsolete
>>>    platform support.
>>>  - Restructure mark code, hopefull resulting in some performance 
>>> improvements.
>>>  - Change the GC code to traffic mostly in either bytes or 
>>>       
>> allocation
>>     
>>>    granules, not words, internally.
>>>  - Provide for fast inline allocation that requires less 
>>>       
>> frequent client
>>     
>>>    recompilations.  (Needs more testing.)
>>>  - Removed SILENT configuration macro and PRINTSTATS and GATHERSTATS
>>>    macros.  Control is now via GC_PRINT_STATS and 
>>>       
>> GC_PRINT_VERBOSE_STATS
>>     
>>>    encironment variables.
>>>  - Thread local allocation is now performed without needing to call
>>>    special allocation functions.  The configuration macro 
>>> THREAD_LOCAL_ALLOC
>>>    continues to determine whether this is supported.
>>>  - Thread local allocation is supported on more platforms.
>>>  - Win32 threads code was rewritten and is hopefully more sane.
>>>  - Allocation routines now decide whether to lock 
>>>       
>> dynamically, based on
>>     
>>>    whether a second thread has been created.
>>>  - Mostly untested support for a compiler write barrier.
>>>  - Use libatomic_ops for atomic operations.
>>>  - Limited support for malloc redirection with Linux 
>>>       
>> threads (& NPTL ).
>>     
>>>  - Various bug fixes and some new platform support.
>>>
>>> Hans
>>>
>>> _______________________________________________
>>> Gc mailing list
>>> Gc at linux.hpl.hp.com
>>> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>>>
>>>
>>>
>>>   
>>>       
>> --
>> Jim Marshall
>> Sr. Staff Engineer
>> WBEM Solutions, Inc.
>> 978-947-3607
>>
>>
>>     
>
>
>
>   


More information about the Gc mailing list