On 12/06/2012 05:35 AM, Alan Bateman wrote:
On 05/12/2012 11:59, David Holmes wrote:
Java 7 introduced support for parallel classloading by adding to each
class loader a ConcurrentHashMap, referenced through a new field,
parallelLockMap. This contains a mapping from class names to Objects
to use as a classloading lock for that class name. This scheme has a
number of inefficiencies. To address this we propose for Java 8 the
notion of a fully concurrent classloader ...
This is a fairly simple proposal that I've written up as a blog entry:
https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
The jdk7 implementation is very unfortunate, it's a pity this wasn't
caught before 7 shipped.
I think the proposal is good, it preserves compatibility, and if there
are loaders calling registerAsParallelCapable now (probably very few)
then it they may be able to change to using registerAsFullyConcurrent
without too much work.
I am tempted to suggest that registerAsParallelCapable should be
deprecated too.
I'm sorry I missed the original post, and I just want to add my
wholehearted support for this idea. Our application server's class
loader implementation can be configured (on certain JVMs) to run in a
lock-free mode and we have seen good performance and memory footprint as
a result on these particular JVMs.
As far as the defineClass concurrent redefine issue goes - our current
implementation simply does a try/catch for redefinition exceptions. If
such an exception occurs, we load the concurrently defined class and
return that. In practice, even with many threads, we would see
relatively few such collisions. But, a tryDefineClass or
defineClassIfNotPresent would be a welcome addition for certain.
I'm very glad to see that Mr. Holmes has taken this initiative and found
solutions to the various stumbling blocks.
--
- DML
