Proposal: Fully Concurrent ClassLoading

[David M. Lloyd]

No problem.  What do you mean by "instrumentation"?

On 12/10/2012 11:18 PM, David Holmes wrote:
> 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.
>>


-- 
- DML