[jboss-jira] [JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency

[Nikita Tovstoles (JIRA)]

    [ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710128#comment-12710128 ] 

Nikita Tovstoles commented on JASSIST-163:
------------------------------------------

Count me biased, but I maintain the approach of eagerly initializing static methods[] - submitted [above|https://issues.jboss.org/browse/JASSIST-163?focusedCommentId=12681065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12681065] is most practical:
* simpler runtime code in generated getters (see before-and-after comparison in the above comment)
* shorter call-chain during getter invocation

My understanding is that the argument for filling methods[] lazily is memory savings. In reality the current approach of lazy methods[] initialization will produce minimal-to-zero memory savings as typically all properties of a proxied class are proxied, and, over the lifecycle of JVM, will be invoked. In other words, after some time methods[] will be fully-initialized in both implementations. 

BTW, Method references in methods[] take up [either 4 or 8 bytes each|http://stackoverflow.com/a/3733242/182808] or 8 or 16 bytes per property (32bit VM vs. 64bit vm; 2 Methods per property). That's 8-16 bytes in allocation *delayed*, not really *avoided*. 
                
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-163
>                 URL: https://issues.jboss.org/browse/JASSIST-163
>             Project: Javassist
>          Issue Type: Enhancement
>    Affects Versions: 3.15.0-GA, 3.16.1-GA
>         Environment: hibernate-core 3.6.10.Final
>            Reporter: Nikita Tovstoles
>            Assignee: Shigeru Chiba
>             Fix For: 3.17.0-GA
>
>         Attachments: blocked-threads.png, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
>         synchronized (methods) {
>             if (methods[index] == null) {
>                 methods[index + 1] = thisMethod == null ? null
>                                      : findMethod(self, thisMethod, desc);
>                 methods[index] = findSuperMethod(self, superMethod, desc);
>             }
>         }
> {code} 
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira