This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Analysis of Mauve failures - The final chapter
- From: Andrew Haley <aph at cambridge dot redhat dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: "'Mark Wielaard'" <mark at klomp dot org>, java at gcc dot gnu dot org
- Date: Fri, 5 Apr 2002 10:07:47 +0100 (BST)
- Subject: RE: Analysis of Mauve failures - The final chapter
- References: <40700B4C02ABD5119F000090278766443BF170@hplex1.hpl.hp.com>
Boehm, Hans writes:
> > From: Mark Wielaard [mailto:mark@klomp.org]
> > > !java.lang.reflect.Array.newInstance
> > Ugh, not fun. Running by hand also hangs, but turning on the -debug or
> > -verbose flag makes it run... When not giving any flags it only prints
> > Needed to allocate blacklisted block at 0x824b000
> > The test actually tries to force a OutOfMemoryError exception which
> > might explain this. But the Object.clone() test also seems to do this
> > and that one just works.
> All tests that allocate large objects should ideally be run with the
> environment variable GC_NO_BLACKLIST_WARNING defined. That will get rid of
> the message. The occurrence of the warning is often less than 100%
> deterministic, and that's expected. Was there an issue here beyond the
> warning?
Hans,
I don't understand. If the gc isn't buggy, why does it produce this
warning at all in a production quality system?
Andrew.