This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: robustness vs. conservative GC




   Date: Mon, 30 Jul 2001 16:32:06 +1000
   From: Fergus Henderson <fjh@cs.mu.oz.au>
   Cc: gcc@gcc.gnu.org
   Content-Type: text/plain; charset=us-ascii
   X-UIDL: e8e3cb5701bee9b31576f77c80077cf4

   On 30-Jul-2001, Tom Lord <lord@regexps.com> wrote:
   > 
   > 2. In the face of an aggressively optimizing C compiler, one that
   >    sometimes disguises pointers, conservative GC can fail to protect
   >    some live objects, resulting in program failures.  This is a 
   >    famous limitation of conservative GC.
   > 
   >    Sticking to a specific compiler and options known not to disguise
   >    pointers avoids the bug, but is a fragile solution.

   I agree.  It would be better to have a specific compiler option, called say
   `-fdont-hide-pointers' or `-fconservative-gc', which guarantees that the
   compiler won't perform any such optimizations.

   Does anyone know of any current GCC optimizations which might hide pointers?

   > In my experience, both bugs (#1 and #2) are likely to eventually show
   > up in deployed systems,

   If you have specific experience of #2 occurring in deployed systems,
   I'd be interested in hearing about that.

   > Fergus Henderson made the claim that an exact GC implemented without
   > compiler support is likely to perform worse than one implemented with
   > compiler support.  I don't know what "likely" means in that claim, but
   > I don't see any a priori reason to believe there will necessarily be
   > performance problems.

   Any scheme for doing exact GC without cooperation from the compiler
   back-end needs to store pointers in a known location on the stack, rather
   than in registers, so that they can be updated when objects are moved.
   This denies the back-end compiler freedom to put such pointers in
   registers.  Register allocation obviously has a big effect on performance.

   That's my a priori reason.

   -- 
   Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
   The University of Melbourne         |  of excellence is a lethal habit"
   WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]