public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* apparent memory increase
@ 2008-05-21 23:05 Tom Tromey
  2008-05-22  9:24 ` Richard Guenther
  2008-05-23 13:28 ` Jan Hubicka
  0 siblings, 2 replies; 4+ messages in thread
From: Tom Tromey @ 2008-05-21 23:05 UTC (permalink / raw)
  To: GCC List

You may have seen this warning from the memory consumption tester:

http://gcc.gnu.org/ml/gcc-regression/2008-05/msg00041.html

... related to the recent identifier GC patch.

I looked into this a little.  My theory is that this is an artifact of
how the tester collects its data.  In particular I suspect the tester
was not including the identifier data in its memory stats -- but now,
because identifiers are allocated via the GC, they are included.

If this theory is in error, let me know and I will investigate some
more.  In this case, it would be helpful to have the script that
generates the report.

Tom

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

* Re: apparent memory increase
  2008-05-21 23:05 apparent memory increase Tom Tromey
@ 2008-05-22  9:24 ` Richard Guenther
  2008-05-22 15:02   ` Tom Tromey
  2008-05-23 13:28 ` Jan Hubicka
  1 sibling, 1 reply; 4+ messages in thread
From: Richard Guenther @ 2008-05-22  9:24 UTC (permalink / raw)
  To: Tom Tromey; +Cc: GCC List

On Thu, May 22, 2008 at 1:04 AM, Tom Tromey <tromey@redhat.com> wrote:
> You may have seen this warning from the memory consumption tester:
>
> http://gcc.gnu.org/ml/gcc-regression/2008-05/msg00041.html
>
> ... related to the recent identifier GC patch.
>
> I looked into this a little.  My theory is that this is an artifact of
> how the tester collects its data.  In particular I suspect the tester
> was not including the identifier data in its memory stats -- but now,
> because identifiers are allocated via the GC, they are included.
>
> If this theory is in error, let me know and I will investigate some
> more.  In this case, it would be helpful to have the script that
> generates the report.

For big testcases I actually see a consistend reduction in peak
overall memory usage
(the number if you would look at 'top').  For small testcases I can
see both ups and downs,
probably because of changes in the number and points of GC collections
(but I guess
that is expected).

Richard.

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

* Re: apparent memory increase
  2008-05-22  9:24 ` Richard Guenther
@ 2008-05-22 15:02   ` Tom Tromey
  0 siblings, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2008-05-22 15:02 UTC (permalink / raw)
  To: Richard Guenther; +Cc: GCC List

>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes:

Richard> For big testcases I actually see a consistend reduction in
Richard> peak overall memory usage (the number if you would look at
Richard> 'top').  For small testcases I can see both ups and downs,
Richard> probably because of changes in the number and points of GC
Richard> collections (but I guess that is expected).

If you are looking with top, I suppose noise for smaller test cases
could come from differences in the overhead imposed by the GC versus
an obstack.  Also the new scheme wastes some amount of memory per
identifier -- on average, half the minimum allocation size.

Tom

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

* Re: apparent memory increase
  2008-05-21 23:05 apparent memory increase Tom Tromey
  2008-05-22  9:24 ` Richard Guenther
@ 2008-05-23 13:28 ` Jan Hubicka
  1 sibling, 0 replies; 4+ messages in thread
From: Jan Hubicka @ 2008-05-23 13:28 UTC (permalink / raw)
  To: Tom Tromey; +Cc: GCC List

> You may have seen this warning from the memory consumption tester:
> 
> http://gcc.gnu.org/ml/gcc-regression/2008-05/msg00041.html
> 
> ... related to the recent identifier GC patch.
> 
> I looked into this a little.  My theory is that this is an artifact of
> how the tester collects its data.  In particular I suspect the tester
> was not including the identifier data in its memory stats -- but now,
> because identifiers are allocated via the GC, they are included.

This is my understanding too, that is why I did not reply to that mail.
SBRK memory didn't increased, so we just moved stuff into GGC from
memory we didn't track at all.

Honza
> 
> If this theory is in error, let me know and I will investigate some
> more.  In this case, it would be helpful to have the script that
> generates the report.
> 
> Tom

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

end of thread, other threads:[~2008-05-23 13:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-05-21 23:05 apparent memory increase Tom Tromey
2008-05-22  9:24 ` Richard Guenther
2008-05-22 15:02   ` Tom Tromey
2008-05-23 13:28 ` Jan Hubicka

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).