[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ajdt-dev] Profiling LTW... initial notes
|
Just to followup on the earlier discussions (and taking Wes hint to move to
aspectj-dev so as not to overwhelm/alarm newcomers without background on
what were doing in tuning the first release of classloader-aware LTW):
I ran a JVMTI profiler on my Tomcat startup with the Glassbox Inspector
using a Sun VM (gladly the two jvmti agents composed appropriately so it
worked). This confirmed Matthews claim that BCEL objecs are the primary
memory consumer. They worse than double memory use when you have shared
objects and already appear bulkier than the in-memory representation of
objects. I think memory use could be dramatically improved with Matthews
suggestion of replacing BCEL ClassFiles with defined classes, say by
weaving into ClassLoaders after the values are defined (although how can you
replace duplicates in child ClassLoaders?).
Memory on start up:
The profiler reports the total retained size of live objects on start up as
~33 million bytes. I believe this is simply misestimating array sizes since
the VM is using 109 MB of heap and 17 MB of non-heap after forcing a GC
However, the information it reports is still interesting (assuming there
isnt really a giant array thats being vastly undercounted!)
Of this the 1500 org.aspectj.apache.bcel.classfile.JavaClass object
instances hold on to almost 20 mm bytes: 6 mm are in methods. This supports
the theory that the Bcel objects are the core issue: these objects are
pretty big and are fairly even distributed in size.
Another 3 mm go to other purposes.(about ½ of this is loading the AspectJ
weaving system).
There are 78 instances of BcelWorld in my fairly small instance of Tomcat
(loading just a few sample apps), although basically 2 of them account for
most of the objects.
Most of the rest of the memory is held by Catalina (about 8.5 mm), which I
believe represents code & resources loaded normally.
Memory after viewing about 8 JSPs:
Heap usage has grown to 119MB. Interestingly the profiler now reports 33 mm
bytes in use (i.e., it tracked all the additional heap use).
Bcel.classfile.JavaClass instances now hold on to 27 mm bytes. So again, the
primary memory user is BCEL objects (no surprise).
Tomcat is now using 11.5 mm bytes fully another 3mm bytes! This second
order effect is worth investigating: does Tomcat normally use this much
extra memory when loading new JSPs?!
Start up TIME analysis:
I also found that there was a significant amount of the time spent starting
up in Aj.preProcess (56%) and also 34% in refreshing the Spring Web app
context (I suspect this has something to do with oversynchronization)
I am hoping using concurrent (weak) maps would help reduce contention. Here
are some of the most notable slow methods. More analysis is needed, but it
seems that BCEL is slower at loading bytes from disk, making it a pretty big
hit on start up times...
Total time: 195s
makeJavaClass 33s of which 98% is parsing ClassParser -> reading
getResource: 23s of which 80% came from ClassLoaderWeavingAdaptor.accept and
20% from World.resolve
lookupJavaClass: 24s of which 75% came from ClassLoaderWeavingAdaptor.accept
and 25% from World.resolve
readUTF 16s: 11s is in bcel.utilitymakeJavaClass, 5s in
CLRepository.loadClass
Object.<init> 29s = 15% in init (largely in BCEL object construction)
