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 16:05:21 GMT
I suppose we could make the ClassNotFoundException class a static class, give it
a transient reference to the IModule and make sure the message is extracted when
the Exception is serialized.
Thoughts ?

On Mon, Feb 25, 2008 at 4:47 PM, Dale Peakall <dale.peakall@oclc.org> wrote:
> These patches do have the problem that exceptions are supposed to be
>  Serializable - and IModule is not Serializable.  I don't know if the
>  information necessary to construct the message is Serializable and can
>  be quickly extracted from the module definition - given the apparent
>  run-time cost of the method I suspect not.
>
>
>
>  Stuart McCulloch wrote:
>  > On 25/02/2008, Guillaume Nodet <gnodet@gmail.com> wrote:
>  >
>  >> 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.
>  >>
>  >
>  >
>  > cool, could you raise a JIRA issue and attach the combined patch - thanks
>  >
>  > 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/
>  >>
>  >>
>  >
>  >
>  >
>  >
>
>



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

Mime
View raw message