You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2013/08/31 16:35:39 UTC

[Bug 55511] New: Reduce contention on WebappClassLoader

https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

            Bug ID: 55511
           Summary: Reduce contention on WebappClassLoader
           Product: Tomcat 8
           Version: 8.0.0-RC1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: jasonk@bluedevel.com

Created attachment 30789
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=30789&action=edit
Patch diff to WebappClassLoader to enable concurrent read of cache

As part of this patchset -
http://svn.apache.org/viewvc?view=revision&revision=927565 - the loadClass()
method was marked synchronized, which means all class loading in a web
application is fully serialized against the class loader.

There are a number of libraries which call loadClass repeatedly (eg some
versions of Saxon XSLT engine).

Attached is a patch that alleviates some of the pressure by converting the
local cache from Hashmap to a ConcurrentHashMap and moving the cache lookup
outside the synchronized block. Thus, all class loading against this CL should
now operate concurrently. Anything requiring the superclass or parent loader is
still synchronized.

Let me know if you need some additional test metrics etc.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55511] Reduce contention on WebappClassLoader

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #30789|0                           |1
           is patch|                            |

--- Comment #2 from Mark Thomas <ma...@apache.org> ---
Comment on attachment 30789
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=30789
Patch diff to WebappClassLoader to enable concurrent read of cache

Mark as patch

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55511] Reduce contention on WebappClassLoader

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

--- Comment #7 from Jason Koch <ja...@bluedevel.com> ---
Just adding an additional comment - trailing from my blog - in case somebody
else comes across this and wants to open it up.

In my opinion this will become an issue for someone in the future, but I wasn't
able to hook up a suitable test to prove it. Hopefully somebody else can.

http://fasterjava.blogspot.com/2013/08/caching-classes-from-classloader.html
=====
Hi Ryan - totally agree with you. TC classloader is definitely a source of
contention, but I was unable to come up with a real-world scenario where it
affected throughput.

If you have enough of a test bench you can probably re-run the tests and see
how it goes, I'd be keen to hear about it. I assume you are looking at Tomcat?

What I found is that when I used the default Tomcat classloader in a real world
scenario (about 2000req/sec incl business logic, db query, output transform,
etc), changing the classloader did not significantly affect the req/sec rate.
It only changes it when running under the profiler or under contrived examples
- eg calling loadClass in a tight loop. I don't have the test bench to drive
enough load onto the server - I was able to saturate the NIC before running out
of CPU.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55511] Reduce contention on WebappClassLoader

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

--- Comment #5 from Jason Koch <ja...@bluedevel.com> ---
Having a little trouble building an isolated minimal case benchmark.

Background - my app, when profiled, shows ~30% of response time under load is
due to the classloader locking. App under profile is Java 6, Tomcat 6, on SPARC
but code has not changed since that time. My attempt to repro the issue with a
simple servlet that calls loadClass as the only item in the servlet does not
show contention. 

Possible causes - falsely showing this issue in my app, is not an issue under
Tomcat 8 for other reasons, attempting to repro on x86, can't drive enough work
onto the x86 server that I have (bandwidth saturated), issue may not really be
with WebappClassLoader but some parent item.

When I have applied a full CachingWebappClassLoader by subclassing it showed
significant benefits but I was unable at the time to hook up a JHM benchmark in
WebappClassLoader, seems to have a lot of dependencies with the container.

Here some additional results for a full subclass of WebappClassLoader - I made
a possibly flawed assumption that the reason WebappClassLoader with CHM did not
show issues was because I was not loading classes from JARs registered with
that loader (but instead loading classes via WebappCL to the system loader) 

http://fasterjava.blogspot.com.au/2013/08/caching-classes-from-classloader.html

Will continue investigating.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55511] Reduce contention on WebappClassLoader

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

--- Comment #3 from Mark Thomas <ma...@apache.org> ---
The patch doesn't apply cleanly with either Eclipse (which can be fussy) or
TortoiseSVN (which is usually quite tolerant).

I'd like to see some performance numbers before considering this patch given
the problems any solution that didn't sync the whole method has demonstrated in
the past.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55511] Reduce contention on WebappClassLoader

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

--- Comment #4 from Konstantin Kolinko <kn...@gmail.com> ---
>   @Override
> - public synchronized Class<?> loadClass(String name, boolean resolve)
> + public Class<?> loadClass(String name, boolean resolve)

The method that is overridden here is marked as synchronized in
java.lang.ClassLoader in Java 6. Thus it is synchronized in Tomcat as well.

That method is not synchronized in Java 7, but as far as I remember, you need
to jump through some hoops such as "registerAsParallelCapable()" to make use of
parallel execution. See discussion in bug 48903 (esp. comments 2 and 6).

Discussion in issue 48903 was three years ago when Java 7 was still beta. I am
not aware of what is the current state of affairs in that API.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55511] Reduce contention on WebappClassLoader

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

--- Comment #6 from Jason Koch <ja...@bluedevel.com> ---
Looks like this is a heisenberg-bug actually related to Yourkit. When I've
removed all of it and stripped back to basics, the "contention" impact is
extremely low; it seems YJP agent is hooking the monitor enter / exit with its
own code and triggering misleading results in the profiler.

Happy to have this rejected/closed.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55511] Reduce contention on WebappClassLoader

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

--- Comment #1 from Jason Koch <ja...@bluedevel.com> ---
It's been quite difficult to hook up the classloader in a JHM environment, so
let me know if you need benchmarks and I'll hook some up end to end.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55511] Reduce contention on WebappClassLoader

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55511

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Mark Thomas <ma...@apache.org> ---
Happy to revisit this if a test case is developed that shows a genuine problem.
However, given that - at the moment - such a test case doesn't exist I'm
resolving this as invalid.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org