Re: libgcj/1190: GC: failure upon allocation inside a finalizer

Re: libgcj/1190: GC: failure upon allocation inside a finalizer

[tromey]

Synopsis: GC: failure upon allocation inside a finalizer

State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Sun Dec  2 21:49:26 2001
State-Changed-Why:
    I think this was fixed when I introduce the new
    finalizer thread a while ago.  Do you agree?
    I tried the sample program and it no longer fails.
    I'm closing this.  If there's still a problem we can reopen it.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=1190&database=gcc

Re: libgcj/1190: GC: failure upon allocation inside a finalizer

[tromey]

The following reply was made to PR libgcj/1190; it has been noted by GNATS.

From: tromey@gcc.gnu.org
To: bryce@albatross.co.nz, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
  gcc-prs@gcc.gnu.org, hans_boehm@hp.com, java-prs@gcc.gnu.org,
  tromey@gcc.gnu.org
Cc:  
Subject: Re: libgcj/1190: GC: failure upon allocation inside a finalizer
Date: 3 Dec 2001 05:49:27 -0000

 Synopsis: GC: failure upon allocation inside a finalizer
 
 State-Changed-From-To: open->closed
 State-Changed-By: tromey
 State-Changed-When: Sun Dec  2 21:49:26 2001
 State-Changed-Why:
     I think this was fixed when I introduce the new
     finalizer thread a while ago.  Do you agree?
     I tried the sample program and it no longer fails.
     I'm closing this.  If there's still a problem we can reopen it.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=1190&database=gcc

libgcj/1190: GC: failure upon allocation inside a finalizer

[bryce]

>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" <hans_boehm@hp.com>
To: "'java-gnats@sourceware.cygnus.com'"
	 <java-gnats@sourceware.cygnus.com>,
        "'bryce@albatross.co.nz'"
	 <bryce@albatross.co.nz>, tromey@cygnus.com
Cc: java-prs@sourceware.cygnus.com, green@cygnus.com,
        "Boehm, Hans"
	 <hans_boehm@hp.com>
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 <tromey@cygnus.com>
To: "Boehm, Hans" <hans_boehm@hp.com>
Cc: "'java-gnats@sourceware.cygnus.com'" <java-gnats@sourceware.cygnus.com>,
        "'bryce@albatross.co.nz'" <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" <hans_boehm@hp.com>
To: "'Tom Tromey'" <tromey@cygnus.com>, "Boehm, Hans" <hans_boehm@hp.com>
Cc: "'java-gnats@sourceware.cygnus.com'"
	 <java-gnats@sourceware.cygnus.com>,
        "'bryce@albatross.co.nz'"
	 <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 <tromey@cygnus.com>
To: "Boehm, Hans" <hans_boehm@hp.com>
Cc: "'Tom Tromey'" <tromey@cygnus.com>,
        "'java-gnats@sourceware.cygnus.com'" <java-gnats@sourceware.cygnus.com>,
        "'bryce@albatross.co.nz'" <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" <hans_boehm@hp.com>
To: "'Tom Tromey'" <tromey@cygnus.com>, "Boehm, Hans" <hans_boehm@hp.com>
Cc: "'java-gnats@sourceware.cygnus.com'"
	 <java-gnats@sourceware.cygnus.com>,
        "'bryce@albatross.co.nz'"
	 <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: