felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Performance problems in classloading
Date Mon, 25 Feb 2008 15:18:51 GMT
Thanks Stuart.  The exception was catched and the getMessage method
called, so I've
hacked a bit more, but the following patch seems to work great for me.

Index: src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
===================================================================
--- src/main/java/org/apache/felix/moduleloader/ModuleImpl.java
(revision 630863)
+++ src/main/java/org/apache/felix/moduleloader/ModuleImpl.java (working copy)
@@ -147,10 +147,17 @@
         }
         catch (ClassNotFoundException ex)
         {
-            m_logger.log(
-                Logger.LOG_WARNING,
-                ex.getMessage(),
-                ex);
+            // Diagnosing the class loader error is very costly, so only
+            // perform this call (indirectly through ex.getMessage())
+            // if necessary.
+            // See R4SearchPolicyCore#findClass
+            if (m_logger.getLogLevel() >= Logger.LOG_WARNING)
+            {
+                m_logger.log(
+                    Logger.LOG_WARNING,
+                    ex.getMessage(),
+                    ex);
+            }
         }
         return null;
     }
Index: src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
===================================================================
--- src/main/java/org/apache/felix/framework/searchpolicy/R4SearchPolicyCore.java
      (revision 630863)
+++ 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,13 @@
         }
         catch (ClassNotFoundException ex)
         {
-            String msg = diagnoseClassLoadError(module, name);
-            throw new ClassNotFoundException(msg, ex);
+            throw new ClassNotFoundException("", ex)
+            {
+                public String getMessage()
+                {
+                    return diagnoseClassLoadError(module, name);
+                }
+            };
         }

         // We should never reach this point.


On Mon, Feb 25, 2008 at 3:37 PM, Stuart McCulloch
<stuart.mcculloch@jayway.net> wrote:
> 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
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/

Mime
View raw message