[abc] J-LO

Hi, Oege.

I have done some tests again, and I still have not come to a really good
conclusion.

Meanwhile I am almost 100% convinced that the benchmark I took first was
somehow flawed. I don't know why, but as Pavel pointed out already,
first the memory/performance shape was very unusual and also Pavel had
never seen J-LO running as fast - in fact not even close to that speed.
Hence, I reckon chances are high that something went wrong - whatever
that was.

Still, the benchmark does run faster on my laptop than on Cardinal,
however after I made efforts to get the environments as equal as
possible, it was "only" about a factor of 4 (however still with graphics
being displayed on my machine and not on cardinal). This is still odd,
but my laptop runs Windows XP and hence it could well be that the
Windows VM is far better in performance than the linux one.

So my suggestion would be that if you feel like, you give it another try
on nikko but possibly it's not really necessary. If you don't, just drop
me a line and I will do a shorter run on cardinal (probably 1000
iterations or so) which we could then extrapolate to an estimated
overall runtime.

By the way: When enabling "GC before each measurement", those memory
peaks went away. This coincides much more with the measurements we had
done for our SC paper
(http://bodden.de/n/index.php?option=com_docman&task=doc_download&gid=53
&Itemid=38).

So I guess for the paper the conclusion will just be:

Memory safe? Yes, due to the fact that it was designed to not interfere
with the underlying application because otherwise that would lead
verification results ad absurdum.

Efficient? No, not at all, because it is fully generic and unoptimized.
The only part that is specific to the original formula is in fact the
generated advice that recognizes the events of interest. (opposed to
using a generic aspect that would just match on any joinpoint whatsoever
and then filter dynamically)

Eric

--
Eric Bodden
Sable Research Group, McGill University
Montreal, Canada