Analysis of Mauve failures - The final chapter

Fri Apr 5 11:37:00 GMT 2002

How about the following "solution" for now:
1) We unconditionally suppress all but every Nth instance of this warning.
(N settable by environment variable replacing GC_NO_BLACKLIST_WARNING,
defaulting to 3). I expect this eliminates the warning completely for all
the standard test cases, and 90% of the rest. I'm not too uncomfortable
with that, since a bounded number of these usually at most indicate a
bounded space leak.
2) We change the warning message to something like
"Repeated allocation of very large block (size %ld): may lead to poor GC
performance and memory leak."
Observations:
- I think it's virtually guaranteed that you will run out of memory before
you get 2 billion of these. Thus setting the threshold sufficiently large
effectively turns off the warning. For backward compatibility,
GC_NO_BLACKLIST_WARNING can be implemented this way.
- If you get regularly repeating instances of this warning, you really do
want to know about it. Unfortunately, currently the only workaround is to
allocate data structures in smaller chunks, or perhaps to instead allocate a
permanent data structure once. (The latter is worth considering anyway,
since large object allocation is expensive in any garbage-collected system.)
On the other hand, I'm not sure anyone has encountered this situation, yet.
Does this sound reasonable?
Hans
> -----Original Message-----
> From: Andrew Haley [mailto:aph@cambridge.redhat.com]
> Sent: Friday, April 05, 2002 10:19 AM
> To: Boehm, Hans
> Cc: 'Mark Wielaard'; java@gcc.gnu.org
> Subject: RE: Analysis of Mauve failures - The final chapter
>>> Thank you for the reminder.
>> Boehm, Hans writes:
>> > As it stands, I'm hesitant to turn off the warnings by 
> default, though
> > I can see arguments either way. If the warnings occur repeatedly,
> > they are indicative of a potential memory leak. If 
> someone wants to
> > turn it off by default, and instead provide an environment 
> variable to
> > turn it back on, I could probably be talked into that, too.
>> It seems to me that we have to make up our minds.
>> IMO: If we are shipping a production-quality system then we shouldn't
> output warnings about which we'll say "ah, don't worry about that
> message, we already know about that." It doesn't look good, and it
> will suggest to people that we don't have a serious offering. This is
> especially true if the warning message uses obscure and frightening
> terminology. This warning message looks like something major has
> failed.
>> Andrew.
>