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 Tue, 26 Feb 2008 20:04:59 GMT
That surely would be the easiest and cleanest solution.

On Tue, Feb 26, 2008 at 8:55 PM, Richard S. Hall <heavy@ungoverned.org> wrote:
> The "diagnoseClassLoadError()" method was always intended to be purely
>  for debugging purposes. It seems like it would be easier to just disable
>  it if the framework log level is not at least at DEBUG.
>
>  -> richard
>
>
>
>  Guillaume Nodet wrote:
>  > I've raised a JIRA with a patch that should accomodate this problem.
>  > I must admit this is not the cleanest thing, but given a 95%
>  > performance boost in my case
>  > I'd be happy it it is included :-)
>  > See https://issues.apache.org/jira/browse/FELIX-500
>  >
>  > On Mon, Feb 25, 2008 at 5:05 PM, Guillaume Nodet <gnodet@gmail.com> wrote:
>  >
>  >> 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/
>  >>
>  >>
>  >
>  >
>  >
>  >
>



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

Mime
View raw message