Description Andrew Clement 2005-01-07 05:30:30 EST

Request from Larry Zhou ("Larry Zhou" <lzhou@acsera.com>) on the aspectj-dev list:
---------
Email#1:
We have been using AspectJ successfully in our development. AspectJ helps us a
great deal. Thanks. 
We had this memory issue with AspectJ, since every JavaClass instance was kept
live all the time. To put it in real number, for example, to start weblogic app
server 8.1.3 for integration, the extra memory usage by AspectJ was about 150M
to 180M. 
We would like to request the following changes for modifiers in
BcelObjectType.java, ( No functionality change at all ) 
1) first 15 private data members changed from private to protected 
2) constructor changed from package access to protected. 
3) method getJavaClass changed from package to public. ( Even setJavaClass is
public ) 
That way, we can subclass BcelObjectType, make it MyBcelObjectType, then kill
this object when appropriate due to our own way of using AspectJ, we are able to
cut the memory usage by 90% to around 15M now. 
Let me know if you have any questions about my request. 
Thanks a lot, 
Larry 
----
Email#2:
First, our goal is to use AspectJ directly from jar files, make no code changes
at all. Nowadays, what we do is get the source code, make the change and then
build & use the jar.
 
Second, our change here is all about memory. We basically want to have a
destructor-like thing in BcelObjectType, so we can reclaim the majority of
memory back, even BcelObjectType instance is still live there,  particularly we
need to make sure the ref to JavaClass is nullified, since that is the big
memory hog.
finishedWith seems to be a perfect fit. But unfortunately, everything is
commented out there. so we need to implement finishedWith in MyBcelObjectType to
do clean up.
If in the future, all things in finishedWith are uncommented, we don't need the
1) from my original request list anymore, since we can call it directly.
 
Maybe another way to substitute my 1) is to make protected method dispose()
which nullify every data member of BcelObjectType.
 
public void finishedWith() {
// dispose();
}
 
protected void dispose() {
  javaClass = null;
 ... = null;
 
...  = null;
}
 
but we still need methods/fields/interfaces/isObject to be protected, so they
can be accessed from subclass.
 
Third, our own way of using it. In our situation, we know when a particular
BcelObjectType is not needed anymore.
so we can make it a ghost one, that is no superclass, no interfaces, no
methods/fields.
like this:
isObject = true; // means superclass = null;
interfaces = ResolvedTypeX.NONE
fields/methods = ResolvedMember.NONE;
 
Of course, every other data member is null as well. By doing this, we reclaim
the memory back.
 
 
I hope these help you. Let me know if you have more questions.
 
Thanks,
Larry
----