Project

General

Profile

Actions

Feature #3291

closed

Speed up CIF essentially

Added by Evgeny Novikov over 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
High
Category:
-
Start date:
07/26/2012
Due date:
% Done:

0%

Estimated time:
Published in build:

Description

Recently we have noticed that CIF processes a huge amount of pointcuts for a large program inefficiently. This almost doesn't depend on a representation of pointcuts: either in separate advices or in one advice which join pointcuts with help of '||'.
I think about this and profile CIF a bit. So there are about 20 thousands of ldv_match_cp() calls and about 50 millions of repeated calls of this function for driver usb/serial/aircable.c and model 119_1a. It means that 20 thousands join points in the driver were analyzed by CIF. But, because of the composite pointcut represents disjunction of about 5 thousands of primitive pointcuts, CIF has checked each of join point against 5 thousands of primitive pointcuts. Generally speaking, this should be done, since the given join point can be matched with one of this primitive pointcut. But this time CIF works inefficiently! I guess, that the most of join points analyzed aren't function call, while the model huge composite pointcut consists just of primitive pointcuts on function calls.
To optimize CIF, we can:
  • Derive some information for the given composite pointcut on the basis of its primitive pointcuts at the aspect parsing stage. For instance, we can say that the given composite pointcut is disjunction of just primitive pointcuts on function calls. Then when we will analyze some join point that isn't a function call we will be able quickly understand whether the given composite pointcut can match it or not. With careful aspect developing (e.g. if one will combine all similar primitive pointcuts together with help of disjunction) it will speed up CIF essentially.
  • Analyze join points distribution. I guess that the most of join points are related with variable manipulations. But we haven't models that use set and get poincuts (as well as other associated with variable manipulations)! Thus we can simply omit analysis of variable manipulations in CIF (conditionally). However this approach may be absolutely useless if one will use at least one set or get pointcut in general kernel model that will be included in each rule model.
  • Use both these optimizations.

Files

cpcihp_zt5550.c.macroinstrumented.bz2 (167 KB) cpcihp_zt5550.c.macroinstrumented.bz2 Evgeny Novikov, 10/16/2013 04:03 PM
0123.aspect.i.tar.xz (1.02 MB) 0123.aspect.i.tar.xz Evgeny Novikov, 02/01/2014 10:34 AM
callgrind.out.4746 (992 KB) callgrind.out.4746 Ilya Shchepetkov, 02/04/2014 04:05 PM

Related issues 3 (1 open2 closed)

Related to C Instrumentation Framework - Bug #372: Aspectator and C-backend don't worry about memory releasingClosedEvgeny Novikov08/05/2010

Actions
Related to C Instrumentation Framework - Bug #3323: Internal compiler error in AspectatorClosedFedor Kozlov08/03/2012

Actions
Blocks Linux Kernel Safety RuleDB - Feature #2606: 119: probe functions should not return -EINTROpenVladimir Gratinskiy03/17/2012

Actions
Actions

Also available in: Atom PDF