This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [Fwd: Uninitialized stack gaps and conservative garbage collection]
- From: Camm Maguire <camm at enhanced dot com>
- To: Raymond Toy <rtoy at earthlink dot net>
- 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, gcl-devel at gnu dot org
- Date: 03 Jun 2005 11:37:53 -0400
- Subject: Re: [Fwd: Uninitialized stack gaps and conservative garbage collection]
- References: <65953E8166311641A685BDF71D8658262B6FB0@cacexc12.americas.cpqcorp.net><54k6lkda3g.fsf@intech19.enhanced.com> <429E670C.30603@earthlink.net>
Greetings!
Raymond Toy <rtoy@earthlink.net> writes:
> 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. :-)
>
:-) I forgot. I think I've discovered a way to do the same from
:within C, but I don't like it. Right now we've addressed most issues
:by pushing the stack mark origin to the frame just above toplevel --
at least a toplevel gc should be able to reclaim all memory.
The stress test here is repeatedly making a list the size of the whole
heap :-).
Take care,
> Ray
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah