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

Reply via email to