Proposal: Fully Concurrent ClassLoading

David Holmes david.holmes at oracle.com
Mon Dec 10 04:03:29 UTC 2012


Hi David,

On 7/12/2012 1:06 AM, David M. Lloyd wrote:
> 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.

That sounds promising. Are you in a position to try out this proposal on 
a testbed with your app server?

> 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.

To be clear, in this proposal defineClass, at the VM level 
(SystemDictionary::find_or_define_instance_class), acts as a 
defineClassIfNotPresent, and simply returns the class that has already 
been defined if a race occurs.

> I'm very glad to see that Mr. Holmes has taken this initiative and found
> solutions to the various stumbling blocks.

This still requires extensive validation but I'm hopeful that this will 
at least ameliorate the situation with the JDK's own classloaders, and 
hopefully enable others to utilise fully concurrent loaders.

Thanks,
David




More information about the core-libs-dev mailing list