public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* GC change to `code' in RTL
@ 1999-09-04 20:24 Mark Mitchell
  1999-09-30 18:02 ` Mark Mitchell
  0 siblings, 1 reply; 2+ messages in thread
From: Mark Mitchell @ 1999-09-04 20:24 UTC (permalink / raw)
  To: gcc; +Cc: Alexander Samuel

Bernd pointed out that one change from the GC branch is likely to have
an impact on performance, even in compilers not using GC.  Namely, the
change to take a bit from `code' in RTL to obtain a `gc_mark' bit.
The problem is that now `code' is 15 bits, and `mode' is not
byte-aligned, making both of them harder to load.

CodeSourcery will, in the next week or so, contribute a new
non-conservative GC, based on `mmap' (but allowing other ways of
getting aligned memory, like `memalign' and/or `valloc').  It should
be a good bit faster that the current GC, and will not necessitate
touching all memory every time a collection is done.

On targets that can use this collector (which is almost everything;
what systems don't provide a means of getting decently-aligned
memory?), there will be no need for a `gc_mark' bit; the marks will be
kept in an on-the-side data structure.  

So, the performance hit due to the RTL change will be very temporary.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

* GC change to `code' in RTL
  1999-09-04 20:24 GC change to `code' in RTL Mark Mitchell
@ 1999-09-30 18:02 ` Mark Mitchell
  0 siblings, 0 replies; 2+ messages in thread
From: Mark Mitchell @ 1999-09-30 18:02 UTC (permalink / raw)
  To: gcc; +Cc: Alexander Samuel

Bernd pointed out that one change from the GC branch is likely to have
an impact on performance, even in compilers not using GC.  Namely, the
change to take a bit from `code' in RTL to obtain a `gc_mark' bit.
The problem is that now `code' is 15 bits, and `mode' is not
byte-aligned, making both of them harder to load.

CodeSourcery will, in the next week or so, contribute a new
non-conservative GC, based on `mmap' (but allowing other ways of
getting aligned memory, like `memalign' and/or `valloc').  It should
be a good bit faster that the current GC, and will not necessitate
touching all memory every time a collection is done.

On targets that can use this collector (which is almost everything;
what systems don't provide a means of getting decently-aligned
memory?), there will be no need for a `gc_mark' bit; the marks will be
kept in an on-the-side data structure.  

So, the performance hit due to the RTL change will be very temporary.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-09-30 18:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-09-04 20:24 GC change to `code' in RTL Mark Mitchell
1999-09-30 18:02 ` Mark Mitchell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).