[m-rev.] Re: [m-dev.] Deep Profiler: clique_proc_report and clique_proc_report_dynamic
pbone at csse.unimelb.edu.au
Wed Feb 11 11:50:55 AEDT 2009
On Wed, Feb 11, 2009 at 11:35:41AM +1100, Zoltan Somogyi wrote:
> On 10-Feb-2009, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > :- type clique_proc_report
> > ---> clique_proc_report(
> > % Summary information for the cost of this procedure in this
> > % clique.
> > cpr_proc_summary :: perf_row_data(proc_desc),
> > % Multiple proc dynamics may occur within the same clique when
> > % there are recursive calls to the same procedure that are
> > % called from different contexts (created by mutually-recursive
> > % calls). This is quite rare. This can occur when the calls
> > % have different call sites or when they are called called from
> > % different contexts within the same clique.
> > cpr_first_proc_dynamic :: clique_proc_dynamic_report,
> > cpr_other_proc_dynamics :: list(clique_proc_dynamic_report)
> > ).
> I don't think that is informative. I have instead committed this diff.
> cvs diff: Diffing .
> Index: report.m
> RCS file: /home/mercury/mercury1/repository/mercury/deep_profiler/report.m,v
> retrieving revision 1.17
> diff -u -b -r1.17 report.m
> --- report.m 2 Jan 2009 02:59:36 -0000 1.17
> +++ report.m 11 Feb 2009 00:34:09 -0000
> @@ -137,6 +137,29 @@
> % clique.
> cpr_proc_summary :: perf_row_data(proc_desc),
> + % A clique may contain more than one proc_dynamic for the same
> + % procedure in one rare circumstance. Consider a clique of
> + % two procedures, let's call them p and q. The entry procedure
> + % is p. When p calls q and q then calls p, the runtime
> + % discovers they are in the same clique. However, after all
> + % those mutually recursive calls unwind and we get back to the
> + % original call to p, p can call q again. If it does so through
> + % a call site through which it has not called q before, then
> + % the call port code in q will allocate a new proc_dynamic,
> + % since it will not find an existing one it can reuse;
> + % q's proc_static won't point to an active proc_dynamic, and
> + % the call site will not supply one either.
> + %
> + % We could modify the code we invoke at call ports to keep a
> + % list of the proc_dynamics of the procedures known to be in
> + % the current clique, and to reuse the proc_dynamic of the
> + % callee in these cases, but that would significantly increase
> + % the call port overhead. Instead, we let the callee allocate a
> + % second (and maybe third etc) proc_dynamic for a procedure,
> + % and let the deep profiler sort it out.
> + %
> + % Note that the entry procedure of a clique will always have
> + % exactly one proc_dynamic.
> cpr_first_proc_dynamic :: clique_proc_dynamic_report,
> cpr_other_proc_dynamics :: list(clique_proc_dynamic_report)
> cvs diff: Diffing notes
This is good, very clear.
I've cross-posted my reply and bounced your e-mail to the reviews list
so that this change can be found when searching the mailing list
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the reviews