[Openmcl-devel] Re: persistence of xref info in fasl files.

[Alan Ruttenberg]

callers considers a global function f to be the caller of a function g if g
is called by f or any function referenced as an immediate by f. It does that
by building a table of functions referencing functions while it looks for g.
top-level-caller takes a possibly non-global function and looks up the
global function(s) that refer to it, possibly indirectly.

So if you start by looking at symbols first and you want to preserve this
behavior (I think you do) then I think you either need search downward from
the global function through the functions it references, or save all xref
info in the global function.

(defun one ())
(defun two () (flet ((three () (one))) (three)))
(callers 'one) -> (TWO)

Is there agreement that this is desirable behavior?


-Alan

> From: Gary Byers <gb at clozure.com>
> Date: Sun, 4 Jan 2004 14:51:04 -0700 (MST)
> To: Oliver Markovic <entrox at entrox.org>
> Cc: openmcl-devel at clozure.com
> Subject: Re: [Openmcl-devel] Re: persistence of xref info in fasl files.
> 
> The big exception that I have to ccl::callers is that it uses low-level
> heap walking primitives to find and examine functions.  Aside from all
> of the locality/paging arguments against that, it basically has to
> suspend all other threads while it's traversing the heap (the way
> that per-thread consing works in 0.14 makes this complicated.)  There
> are all kinds of ways to lose (deadlock, mostly) when doing this,
> and I'd like to find a better alternative.
> 
> The confusing part is that (after looking at every function in the
> heap), CCL::CALLERS discards those that aren't globally accessible
> (things that aren't current function definitions, macro definitions,
> active method functions, etc.)  There are a number of good reasons for
> it to concentrate only on those things that are globally accessible,
> but of the two strategies:
> 
> a) find all interesting interesting functions by walking the heap,
>   discard those that aren't globally accessible.
> b) traverse (via DO-ALL-SYMBOLS or something) all globally-accessible
>   functions, find those that're interesting.
> 
> (b) seems preferable for a lot of reasons.  If there's a good reason
> for the current CCL::CALLERS to be implemented via (a) instead of (b),
> I can't think of it.




This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.