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

[Scott Marlow (JIRA)]

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

Scott Marlow commented on JASSIST-163:
--------------------------------------

How are the elements in methods sort of final fields?  

I think that final fields have to be initialized during the referencing class constructor or class static initializer.

Your change looks good to me.  I'll paste the additional lines (from your change) below for others to also review.

{code}
    /**
     * Finds two methods specified by the parameters and stores them
     * into the given array.
     *
     * @throws RuntimeException     if the methods are not found.
     * @see javassist.util.proxy.ProxyFactory
     */
    public static void find2Methods(Object self, String superMethod,
                                    String thisMethod, int index,
                                    String desc, java.lang.reflect.Method[] methods)
    {
        /* Once methods[index] and methods[index + 1] are set to non-null, 
         * then their values never change.
         */
        if (methods[index] == null || methods[index + 1] == null) {
            Method m1 = thisMethod == null ? null
                                           : findMethod(self, thisMethod, desc);
            Method m0 = findSuperMethod(self, superMethod, desc);
            synchronized (methods) {
                if (methods[index] == null) {
                    methods[index + 1] = m1;
                    methods[index] = m0;
                }
            }
        }
    }
{code}

If a another thread attempts to read methods[index] or methods[index+1], they will either see one of the fields set to null or both fields initialized.  If either field is null, the thread will synchronize on methods and then only set both fields if they are still null.  
                
> 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