Re: [abc-users] Tracematches performance query

Dear Alan,

I would like to apologise for the tone Mr Bodden took, he does by no means
speak for the entire abc team.

Had Mr Bodden bothered to read your example, he would have noted that what he
said does not apply at all. Each partial match is completed within an
iteration of the inner loop, so (note this, Eric) *there is no build-up of
disjuncts or partial matches*.

The behaviour Alan observes is actually far more subtle. It is due to the fact
that in order to guarantee the tracematch semantics, we need to use the same
weak reference for the same object in certain situations
(so-called "PersistentWeakReferences" -- Eric, I suggest you actually read
http://abc.comlab.ox.ac.uk/papers#oopsla2007 where this is explained).

In particular, this means that we maintain a map from objects to associated
weak references. Now, in the normal course of a program, objects expire and
the associated map entries are dropped. In the toy example you have, Alan,
none of the Account objects expire during the course of a program, and so for
each account object we create an entry in a hashmap and an associated weak
reference. Unfortunately, this happens to require 40 MB of heap space.

This is not, technically, a space leak -- if you modify your main program as
shown in the attachment, you will note that the memory usage only increases
during the first iteration over the accounts; the remaining 9 simply reuse
the existing data structures and are faster. You could iterate this as many
times as you want without using *additional* memory, and if an account object
was to expire, the associated bookkeeping structures would be released.

Unfortunately I'm not sure what we can do to optimise such a case, since, as I
mentioned above, we need to use PersistentWeakReferences in order to
guarantee the semantics... I'll think about it, and possibly come up with a
solution -- it seems to me that in certain cases we can avoid using PWRs, but
it will require careful thought.

In a nutshell, currently the tracematch implementation caters for the more
general case where you might use account objects arbitrarily, in which case
we would need the extra book-keeping. I will let you know if I see a way of
improving this behaviour.

Cheers,
- Pavel

On Wednesday 19 March 2008 19:27:54 Eric Bodden wrote:
> > The reason why I asked was because I thought tracematches were designed
> > to be memory safe, therefore its memory consumption should be more or
> > less on par with the hand-coded aspect (as in the benchmarks shown on
> > the paper). Thus an opinion on this matter would be greatly appreciated.
> > Thanks.
>
> They are memory safe. Memory safety means that we don't hold on to
> unnecessary objects. But we certainly hold on to all objects that are
> necessary for a sound computation. The overhead can easily be
> explained by the fact that tracematches use disjuncts to store data.
> Each disjunct represents a partial match and is in itself an object.
> So if you have 100,000 partial matches for 100,000 accounts and in
> fact each Account is such a tiny object that a disjunct takes about
> the same space in memory than quite naturally you require twice as
> much memory.
>
> To us it was always clear that hand-optimized aspects are potentially
> faster and may require less memory. The point is that using
> tracematches you can make much less mistakes (hand-writing a good
> aspect is hard), you can write code much faster and for actual
> programs (not made-up microbenchmarks) get an implementation that is
> almost as fast and memory-efficient as a handcoded aspect.
>
> I suggest actually reading our publications, e.g. this one here where
> we say exactly that:
> http://abc.comlab.ox.ac.uk/techreports#abc-2006-1
>
> Eric