Proposal: Fully Concurrent ClassLoading
David Holmes
david.holmes at oracle.com
Tue Dec 11 05:18:10 UTC 2012
David,
Many thanks for trialling this so promptly!
Do you have any suggestions for what instrumentation you would like to
see accompany this?
David
On 11/12/2012 1:41 PM, David M. Lloyd wrote:
> On 12/10/2012 06:36 PM, David Holmes wrote:
>> On 10/12/2012 11:53 PM, David M. Lloyd wrote:
>>> On 12/09/2012 10:03 PM, David Holmes wrote:
>>>> 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?
>>
>> Please apply the patches from the webrevs here:
>>
>> http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.hotspot/
>> http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.jdk/
>>
>> They should apply to a jdk8 or tl forest. (And I hope I didn't mess
>> something up generating the webrev ;-) )
>
> Well, I've just gotten everything working and done some cursory testing
> on a startup of an "empty" JBoss AS 7 instance, and then reviewing the
> metrics reported by our class loader. Our timing metrics are not really
> great for general-purpose benchmarking (for various uninteresting
> reasons), but I can at least get enough information to know everything
> is working more or less as expected:
>
> On JDK 6 with our "unsafe" lockless modification, we're typically
> loading 4707 classes, and I'm seeing anywhere from 0 to 5 define races
> that were automatically resolved.
>
> On JDK 7 using the standard registerAsParallelCapable() mechanism, we
> are loading 4711 classes and I'm seeing 35-50 define races that were
> automatically resolved - the overhead of locking starts to come to the
> fore I think.
>
> On JDK 8 with your patches, we are loading around 4750 classes and there
> are, as expected, 0 define races (I believe, however, that we're getting
> a false count though whenever defineClass() returns an already-defined
> class - it would be nice if there were *some* way to detect that this
> happened).
>
> On our class loader implementations, I'm initializing this way:
>
> static {
> try {
> ClassLoader.registerAsFullyConcurrent();
> } catch (Throwable ignored) {
> try {
> ClassLoader.registerAsParallelCapable();
> } catch (Throwable ignored2) {
> }
> }
> }
>
> The debugging message confirms that our class loaders are successfully
> registered as fully concurrent, and the fact that it doesn't hang or
> crash on JDK 7 indicates that they are still properly being registered
> as parallel-capable on that platform.
>
More information about the core-libs-dev
mailing list