On 2011-12-05 23:45, Iain Buclaw wrote:
> On 5 December 2011 22:34, Martin Nowak<dawg@dawgfoto.de>  wrote:
>> We currently add something from etext to _end (rt.memory) as static root.
>> This probably contains read-only sections, data from other languages
>> and (unlikely) other unrelated sections.
>> I think some help from the compiler will be necessary to support
>> shared libraries anyhow, so we should be able to get a precise range.
>>
>
> Indeed.  The current implementation kicking around is to scan
> /proc/self/maps on init (this is true for the runtime that ships with
> GDC at least).  Which is not the most pleasant of things to do - not
> to mention only supports Unix-flavoured systems, but it works well
> enough for when linking against shared D libraries.

/proc doesn't exist on Mac OS X.

-- 
/Jacob Carlborg

I have an updated and win32-compilable version of CDGC in a branch. It's missing some features from the current GC though (it's based on the Tango GC which has remained relatively static for the past years while druntime's GC has improved).

Sent from my iPhone

On Dec 5, 2011, at 3:39 PM, Trass3r <un@known.com> wrote:

>> On 05/12/2011 01:46, dsimcha wrote:
>>> I'm at my traditional passtime of trying to speed up D's garbage collector again
>> 
>> Have you thought about pushing for the inclusion of CDGC at all/working on the tweaks needed to make it the main GC?
> 
> So true, it's been rotting in that branch.

On Dec 4, 2011, at 5:46 PM, dsimcha wrote:

> I'm at my traditional passtime of trying to speed up D's garbage collector again, and I've stumbled on the fact that rt_finalize is taking up a ridiculous share of the time (~30% of total runtime) on a benchmark where huge numbers of classes **that don't have destructors** are being created and collected.  Here's the code to this function, from lifetime.d:
> 
> extern (C) void rt_finalize(void* p, bool det = true)
> {
>    debug(PRINTF) printf("rt_finalize(p = %p)\n", p);
> 
>    if (p) // not necessary if called from gc
>    {
>        ClassInfo** pc = cast(ClassInfo**)p;
> 
>        if (*pc)
>        {
>            ClassInfo c = **pc;
>            byte[]    w = c.init;
> 
>            try
>            {
>                if (det || collectHandler is null || collectHandler(cast(Object)p))
>                {
>                    do
>                    {
>                        if (c.destructor)
>                        {
>                            fp_t fp = cast(fp_t)c.destructor;
>                            (*fp)(cast(Object)p); // call destructor
>                        }
>                        c = c.base;
>                    } while (c);
>                }
>                if ((cast(void**)p)[1]) // if monitor is not null
>                    _d_monitordelete(cast(Object)p, det);
>                (cast(byte*) p)[0 .. w.length] = w[];  // WTF?
>            }
>            catch (Throwable e)
>            {
>                onFinalizeError(**pc, e);
>            }
>            finally  // WTF?
>            {
>                *pc = null; // zero vptr
>            }
>        }
>    }
> }
> 
> Getting rid of the stuff I've marked with //WTF? comments (namely the finally block and the re-initializing of the memory occupied by the finalized object) speeds things up by ~15% on the benchmark in question.  Why do we care what state the blob of memory is left in after we finalize it?  I can kind of see that we want to clear things if delete/clear was called manually and we want to leave the object in a state that doesn't look valid.  However, this has significant performance costs and IIRC is already done in clear() and delete is supposed to be deprecated.  Furthermore, I'd like to get rid of the finally block entirely, since I assume its presence and the effect on the generated code is causing the slowdown, not the body, which just assigns a pointer.

Now that having multiple in-flight exceptions is actually legal, we can probably just throw out the try/catch entirely.  The try/catch and call to onFinalizeError is a holdover from when it was effectively illegal to throw from a finalizer.

dsimcha:

> I'm at my traditional passtime of trying to speed up D's garbage collector again,

Are you going to create a pull request soon? So people will be able to try it with their D programs and spot potential troubles...

Bye,
bearophile