[Gc] Using the GC w/ common x86 compilers.

Andrew Haley aph at redhat.com
Tue Jul 24 10:19:30 PDT 2007


Dave writes:
 > Bruce Hoult wrote:
 > > On 7/24/07, Dave <davejf at frontiernet.net> wrote:
 > >> - Are there any known compiler optimization issues that break the GC
 > >> with any of the above?
 > >> - Do any of them (by default) align pointers and/or pack struct / class
 > >> pointer members such that it would break the GC?
 > >
 > > If they do, all you have to do is detect that compiler in
 > > include/private/gcconfig.h and  #define ALIGNMENT 1 (or whatever it
 > > is).
 > >
 > > It will make scanning several times slower and increase the chance of
 > > false positives, but it will work.
 > 
 > Thank you. My understanding is that since alignment and packing have 
 > both performance and ABI consequences, most all contemporary compilers 
 > will "follow the leader" and fortunately MSVC and GCC seem to "do the 
 > right thing" <g>
 > 
 > How about the compiler optimization issue (where the optimization
 > 'hides' a pointer into the GC heap)? That actually worries me more
 > because bugs would be really tough to isolate and recreate. I've
 > read Dr. Boehm's papers on this, but IIUC the point is made that
 > it's generally not a concern for 'normal' code. Just wondering if
 > anyone has any experience or examples regarding this issue
 > (especially but not limited to x86 compilers)?

I'm not aware of any optimization algorithms used by gcc that might do
this.  It is, perhaps, possible that the compiler might try to save a
register if the difference between two pointers is a constant, but in
that case both pointers would point to the same object.  If there
really was a problem I think we'd know by now, and I do try to keep a
watchful eye on gcc progress.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903


More information about the Gc mailing list