[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[aspectj-users] Re: Why are you using LTW?
|
Hi Simone,
I do not think the aspectj load-time weaving is at all suitable in the enterprise context unless you are using bytecode caching technology especially if the instrumentation is covering a significant degree of the code base which is what we must do for performance monitoring and runtime request/state diagnostics.
Using the plain vanilla aspectj javaagent we have seen application server startup times treble which when you consider that some application servers startup up in minutes (2-3) is simply intolerable. With our javaagent fronting the aspectj weaver on second startup the overhead is significantly less depending on the degree of instrumentation but lets say it is not at all noticeable which cannot be said for plain vanilla version. Caching also ** greatly ** reduces the footprint of the runtime as we can avoid going to the weaver except for the initial class load event for every new class loader (to allow scanning of aop.xml). It is also worth noting that with our caching technology we can use the same cached bytecode across class loaders (which is a very common occurrence with temporary class loaders) as our identification mechanism is to some degree distinct for the actual class loader hierarchy via selective fingerprinting with is extremely efficient.
We also use the cache to visualize the aop runtime within our management console and customers also have a filtering mechanism which fronts the cache so they can experiment with various degree of instrumentation coverage without getting hit with the weaving overhead which by the way is still a significant performance issue today relative to other things we do.
Kind regards,
William
Date: Mon, 16 Feb 2009 17:58:14 +0100
From: Simone Gianni <simoneg@xxxxxxxxxx>
Subject: Re: [aspectj-users] Re: Why are you using LTW?
To: aspectj-users@xxxxxxxxxxx
Hi William,
I've been working on a cache for load time weaved bytecode to preserve
it between invocations. I'm not currently actively working on it because
the performance benefit I was getting out of it was not significant.
Basically, the time it takes to check if there is a cached bytecode, if
the originating .class has changed, or if any aspect has changed (cause
checking if the actual change influences or not a certain class is too
heavy to determine) was often much more than simply sending the bytecode
to the weaver.
There are just a few cases where this time is by far lower, but this
advantage gets hidden by all the other checks .. as it often happens in
many caching systems :)
Equinox Aspects also developed a caching classloader for AspectJ. In the
corner case described there (a tracing aspect tracing each and every
class in the Eclipse system), both Equinox Aspects and my implementation
do obtain huge performance gain, but I made no tests on their
implementation on less corner cases, like a system where aspects are
each one weaving a few classes, and one of these classes has changed
between two restarts. No matter what, their code is better than my
experiment :)
Also, in my case, there are a number of other variables at play, like
other enhancers : we also have load-time OpenJPA enhancement, and
(during tests) compile time Cobertura enhancement. For OpenJPA
enhancement the same problem occurs, when dealing with very big beans,
with lots of relations and so on, the benefit of caching is interesting,
while in other cases it is counterproductive.
Obviously, using a more efficient caching system (caching algorithm,
better code and so on) can change the situation, but I had no time to go
further in this experiment.
Simone
