From mboxrd@z Thu Jan 1 00:00:00 1970 From: bryce@albatross.co.nz To: java-gnats@sourceware.cygnus.com Cc: hans_boehm@hp.com Subject: libgcj/1190: GC: failure upon allocation inside a finalizer Date: Wed, 20 Dec 2000 12:21:00 -0000 Message-id: <20000507101125.12370.qmail@sourceware.cygnus.com> X-SW-Source: 2000-q4/msg00982.html List-Id: >Number: 1190 >Category: libgcj >Synopsis: GC: failure upon allocation inside a finalizer >Confidential: no >Severity: serious >Priority: medium >Responsible: tromey >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Wed Dec 20 12:17:20 PST 2000 >Closed-Date: >Last-Modified: Mon May 8 16:16:01 PDT 2000 >Originator: Bryce McKinlay >Release: Current cvs libgcj, using boehm-gc 5.0alpha7 >Organization: >Environment: linux >Description: A java finalizer that tries to perform an allocation can throw the collector into an infinate loop: [...] #43488 0x402355f6 in GC_invoke_finalizers () at ../../../boehm-gc/finalize.c:728 #43489 0x402372bc in GC_generic_malloc (lb=20, k=4) at ../../../boehm-gc/malloc.c:130 #43490 0x4015b7a2 in _Jv_AllocObj (size=20) at ../../../libjava/boehm.cc:305 #43491 0x400acf15 in _Jv_AllocObject (c=0x804cdd0, size=20) at ../../../libjava/prims.cc:330 #43492 0x804b598 in Finalizer.finalize (this=0x80bdfd0) at Finalizer.java:13 #43493 0x40147a6d in _Jv_FinalizeObject (obj=0x80bdfd0) at ../../../libjava/java/lang/natObject.cc:255 #43494 0x4015b84b in call_finalizer (obj=0x80bdfd0, client_data=0x40147a50) at ../../../libjava/boehm.cc:336 #43495 0x402355f6 in GC_invoke_finalizers () at ../../../boehm-gc/finalize.c:728 [...] >How-To-Repeat: public class Finalizer { public static void main(String args[]) { for (int i=0; i < 500000; i++) { new Finalizer(); } } public void finalize() { new java.util.Vector (); } } >Fix: Asynchronous finalization? >Release-Note: >Audit-Trail: Formerly PR libgcj/222 From: "Boehm, Hans" To: "'java-gnats@sourceware.cygnus.com'" , "'bryce@albatross.co.nz'" , tromey@cygnus.com Cc: java-prs@sourceware.cygnus.com, green@cygnus.com, "Boehm, Hans" Subject: RE: libgcj/222: GC: failure upon allocation inside a finalizer Date: Mon, 8 May 2000 14:09:26 -0700 Is this really an infinite loop? The finalization code is quite careful to remove the current finalizable object from the list before it invokes the finalizer, for precisely this reason. Thus I suspect you really only get 500,000 levels of recursion before it terminates :-). Unless my reasoning is incorrect, I'm actually inclined to not fic this directly, in large part because this path shouldn't be getting exercised anyway. Gcj needs to build the collector with -DFINALIZE_ON_DEMAND, and run finalizers from a separate thread. Aside from these problems, it seems to me that the current scheme is just plain broken, since the finalizer may be run in a thread that holds Java locks. In general, running finalizers from the allocator is a bad idea. It's the collector default only beacuse you can't do much else without assuming the existence of threads or losing backward compatibility with earlier versions of the collector. We probably need to add some mechanism for having the collector notify the finalizer thread when there is something to do. Perhaps a callback that is invoked at the end of a GC when there are objects to be finalized? Currently the finalizer thread would have to poll periodically. Hans -----Original Message----- From: bryce@albatross.co.nz [ mailto:bryce@albatross.co.nz ] Sent: Sunday, May 07, 2000 3:11 AM To: tromey@cygnus.com Cc: java-prs@sourceware.cygnus.com; green@cygnus.com; hans_boehm@hp.com Subject: libgcj/222: GC: failure upon allocation inside a finalizer >Number: 222 >Category: libgcj >Synopsis: GC: failure upon allocation inside a finalizer >Confidential: no >Severity: serious >Priority: medium >Responsible: tromey >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Sun May 07 03:16:00 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Bryce McKinlay >Release: Current cvs libgcj, using boehm-gc 5.0alpha7 >Organization: >Environment: linux >Description: A java finalizer that tries to perform an allocation can throw the collector into an infinate loop: [...] #43488 0x402355f6 in GC_invoke_finalizers () at ../../../boehm-gc/finalize.c:728 #43489 0x402372bc in GC_generic_malloc (lb=20, k=4) at ../../../boehm-gc/malloc.c:130 #43490 0x4015b7a2 in _Jv_AllocObj (size=20) at ../../../libjava/boehm.cc:305 #43491 0x400acf15 in _Jv_AllocObject (c=0x804cdd0, size=20) at ../../../libjava/prims.cc:330 #43492 0x804b598 in Finalizer.finalize (this=0x80bdfd0) at Finalizer.java:13 #43493 0x40147a6d in _Jv_FinalizeObject (obj=0x80bdfd0) at ../../../libjava/java/lang/natObject.cc:255 #43494 0x4015b84b in call_finalizer (obj=0x80bdfd0, client_data=0x40147a50) at ../../../libjava/boehm.cc:336 #43495 0x402355f6 in GC_invoke_finalizers () at ../../../boehm-gc/finalize.c:728 [...] >How-To-Repeat: public class Finalizer { public static void main(String args[]) { for (int i=0; i < 500000; i++) { new Finalizer(); } } public void finalize() { new java.util.Vector (); } } >Fix: Asynchronous finalization? >Release-Note: >Audit-Trail: >Unformatted: From: Tom Tromey To: "Boehm, Hans" Cc: "'java-gnats@sourceware.cygnus.com'" , "'bryce@albatross.co.nz'" , tromey@cygnus.com, green@cygnus.com Subject: RE: libgcj/222: GC: failure upon allocation inside a finalizer Date: Mon, 8 May 2000 15:31:13 -0700 (PDT) Hans> We probably need to add some mechanism for having the collector Hans> notify the finalizer thread when there is something to do. Hans> Perhaps a callback that is invoked at the end of a GC when there Hans> are objects to be finalized? That would be perfect. We'll have the finalizer thread wait on a condition variable, and we'll have the callback notify it. Tom From: "Boehm, Hans" To: "'Tom Tromey'" , "Boehm, Hans" Cc: "'java-gnats@sourceware.cygnus.com'" , "'bryce@albatross.co.nz'" , green@cygnus.com Subject: RE: libgcj/222: GC: failure upon allocation inside a finalizer Date: Mon, 8 May 2000 15:59:33 -0700 One minor complication is that in the single-threaded case, everything will presumably have to continue working as it does now. The alternative would be to require an explicit client call to run finalizers. That's probably closer to correct, but I suspect it would break a lot more existing code. Single-threaded finalization just doesn't work well. Hans -----Original Message----- From: Tom Tromey [ mailto:tromey@cygnus.com ] Sent: Monday, May 08, 2000 3:31 PM To: Boehm, Hans Cc: 'java-gnats@sourceware.cygnus.com'; 'bryce@albatross.co.nz'; tromey@cygnus.com; green@cygnus.com Subject: RE: libgcj/222: GC: failure upon allocation inside a finalizer Hans> We probably need to add some mechanism for having the collector Hans> notify the finalizer thread when there is something to do. Hans> Perhaps a callback that is invoked at the end of a GC when there Hans> are objects to be finalized? That would be perfect. We'll have the finalizer thread wait on a condition variable, and we'll have the callback notify it. Tom From: Tom Tromey To: "Boehm, Hans" Cc: "'Tom Tromey'" , "'java-gnats@sourceware.cygnus.com'" , "'bryce@albatross.co.nz'" , green@cygnus.com Subject: RE: libgcj/222: GC: failure upon allocation inside a finalizer Date: Mon, 8 May 2000 16:02:42 -0700 (PDT) Hans> One minor complication is that in the single-threaded case, Hans> everything will presumably have to continue working as it does Hans> now. Do you mean for gcj or in general? For gcj we only have to deal with this for the case where libgcj was configured threadless. Tom From: "Boehm, Hans" To: "'Tom Tromey'" , "Boehm, Hans" Cc: "'java-gnats@sourceware.cygnus.com'" , "'bryce@albatross.co.nz'" , green@cygnus.com Subject: RE: libgcj/222: GC: failure upon allocation inside a finalizer Date: Mon, 8 May 2000 16:14:26 -0700 I was concerned about the threadless libgcj (which I've found very useful on occasion). Even there, the decision is really about the default behavior, since you can always change the behavior with a small amount of native code. Hans -----Original Message----- From: Tom Tromey [ mailto:tromey@cygnus.com ] Sent: Monday, May 08, 2000 4:03 PM To: Boehm, Hans Cc: 'Tom Tromey'; 'java-gnats@sourceware.cygnus.com'; 'bryce@albatross.co.nz'; green@cygnus.com Subject: RE: libgcj/222: GC: failure upon allocation inside a finalizer Hans> One minor complication is that in the single-threaded case, Hans> everything will presumably have to continue working as it does Hans> now. Do you mean for gcj or in general? For gcj we only have to deal with this for the case where libgcj was configured threadless. Tom >Unformatted: