Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of mcculls@gmail.com designates
 209.85.142.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=Am5l4WSDzDpV/SPwL/dbv12a34UpXyVesr3GRP9DolRkZV6rsJ7tVUuZKvIoj0ze//VPJgUgmdE2Wd/oppjBYV2xKGy3I37wu7NqnjvJ5c+SkmrxNue5IW6qqTY7p0n0yWqoRrMXI1B0Ws0LaYIEqgOWxSuIh1BG0HQ7hErCM0c=
Message-ID: <81f0d9c0802250637g30a3bb61g110780b910e57437@mail.gmail.com>
Date: Mon, 25 Feb 2008 22:37:28 +0800
From: "Stuart McCulloch" <stuart.mcculloch@jayway.net>
Sender: mcculls@gmail.com
To: dev@felix.apache.org
Subject: Re: Performance problems in classloading
Cc: dev@servicemix.apache.org
In-Reply-To: <b23ecedc0802250612q5489a27ayce6c4e80648cfb36@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3084_2974183.1203950248970"
References: <b23ecedc0802250612q5489a27ayce6c4e80648cfb36@mail.gmail.com>

------=_Part_3084_2974183.1203950248970
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 25/02/2008, Guillaume Nodet <gnodet@gmail.com> wrote:
>
> I'm currently working on ServiceMix 4 which uses Felix.\
>
> I have some really important performance problems in classloading.
> When loading JBI applications (they have some very specific
> classloading architecture
> that must be implemented to be JBI compliant), 95% of the time  is
> spent in the following method:
>    R4SearchPolicyCore.diagnoseClassLoadError()
> which is not really acceptable.
>
> The problem is that the classloader is built dynamically and does not
> completely rely on
> OSGi.  For this reason, the classloader of JBI artifacts delegates to
> the parent classloader,
> then looks inside its own jar.  This means there will be lots of
> ClassNotFoundException thrown
> by the parents classloader (ultimately by Felix).
>
> Is there any way to maybe speed / disable the diagnoseClassLoadError
> method call which
> is purely informative ?


we could try a lazy-load approach (ie. only construct the string in the
getMessage method)
for example, you might want to see if the following patch helps, based on
the current trunk:

Index:
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
===================================================================
---
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
(revision 630859)
+++
src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
(working copy)
@@ -178,7 +178,7 @@
         return null;
     }

-    public Class findClass(IModule module, String name)
+    public Class findClass(final IModule module, final String name)
         throws ClassNotFoundException
     {
         try
@@ -191,8 +191,14 @@
         }
         catch (ClassNotFoundException ex)
         {
-            String msg = diagnoseClassLoadError(module, name);
-            throw new ClassNotFoundException(msg, ex);
+            // lazy construction of exception message
+            throw new ClassNotFoundException("", ex)
+            {
+                public String getMessage()
+                {
+                    return diagnoseClassLoadError(module, name);
+                }
+            };
         }

         // We should never reach this point.
@@ -3272,4 +3278,4 @@

         return sb.toString();
     }
-}
\ No newline at end of file
+}

although lazy construction might cause problems if people hold onto
the exception for a long time, but I don't think this is usually the case

I know the design of the JBI classloaders is not really a good fit in
> OSGi, so I will investigate
> a better solution (leveraging more of OSGi classloaders) anyway, but I
> still wanted to report
> the problem.
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>


-- 
Cheers, Stuart

------=_Part_3084_2974183.1203950248970--