[Openmcl-devel] Shark

[Dan Knapp]

   Thanks!  I've attached an updated version which incorporates your 
change;
avoids printing data for the same symbol twice; and sorts symbols by 
address
as a convenience for when I'm trying to figure out why things don't 
work.

   I've tested this with Shark 4.1.1 and, as far as I can tell, it is 
correctly
identifying symbols now.  Looking at my .spatch, though, I see lots of
symbols with the same address.  The first batch of them appears to be 
all the
built-ins; but then there's a batch containing a lot of my symbols and 
a lot of
symbols in COMMON-LISP.  I don't immediately see any other duplicated
addresses; I've put together an abbreviated version of these, to save 
you
reading the whole .spatch.

   Another anomaly is that Shark doesn't appear to understand Lisp 
function
calls; so instead of a call tree, you get a flat list.  I gather this 
is because
the actual call is done by funcall or some other system-wide trampoline?
Unfortunately there may be no way to instruct Shark about that.

   It also sometimes shows the caller as a child of the callee, which 
may be
due to closures appearing to be part of the caller?

> Agreed.  It'd be good to have something that worked with Shark (there
> are ways of controlling Shark remotely, e.g.:
>
>    (unwind-protect
>     (progn
>      (start-shark-profiling-session)
>      (long-computation))
>     (stop-shark-profiling-session))
>
> which might be a little better than trying to press Control-Escape 
> quickly
> enough), and there are also ways of accessing the kernel profiling
> facility directly.

   Does this really matter?  The process should be mostly sleeping when 
it's not
executing user code, so that shouldn't get charged against it, right?  
... But I'll
look into how to do that.

   It's almost certainly better to use Shark than to use the kernel 
profiler
directly.

   Here's the symbols that turned up with identical addresses:

common-lisp_symbol-macrolet
0x02000424
0x02000448
}
{
common-lisp_throw
0x02000424
0x02000448
}

   Also at this address are:

common-lisp_locally
common-lisp_catch
common-lisp_load-time-value
common-lisp_multiple-value-call
common-lisp_return-from
common-lisp_let
common-lisp_go
common-lisp_macrolet
common-lisp_multiple-value-prog1
common-lisp_let*
common-lisp_if
common-lisp_setq
common-lisp_flet
common-lisp_eval-when
common-lisp_the
common-lisp_unwind-protect
common-lisp_progn
common-lisp_labels
common-lisp_progv
common-lisp_function
common-lisp_quote
common-lisp_tagbody
common-lisp_block

... these are all builtins, so there would be no mystery if it were 
just these.  But there's
user functions that have the same address, too:

{
parser__nodes-to-shift
0x02003F64
0x02003F80
}
{
parser__nodes-to-reduce
0x02003F64
0x02003F80
}
[30 more symbols in that package, including all the ones I actually 
want to profile]
common-lisp_open-stream-p
common-lisp_make-instances-obsolete
common-lisp_stream
common-lisp_simple-condition-format-arguments
common-lisp_streamp
common-lisp_arithmetic-error-operands
common-lisp_unbound-slot-instance
common-lisp_package-error-package
common-lisp_echo-stream-output-stream
common-lisp_debug
common-lisp_input-stream-p
common-lisp_type-error-datum
common-lisp_two-way-stream-input-stream
common-lisp_output-stream-p
common-lisp_stream-error-stream
common-lisp_class-name
common-lisp_echo-stream-input-stream
common-lisp_print-not-readable-object
common-lisp_simple-condition-format-control
common-lisp_arithmetic-error-operation
common-lisp_type-error-expected-type
common-lisp_stream-element-type
common-lisp_two-way-stream-output-stream
common-lisp_function-keywords
common-lisp_cell-error-name
common-lisp_method-qualifiers
common-lisp_broadcast-stream-streams
common-lisp_stream-external-format
common-lisp_interactive-stream-p
common-lisp_concatenated-stream-streams
common-lisp_file-error-pathname
common-lisp_synonym-stream-symbol

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sharktest.lisp
Type: application/octet-stream
Size: 3262 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20050410/59eeb0ef/attachment.obj>
-------------- next part --------------



-- Dan Knapp