[m-dev.] Deep Profiler: clique_proc_report and clique_proc_report_dynamic

[Paul Bone]

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
archives.

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20090211/3ebd98dc/attachment.sig>