User development,

A new message was posted in the thread "A few Javassist proxy patches":

http://community.jboss.org/message/529280#529280

Author  : Mark Struberg
Profile : http://community.jboss.org/people/struberg

Message:
--------------------------------------------------------------
Hi!
 
I'm working on Apache OpenWebbeans and we use javassist - so first of all 
thanks for providing it!
 
I found a few issues which are mainly based on the way javassist got used in 
many projects, which caused loss of permgenspace with every invocation. I tried 
to address this with a few patches.
 
The problem is caused by the current javassist usage pattern of calling 
ProxyFactory.createClass().newInstance() which currently (due to the broken 
cache), always creates a new class for the proxy. And once this class gets 
classloaded, you cannot easily get rid of it from the ClassLoaders class map. 
In the worst case the generated proxy class gets registered in the 
SystemClassLoader and can never get freed again. Another problem is that 
setting the default method handler with ProxyFactore.setMethodHandler() will 
store this MethodHandler in a static field, thus the class will hold a 
reference to this MethodHandler - even if it is not used anymore. Thus the 
MethodHandler (and all the instances it references) imo can never get garbage 
collected.
 
There were also a few problems with deserialization, mainly because it did drop 
the assigned MehodHandler and used the DefaultMethodHandler instead. I added 
new bytecode to support MethodHandler serialization along with the 
proxyInstance.
 
To understand my need: instead of creating a fresh proxyClass every time, I 
switched OWB to use the following pattern
 
1.) ProxyFactory.useCache = false; since the current implementation fo the 
internal class cache imo inherently creates mem losses
 
2.) create the ProxyFactory only once and cache this class in our own code:
2.a) ProxyFactory pf = new ProxyFactory()
2.b) pf.setInterfaces(...);
2.c) pf.setSuperclass(...);
2.d) Class proxyClass = pf.creatClass();

3.) create a new proxy instance with it's own MethodHandler by always only 
using the same cached proxy Class for a certain original class
Object proxyInstance = proxyClass.newInstance(); +
((ProxyObject)proxyInstance).setHandler(new BeanMethodHandler(beaninfo));
 
I didn't really need the MethodFilter in my use cases, so we need think about 
where this fits into the picture.
 
Most foundings are explained in my patches available at github
http://github.com/struberg/javassist
 
Those patches are tested with OpenWebBeans and Weld (thanks to David R. Allen), 
but I'm sure there is still room for improvement 
 
One of the areas I'm not 100% sure is deserialization on another VM which may 
already contain other proxy classes of that kind (with different javassist 
name). I now check if the interfaces and the superclass is the same if I found 
a javassist proxyClass with Class.forName on deserialization, maybe there is 
something missing still.
This szenario mainly may concern replication in big clusters, and the behaviour 
of the patched version is of course heavily improved at least.
 
Oh yes, we should really cleanup the pom.xml!
I can volunteer with all the maven stuff too if needed.
 
txs and LieGrue,
strub

--------------------------------------------------------------

To reply to this message visit the message page: 
http://community.jboss.org/message/529280#529280


_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to