3
Why Redesign MPI? The current design does not scale well –SData is cluttered with unrelated fields and will be even more so when new events and data is added –Extending SData to support more than 32 data types is clumsy –Event selectivity model fits only call-graph events Does not allow different selectivity function callback prototypes Usability –Implicit grouping of events (for selectivity and enable/disable) is documented but not reflected in the formal API –The DataRequest mechanism is complex Function arguments arent natural –.NET and Java specific extensions are not cleanly separated This issue has been addressed separately and is not part of this design

4
Requirements Support multiple selectivity models for events Event handlers should work with event- specific data –Should include only relevant data items Selectivity and Enable/Disable operations should be applied to groups of related events and not to a specific event –e.g. Call Graph events, Heap events

6
Events (1/2) Martini provides information to profilers through a publish- subscribe event model Clients handle events by implementing Event Observers and registering them with the Martini runtime –A specific MPI Event Observer interface is defined for each event All Event Observer interfaces derive from a generic IEventObserver interface –The interface defines a minimal set of shared operations EventDataTypes() –specifies the data items to send with the event –The generic interface does not define a HandleEvent callback Each Event Observer interface defines an event-specific HandleEvent callback function HandleEvent callbacks differ in their event data type argument These callbacks are used by MPI to dispatch the event to the client

7
Events (2/2) An observer interface for the New Method event Each event handler is represented by a specific interface. To respond to an event, the client implements and registers the Observer which represents the event it is interested in An observer interface for the Object Free event best seen in slide show mode

8
Event Groups (1/2) Event Groups enables some operations to be applied on a group of events rather than on individual events –Groups are not new to MPI. In the previous version they were implicitly defined and documented, but the concept was not reflected in the API definition –Examples Event selectivity defined for the Method Enter event is automatically applied to the New Method and Method Leave events Enabling (disabling) the Method Enter event automatically enables (disables) the New Method and Method Leave events In MPI v2, related events are explicitly grouped together –These groups are hard-coded in the API. –Each group is identified by a unique name (defined by an EEventGroup enumerator). –Enabling/disabling events and setting event filter operations are defined for event groups, rather than for individual events

10
Event Filters (1/2) Filters define the selectivity criterion for events –Associated with Event Groups –Applied to all events in the group –Decoupled from Event Observers The event selectivity is not tied to a specific event Clients define filters by implementing Event Filter interfaces, and registering them with MPI using a specific API (SetEventGroupFilter) –Each Event Group has a corresponding Filter interface which defines a ShouldNotify() operation. The signature of this operation is specific to each group. –ShouldNotify() is the callback used by MPI to query the client for selectivity criterion (for example, during BCI for generating Method Enter/Leave events)