====== Cache Evaluation Aspect ======
In the previous section we reviewed how to add a cache to our Fibonacci class. Now that we have the cache, a good question that may arise is: how effective is the cache?. In this section we will se how to define a new aspect: a cache evaluation aspect; that will monitor the execution of another aspect: the cache aspect.
First, we need to define how we are going to measure the cache efectiveness. The alternative we will take is to compare how many times the get method was called and how many times the cache aspect called proceed (this represents a cache miss). Then, we can calculate the cache efectiveness with the following formula:
cache efectiveness (%) = (theCalls - theMisses) / theCalls) * 100
That represents the percentage of cache hits ever the total get invocations.
As we have already developed a cache aspect, we will reuse its code (the version we chose is the one that uses the Fibonacci instances to hold the cached values):
SMetaobject theSMO = new CacheElementsSMO();
SLink theSLink = API.links().createSLink(
new NameCS("reflex.examples.fibonacci.app.Fibonacci"),
theSMO
);
Hookset theHookset = new PrimitiveHookset(
MsgReceive.class,
new NameCS("reflex.examples.fibonacci.app.Fibonacci"),
new NameOS("get")
);
MODefinition theMO = new MODefinition.SharedMO(new GlobalCacheHandler());
BLink theCacheLink = Links.get(theHookset, theMO);
theCacheLink.setControl(Control.AROUND);
theCacheLink.setCall(Control.AROUND, GlobalCacheHandler.class.getName(), "lookCache",
new Parameter[]{
Parameter.CONTEXT_OBJECT,
new StdParameters.IndexedArgument(0),
Parameter.CLOSURE
});
(A detailled description of this code can be found in the previous [[Cache Aspect|section]])
The metaobject we will use to record the statistics is defined this way:
public static class EvalCacheMO{
private int itsCalls = 0;
private int itsCacheMisses = 0;
public void enterGet(){
//record that the get method was called
}
public Object cacheMiss(IExecutionPointClosure aClosure){
//record that the cache failed and proceed
}
public int getCacheMisses(){
return itsCacheMisses;
}
public int getCalls(){
return itsCalls;
}
}
As you can see, it only holds the two values representing the number of calls to the get method and the number of cache misses. We will review now the how the methods enterGet and cacheMiss are invoked and what they do in their bodies.
First, the metaobject definition:
EvalCacheMO theEvalCacheMO = new EvalCacheMO();
MODefinition theEvalMO = new MODefinition.SharedMO(theEvalCacheMO);
Now, to make the enterGet method be called, we put a link with ''BEFORE'' at the get method:
BLink theEnterGetLink = Links.get(theHookset, theEvalMO);
theEnterGetLink.setControl(Control.BEFORE);
theEnterGetLink.setCall(Control.BEFORE, EvalCacheMO.class.getName(), "enterGet");
This code is self-explanatory: It declares a link, with ''BEFORE'' control, using the hookset that matches the get method, that calls the ''enterGet'' method is called without arguments.
Now, and this is the difficult part, we need to make the ''cacheMiss'' method be called:
BLink theCacheMissLink = Links.get(theHookset, theEvalMO);
theCacheMissLink.setControl(Control.AROUND);
theCacheMissLink.setCall(
Control.AROUND,
EvalCacheMO.class.getName(),
"cacheMiss",
Parameter.CLOSURE)
);
Here we create a link, with ''AROUND'' control: it will replace the original operation, in our case, the get method. And when the hookset is reached, the cacheMiss method is called with a closure as parameter. To understand this, let us make a resume of the behavioral links we have at the moment:
* theCacheLink: ''AROUND'' control
* theEnterGetLink: ''BEFORE'' control
* theCacheMissLink: ''AROUND'' control
The first two links can be composed without problems: first behavior assosiated with ''theEnterGetLink'' is executed, then the behavior assosiated with ''theCacheLink''.
But in this case, wo have two links with ''AROUND'' control, then, [[A Brief Introduction to Around Metaobjects|composition rules]] must be specified by the developer.
In our case we want the ''cacheMiss'' method to be invoked when the cache aspect invokes ''proceed'' over its closure. This is exactly what the [[http://reflex.dcc.uchile.cl/svn/base/trunk/src/reflex/api/compose/Wrap.java|Wrap]] rule does: it creates a chain in the execution flow conditioned to the execution of proceed by the previous metaobject in the chain.
Then, there is only one configuration instruction remaining:
API.rules().addRule(new Wrap(theCacheLink, theCacheMissLink));
{info}
The code above specifies that the ''theCacheLink'' will wrap ''theCacheMissLink''. {info}
Finally, we add a shutdown hook at the virtual machine level to print the cache statistics right before the end of the program (in a real application, the EvalCacheMO instance can be stored in a way that statistics can be printed at any time):
Runtime.getRuntime().addShutdownHook(new Thread(){
public void run(){
int theCalls = theEvalCacheMO.getCalls();
int theMisses = theEvalCacheMO.getCacheMisses();
System.out.println("------ Cache Evaluation ---------");
System.out.println(" Method invocations : " +
theCalls);
System.out.println(" Cache misses : " +
theMisses);
System.out.println(" Cache effectiveness: " +
((theCalls - theMisses) * 100.0 / theCalls) + "%");
System.out.println("---------------------------------");
}
});
The complete code of this example is [[http://reflex.dcc.uchile.cl/svn/base/trunk/src/reflex/examples/tutorial/CacheEvaluationAspect.java|here]]. To run it, the command is:
Windows
%java -classpath
"lib\javassist.jar;build\reflex-core.jar;build\reflex-examples.jar"
reflex.examples.tutorial.CacheEvaluationAspect
Linux
%java -classpath
"lib/javassist.jar:build/reflex-core.jar:build/reflex-examples.jar"
reflex.examples.tutorial.CacheEvaluationAspect
If everithing went ok, the output should be something like:
The fibonacci[5] is 5
The fibonacci[6] is 8
------ Cache Evaluation ---------
Method invocations : 20
Cache misses : 13
Cache effectiveness: 35.0%
---------------------------------
You can see here that the effectiveness of our cache strategy is 35%. Not so bad ;-).