Adding capture support to score

[Gedare Bloom]

Hi,

On Tue, Jul 8, 2014 at 3:19 PM, Jennifer Averett
<Jennifer.Averett at oarcorp.com> wrote:
> The attached patches are a starting point for discussions for adding capture support
> to core objects.   We started to write notes based on our discussions but the text
> was harder to follow than just writing some code and commenting on it. It is hard
> to see the impact of "word changes" versus real changes.
>
Is this related to capture engine? if not, there needs to be some
better terminology to avoid confusion.

I find it easier to comment on patches that are sent "in-line", see
instructions on the wiki Git page about using git-send-email.

> The initial cut has one method call per Score Handler with an enumerated
> parameter indicating points of interest.  Most take a thread pointer and
> an object id as arguments which can be interpreted based on the
> event indicated by the enumerated first argument.
>
Why have separate event sets (types) for mutex and semaphore? (I will
say "event set" to mean the points of interest associated with a class
of objects. Thus, your first patch includes 3 event sets, one for
generic Object, one for Mutex, and one for Semaphore.) Most all locks
will have the same kinds of abstract events that affect them.

> Some of the items we would like to discuss:
>
>   1) Should the number of methods be expanded to one method per point of interest?
>
This might make sense, since probably the approach taken requires the
one function handler per event set to determine the source of the
event anyways, so they'll all probably just be implemented as a giant
switch statement. It makes sense to me that there is a specific
function invoked for each kind of event that occurs, and it could help
with debugging since a backtrace makes more sense, and inlining can be
done more aggressively with finer-grained functions. gcc can inline
function pointers under certain conditions, although I forget what
they are off-hand.

I would choose a generic template for the function pointer though,
something like...
typedef void (*_Capture_Event_handler)(_Capture_Event e, Objects_Id
Object, Thread_Control *thread);
Or something similar, if it can be made generic enough to cover the
parameters needed at each "point of interest".

>    Having one method per "event" or doing it this way is a no-win choice. The callout
>   table will grow larger with more entries if we go to one function per event.  More
>   methods will be in the capture engine. But if we stick this way, there is a smaller
>   callout table, fewer capture methods, but the capture methods likely will have some
>   decode logic.
>
Perhaps, or you just need to be fastidious in how many events you
include in an event set. You could also have a catch-all function,
e.g.
  _Capture_Event_handler default;
that can be invoked for when there isn't a specific handler for an
event at some point of interest.

>   2) This design focuses on pass paths for points of interest and ignores failure paths,
>       is this the direction we wish to follow?
>
>   There are potentially LOTS of failure points and the errors will be in the supercore level.
>   Worse, a "try lock" which doesn't get the mutex could end up in a busy loop swamping
>    the capture engine.
>
You may consider reporting only one failure at each point of interest.
For debugging purposes, it probably helps to see failures?

>   3) We think the callout table should be completely populated. The table is either
>     full of methods or not. It is an error not to install a handler for every event.  This
>     simplified checks at run-time.
>
And if I'm only interested in tracking Object allocate/free? I still
need to provide stubs (and suffer overhead) for locks or whatever
other events there are?

>   4) We discussed having the Score own a table with stubs so the calls are always
>   present but that could negatively impact minimum footprint. This only puts a
>   single pointer and code to call. This point is arguable if we stick to the small
>   number of handlers approach. Eliminating the "if table installed" check and always
>   making the subroutine call to a stub MIGHT be better. But we thought avoiding
>   a subroutine call in critical paths was best.
>
If you can figure out how to make gcc inline the function pointer for
this case, it can be practicable since there should be zero-overhead
after optimizations.

That's all I have for now.
-Gedare

> So this is basically some code using one approach for discussion purposes. It
> Is only known to compile and this may not be enough for you to compile it. :)
>
> We want to discuss the design approach and see where to take this.
>
> Jennifer Averett
> On-Line Applications Research
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel