gc problem?

Loren James Rittle rittle@latour.rsch.comm.mot.com
Tue Oct 23 19:38:00 GMT 2001


>> Not yet.  It is on my to-do list, but it is about 20 items down and
>> things get added to the top every day.  So I'd say it is a low
>> probability fix :-(

> Shouldn't we disable the warning instead?  Or, at least, make it a runtime
> option?

Hi Tom,

As a fellow i386 user seeing the exact same issue, here is the trivial
patch I have had in my source tree for a while.  Before patching this
way, I noticed that most/all other GC debugging had to be explicitly
enabled whereas this one was backwards.

Regards,
Loren

Index: allchblk.c
===================================================================
RCS file: /cvs/gcc/egcs/boehm-gc/allchblk.c,v
retrieving revision 1.8
diff -c -r1.8 allchblk.c
*** allchblk.c	2001/10/16 09:01:35	1.8
--- allchblk.c	2001/10/24 02:26:39
***************
*** 655,661 ****
  	                 && orig_avail - size_needed
  			    > (signed_word)BL_LIMIT) {
  	        /* Punt, since anything else risks unreasonable heap growth. */
! 		if (0 == GETENV("GC_NO_BLACKLIST_WARNING")) {
  	          WARN("Needed to allocate blacklisted block at 0x%lx\n",
  		       (word)hbp);
  		}
--- 655,661 ----
  	                 && orig_avail - size_needed
  			    > (signed_word)BL_LIMIT) {
  	        /* Punt, since anything else risks unreasonable heap growth. */
! 		if (0 != GETENV("GC_BLACKLIST_WARNING")) {
  	          WARN("Needed to allocate blacklisted block at 0x%lx\n",
  		       (word)hbp);
  		}
Index: doc/README.environment
===================================================================
RCS file: /cvs/gcc/egcs/boehm-gc/doc/README.environment,v
retrieving revision 1.3
diff -c -r1.3 README.environment
*** README.environment	2001/08/18 01:04:43	1.3
--- README.environment	2001/10/24 02:26:39
***************
*** 29,35 ****
  		when multiple processors are available will preserve
  		correctness, but may lead to really horrible performance.
  
! GC_NO_BLACKLIST_WARNING - Prevents the collector from issuing
  		"Needed to allocate blacklisted block at ..." warnings.
  
  The following turn on runtime flags that are also program settable.  Checked
--- 29,35 ----
  		when multiple processors are available will preserve
  		correctness, but may lead to really horrible performance.
  
! GC_BLACKLIST_WARNING - Requests the collector to issue
  		"Needed to allocate blacklisted block at ..." warnings.
  
  The following turn on runtime flags that are also program settable.  Checked
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672



More information about the Java mailing list