www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC finalizer optimization.

reply Dave <Dave_member pathlink.com> writes:
Comments? Like, how can this break things?

By changing line 129 of phobos/internal/gc/gc.d from:

_gc.setFinalizer(p, &new_finalizer);

to:

///_gc.setFinalizer(p, &new_finalizer);
///
     ClassInfo c = ci;
     do
     {
         if (c.destructor)
         {
             _gc.setFinalizer(p, &new_finalizer);
         }
         c = c.base;
     } while (c);
///

gives me about 3x performance in allocating class objects w/o a dtor 
using the following code.

Before:
D::~this
C::~this
C::~this
0.829

After:
D::~this
C::~this
C::~this
0.258

;---

import std.date, std.stdio;

void main()
{
     C c = new C;
     D d = new D;
     E e;
     F f;

     d_time st = getUTCtime();
     for(int i = 0; i < 1_000_000; i++)
     {
         e = new E;
         f = new F;
     }
     d_time et = getUTCtime();
     writefln((et - st) / cast(double)TicksPerSecond);
}

class C
{
     int i;
     ~this()
     {
         printf("C::~this\n");
     }
}

class D : C
{
     int i;
     ~this()
     {
         printf("D::~this\n");
     }
}

class E
{
     int i;
}

class F : E
{
     int i;
}

Thanks,

- Dave
Apr 11 2006
next sibling parent kris <foo bar.com> writes:
Dave wrote:

 
 Comments? Like, how can this break things?
 
 By changing line 129 of phobos/internal/gc/gc.d from:
 
 _gc.setFinalizer(p, &new_finalizer);
 
 to:
 
 ///_gc.setFinalizer(p, &new_finalizer);
 ///
     ClassInfo c = ci;
     do
     {
         if (c.destructor)
         {
             _gc.setFinalizer(p, &new_finalizer);
         }
         c = c.base;
     } while (c);
 ///
 
 gives me about 3x performance in allocating class objects w/o a dtor 
 using the following code.
 
 Before:
 D::~this
 C::~this
 C::~this
 0.829
 
 After:
 D::~this
 C::~this
 C::~this
 0.258
 



Heh heh heh ;-)

Then, to identify "leaking" resources, the collector only has to check 
if there's a finalizer set :)
Apr 11 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Argh - I forgot about needing to release synchronization resources or 
zeroing the vptr. regardless of if there is a dtor or not...

Damn.

Dave wrote:

 
 Comments? Like, how can this break things?
 
 By changing line 129 of phobos/internal/gc/gc.d from:
 
 _gc.setFinalizer(p, &new_finalizer);
 
 to:
 
 ///_gc.setFinalizer(p, &new_finalizer);
 ///
     ClassInfo c = ci;
     do
     {
         if (c.destructor)
         {
             _gc.setFinalizer(p, &new_finalizer);
         }
         c = c.base;
     } while (c);
 ///
 
 gives me about 3x performance in allocating class objects w/o a dtor 
 using the following code.
 
 Before:
 D::~this
 C::~this
 C::~this
 0.829
 
 After:
 D::~this
 C::~this
 C::~this
 0.258
 
 ;---
 
 import std.date, std.stdio;
 
 void main()
 {
     C c = new C;
     D d = new D;
     E e;
     F f;
 
     d_time st = getUTCtime();
     for(int i = 0; i < 1_000_000; i++)
     {
         e = new E;
         f = new F;
     }
     d_time et = getUTCtime();
     writefln((et - st) / cast(double)TicksPerSecond);
 }
 
 class C
 {
     int i;
     ~this()
     {
         printf("C::~this\n");
     }
 }
 
 class D : C
 {
     int i;
     ~this()
     {
         printf("D::~this\n");
     }
 }
 
 class E
 {
     int i;
 }
 
 class F : E
 {
     int i;
 }
 
 Thanks,
 
 - Dave
