| Re: [ajdt-dev] Profiling LTW... initial notes |
Please respond to AspectJ Development Tools developer discussions <ajdt-dev@xxxxxxxxxxx>
Sent by: ajdt-dev-bounces@xxxxxxxxxxx
To:
"'AspectJ Development
Tools developer discussions'" <ajdt-dev@xxxxxxxxxxx>
cc:
Subject:
[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 we’re 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 Matthew’s 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 Matthew’s
suggestion of replacing BCEL ClassFile’s 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
isn’t really a giant array that’s 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 JSP’s:
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)
_______________________________________________
ajdt-dev mailing list
ajdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ajdt-dev