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]
Other format:	[Raw text]

Re: [Fwd: Uninitialized stack gaps and conservative garbage collection]

From: Raymond Toy <rtoy at earthlink dot net>
To: Camm Maguire <camm at enhanced dot com>
Cc: Bryce McKinlay <mckinlay at redhat dot com>, gcc at gcc dot gnu dot org, Ranjit Mathew <rmathew at gmail dot com>, java at gcc dot gnu dot org
Date: Wed, 01 Jun 2005 21:55:24 -0400
Subject: Re: [Fwd: Uninitialized stack gaps and conservative garbage collection]
Newsgroups: gmane.comp.gcc.devel, gmane.lisp.gcl.devel, gmane.comp.gcc.java.devel
References: <65953E8166311641A685BDF71D8658262B6FB0@cacexc12.americas.cpqcorp.net> <54k6lkda3g.fsf@intech19.enhanced.com>

Camm Maguire wrote:

Raymond Toy writes:

On the sparc port, this area can be zeroed out with appropriate
optimization settings.  I ran some tests using Eric Marsden's
cl-bench.   If the stack is always cleared, the cost of some
benchmarks go up, but some go down, because the cost of GC is
decreased.  (The benchmarks include GC time.)

Thanks for the tip -- does this use gcc, and if so, what is the

You know, of course, that CMUCL is a native compiler that doesn't use gcc. I hand-wrote the assembly code to clear the stack area. :-)

Ray

Follow-Ups:
- Re: [Fwd: Uninitialized stack gaps and conservative garbage collection]
  - From: Camm Maguire

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