Apr 11 2006
parent reply Dave <Dave_member pathlink.com> writes:
Dave wrote:

 
 Argh - I forgot about needing to release synchronization resources or 
 zeroing the vptr. regardless of if there is a dtor or not...
 
 Damn.
 


Maybe all is not lost, change gcx.setFinalizer to:

     void setFinalizer(void *p, GC_FINALIZER pFn)
     {
	// should be thread-safe - Threads.nthreads is
	//  mutex'd in std/thread.d
         if(Thread.nthreads > 1)
         {
         synchronized (gcLock)
         {
             gcx.finalizer = pFn;
             gcx.doFinalize(p);
         }
         }
         else
         {
             gcx.finalizer = pFn;
             gcx.doFinalize(p);
         }
     }

Now you get:

Before:
D::~this
C::~this
C::~this
0.827

After:
D::~this
C::~this
C::~this
0.466

- Dave


 Dave wrote:

 Comments? Like, how can this break things?

 By changing line 129 of phobos/internal/gc/gc.d from:

 _gc.setFinalizer(p, &new_finalizer);

 to:

 ///_gc.setFinalizer(p, &new_finalizer);
 ///
     ClassInfo c = ci;
     do
     {
         if (c.destructor)
         {
             _gc.setFinalizer(p, &new_finalizer);
         }
         c = c.base;
     } while (c);
 ///

 gives me about 3x performance in allocating class objects w/o a dtor 
 using the following code.

 Before:
 D::~this
 C::~this
 C::~this
 0.829

 After:
 D::~this
 C::~this
 C::~this
 0.258

 ;---

 import std.date, std.stdio;

 void main()
 {
     C c = new C;
     D d = new D;
     E e;
     F f;

     d_time st = getUTCtime();
     for(int i = 0; i < 1_000_000; i++)
     {
         e = new E;
         f = new F;
     }
     d_time et = getUTCtime();
     writefln((et - st) / cast(double)TicksPerSecond);
 }

 class C
 {
     int i;
     ~this()
     {
         printf("C::~this\n");
     }
 }

 class D : C
 {
     int i;
     ~this()
     {
         printf("D::~this\n");
     }
 }

 class E
 {
     int i;
 }

 class F : E
 {
     int i;
 }

 Thanks,

 - Dave
Apr 11 2006
parent Sean Kelly <sean f4.ca> writes:
Dave wrote:

 Dave wrote:

 Argh - I forgot about needing to release synchronization resources or 
 zeroing the vptr. regardless of if there is a dtor or not...

 Damn.


 
 Maybe all is not lost, change gcx.setFinalizer to:
 
     void setFinalizer(void *p, GC_FINALIZER pFn)
     {
     // should be thread-safe - Threads.nthreads is
     //  mutex'd in std/thread.d
         if(Thread.nthreads > 1)
         {
         synchronized (gcLock)
         {
             gcx.finalizer = pFn;
             gcx.doFinalize(p);
         }
         }
         else
         {
             gcx.finalizer = pFn;
             gcx.doFinalize(p);
         }
     }


This will optimize the code path for single-threaded programs, but I 
would advise against ever calling setFinalizer from user code.  So far 
as I can tell, the setFinalizer call is an artifact of the days before D 
classes could have dtors.  While you'd think setFinalizer sets a 
per-object finalizer pointer, it actually sets a bit flag indicating 
that p should be finalized and then sets a global pointer to the 
finalizer function.  Thus:

     gc_setFinalizer( p, null );
     gc_fullCollect();

will actually cause all orphaned objects to not be finalized during the 
collection, as the GC's finalizer pointer will be null.

I think the GC should be restructured so that setting the global 
finalizer function is available as a separate option from the function 
that indicates p should be finalized.  In fact, the finalizer should 
probably either be an established extern (C) function or set via 
gc_init, assuming it doesn't live inside the GC code.

For Ares, I've decided to make the finalizer a named C function 
(rt_finalize), and GC allocator functions now accept a parameter to 
indicate whether the block should be finalized on deletion/collection.


Sean
Apr 11 2006