Proposal: Fully Concurrent ClassLoading
David M. Lloyd
david.lloyd at redhat.com
Mon Dec 10 13:53:45 UTC 2012
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:
>>> 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?
More information about the core-libs-dev