Patch for exposing gc_stats() to the public + GCStats enhancements

the patch (attachments magically work now, sorry about the inline patch)

Thanks. What do you think, Fawzi?

I don't agree with the choice of making the gc_stat struct public, the kind of info available is quite generic, it is still dependent on the gc algorithm, and the access to it is not time critical, so I would like to see an interface with a string based interface (hash like), and ways to check the presence of a given string.

Total allocation/deallocation and total time in gc could be generic for all GCs.

With those changes I have no problems with the patch

Fawzi, what exactly do you have in mind?

Here are two ideas about an interface, that isn't fixed to a struct with fixed members:

1. ulong gc_get_stat(char[] stat_name);

(can return 0 or ulong.max to signal non-presence of a stat_name)

2. ulong[char[]] gc_get_stats();

Same as 1., but return all present values in an associative array.

3. struct StatEntry { char[20] name; ulong value; } StatEntry[] gc_get_stats(StatEntry[] prealloc);

Basically the same interface again. The user has to pass a preallocated array in prealloc, and the function returns a slice of this array.

But that isn't without problems:

For 1, you need several calls to gc_get_stat() to get all statistics, but then the returned values could be inconsistent with each other (e.g. because a garbage collection happened between two calls). I don't think this is really a problem, though.

For 2, gc_get_stats() needs to allocate memory, which might be a problem.

3 avoids memory allocation, but is a bit complicated and unintuitive for the user.

Please tell me what to do. I think if I don't push this, nothing will ever happen. It's so trivial, yet annoying.

I was thinking to use a class that returns the gc info, and implements real opIndex(char[]) and bool opIn(char[]) and dup. There should be a global instance that gives the info for the current gc. i.e something like

class GCInfo{
 static GCInfo instance;
 static GCInfo opCall(){ return instance; }
 real opIndex(char[]k){ assert(false,"unsupported key "~k); }
 bool opIn(char[]k){ return false; }
 GCInfo dup(){ return this; }
}

private class BasicGCInfo: GCInfo{
//...
}

static this(){
  GCInfo.instance=new BasicGCInfo();
}

doing it this way, support for other GC would be trivial without changing the interface

About the extra info on gc runs that is part of the patch, that is welcome.

new patch

Sorry I just looked in detail at the patch, and I don't like having tango-base depending on Variant (through the extern(C) function).

Sometime Variant does not compile, or has problems on some platform/compilers, making tango-base depend on it looks like a bad choice. I am sorry I didn't realize the issue earlier, I think that maybe using a real is still the best solution...

in r4880 GCStats are user accessible

this will have to be done again in some way with the new directory struct

(In [5465]) fixes #1702 :: Patch for exposing gc_stats() to the public + GCStats enhancements

made some changes to support the invocation of user-defined delegates at the beginning and end of a full-collection

Thanks to wintervar

The changset [5465] caused some problems when building tango as a dynamic library on mac. I'm getting errors about a missing symbol.

Undefined symbols:

"_D5tango4core6Memory10gc_monitorFDFZvDFiiZvZv", referenced from:

_D5tango4core6Memory2GC7monitorFDFZvDFiiZvZv in tango-coreMemory-release.o

ld: symbol(s) not found collect2: ld returned 1 exit status

The problem is the newly added "gc_monitor" in tango.core.Memory. Since it's declared extern (D) it will include the module in the mangled name. But "gc_monitor" is declared in rt.gc.basic.gc and that declaration will mangle the name to containing a different module name. Is it possible to declare the function as a C function?

oh drat ... I'd like to make it extern(C), but doing so won't accept delegates as arguments :|

Any idea how to fix the delegate issue? (change the decl to extern(C) and recompile to see the issue)

Replying to kris:

oh drat ... I'd like to make it extern(C), but doing so won't accept delegates as arguments :|

Yeah, I noticed that.

Any idea how to fix the delegate issue? (change the decl to extern(C) and recompile to see the issue)

An ugly solution is to declare the function as an extern (C) void pointer with the same name as the mangled name then cast it to a function pointer when calling it:

extern (C) void* _D2rt2gc5basic2gc10gc_monitorFDFZvDFiiZvZv;

static void monitor( void delegate() begin, void delegate(int, int) end )
{
    (cast(void function (void delegate(), void delegate(int, int)) gc_monitor)( begin, end );
}

Actually, I don't know if the above will run, it links anyway.

Patch for the latest issue

What compiles, too is

_gc.monitor (cast(void delegate())begin,cast(void delegate(int,int)) end);

but when trying to use the resulting .a to link I still get

undefined reference to `_D5tango4core6Memory10gc_monitorFDFZvDFiiZvZv'

--Maren

Okay, I fixed it now.

in Memory.d, change the decleration, so that it looks like

		alias extern(D) void delegate() ddel;
		alias extern(D) void delegate(int,int) dint;

		extern (C) void gc_monitor(ddel begin, dint end );

in gc.d:

alias extern(D) void delegate() ddel;
alias extern(D) void delegate(int,int) dint;

extern (C) void gc_monitor( ddel begin, dint end )
{
	_gc.monitor (begin,end);
}

(or you can define the aliases only in one file and import the file, doesn't matter)

--Marenz

Works me as well (dmd 1.060, tango trunk).

(In [5477]) fixes #1702 :: Patch for exposing gc_stats() to the public + GCStats enhancements

kudos to doob & marenz

Sorry, that's not enough information you can get from the GC.

What is still missing: * get the number of bytes in use * get the number of free bytes (e.g. in freelists) * get the number of pools (this number seems kind of critical for GC performance, so you'd naturally be interested in it)

The solution is very simple: just expose gcstats.d and the gc_stats() function to the user.