[m-dev.] interactive queries, dlclose(), and profiling

[Fergus Henderson]

I wrote:
> Another alternative would be to change the implementation of memory profiling
> so that it makes a fresh copy of the procedure name string, rather than
> just copying the pointer -- see the diff below.  That would solve the
> current problem, albeit at some efficiency cost.  However, I suspect that
> there are probably similar problems with other global tables used by
> time profiling, call profiling, and the debugger itself.  And for time
> profiling, the efficiency cost of the extra copying might be significant,
> because it would cause the profiles to be a bit more skewed.

On further investigation, it turns out that time and call profiling don't keep
any real references to static memory of the modules being loaded, so they
won't run into quite the same problem.  Time and call profiling keep tables
indexed by code addresses, rather than by strings, and these code addresses
are never dereferenced, since they are just used as identifiers rather than
as pointers.  If dlopen() should happen to map two different procedures
onto the same address at different times, then the profiler's results might
be less informative than you would like, but I think we can live with that.
It's already possible for two different procedures to map to the same
address if they happen to have the same code, so I think the profiler
should already handle that case correctly.

There are also problems with the global tables used by the debugger and
the accurate garbage collector, and with the `Prof.Addrs' file used
by the profiler.  The label table and entry table do contain
pointers to static memory, specifically the layout structures.
Currently dl__open/6 does not call the initialization functions for the
library being loaded, so labels in dynamically loaded modules don't get
inserted into the label table.  This makes it impossible to debug stuff
in dynamically loaded modules.  Likewise, labels in dynamically loaded
modules also don't get printed to the `Prof.Addrs' file, which will
probably cause some problems for profiling. 
Nor does dl__close call finalization functions -- indeed currently we
don't support finalization functions at all.

I guess we should eventually arrange things so that we build initialization
and finalization functions for each library.  The initialization functions
should add entries to the label table, and any similar global tables,
and (if profiling is enabled) should print them to the `Prof.Addrs' file. 
The finalization functions should remove the entries from the global tables.
The dl__open and dl__close procedures should invoke the initialization
and finalization functions (respectively).
Any part of the system which, like memory profiling, needs to hold on to
information defined in a module even after it has been dlclose()'d
should make a copy of that information.

So for now, I will go ahead and commit the change to mercury_heap_profile.c
to get it to make a copy of the string.  The changes to the way we handle
initialization and finalization functions can wait for another day.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.