Proposal: Fully Concurrent ClassLoading

[David M. Lloyd]

On 12/09/2012 10:03 PM, David Holmes wrote:
> 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?

Sure, I'd love to.  What tree should I build?

-- 
- DML