Bug 226084 - NetbinoxLoader needs to be parallel capable
NetbinoxLoader needs to be parallel capable
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Netigso
7.4
All Linux
: P2 (vote)
: 7.3.1
Assigned To: Jaroslav Tulach
issues@platform
bugdb_16324535 73patch2-fixed
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-13 18:55 UTC by stoto79
Modified: 2013-05-16 02:27 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
patch for NetbinoxLoader (1.49 KB, patch)
2013-02-13 18:55 UTC, stoto79
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description stoto79 2013-02-13 18:55:39 UTC
Created attachment 131359 [details]
patch for NetbinoxLoader

In JDK7 parallel classloaders were introduced. NetbinoxLoader extends Equinox's DefaultClassLoader, which is already parallel, but since every subclass of ClassLoader needs to register itself as parallel, NetbinoxLoader is not taking advantage of classloader parallelism, and since Equinox discontinued support for some of the deadlock workarounds they had in place, this exacerbates the issue, hence the P2. 

NetbinoxLoader should be parallel IMHO. I've attached a patch.
Comment 1 Jaroslav Tulach 2013-03-12 15:29:02 UTC
I am struggling to write a test. When debugging org.netbeans.modules.netbinox.NetigsoOSGiActivationVisibleTest (for example), and having a breakpoint at

org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLoadedClass(ClasspathMan
ager.java:477)

it says that isParallelClassLoader is true. May I ask how exactly the problem demonstrates? Which lock is held and should not?
Comment 2 stoto79 2013-03-12 21:46:32 UTC
A classloader is parallel capable if, during the loading of a class, it holds a lock on the entire classloader object. The flag maintained by Equinox, isParallelClassLoader, does *not* reflect whether the classloader is indeed parallel capable: it is only Equinox's internal attempt at that. To be parallel capable truly a classloader must call ClassLoader.registerAsParallelCapable() in its static initializer.

http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html

As to where the classloader lock is obtain and how to check that, if I recall correctly ClassLoader.loadClassInternal, called by the VM was where the lock was obtained in the past. It's been reimplemented in Java 7 to only obtain the lock if the classloader is not parallel capable. 

So if you're running Java 6, or Java 7 and NetbinoxLoader is not parallel capable, when the BP you mention gets hit, and you inspect JVM locks held, you will see that there's a lock on NetbinoxLoader. If you make the NetbinoxLoader parallel capable by calling ClassLoader.registerAsParallelCapable() in its static constructor, you will observe that in that same situation when the same BP gets hit, the lock on NetbinoxLoader is no longer held, but instead ClassLoader is using parallelLockMap attribute to lock by classname. That means parallel classloading has worked. How to automate that check is a great question, to which I don't have a good answer. Possibly calling ClassLoader.ParallelLoaders.isRegistered(), by reflection?
Comment 3 stoto79 2013-03-12 21:53:46 UTC
Correction in the above statement: A classloader is parallel capable if, during the loading of a class, it *does not hold* a lock on the entire classloader object

So:

parallel ==> locks on classname of the class that's being loaded
not parallel / legacy / all pre-Java 6 classloaders ==> locks on the classloader object itself
Comment 4 Jaroslav Tulach 2013-03-13 12:15:55 UTC
ergonomics#03ca4117274e

I'd like to merge this fix into release73.
Comment 5 Marian Mirilovic 2013-03-13 14:11:59 UTC
(In reply to comment #4)
> I'd like to merge this fix into release73.

please wait till Patch 1 is released (03/21), thanks a lot
Comment 6 Jaroslav Tulach 2013-03-14 10:47:49 UTC
OK, I delay the integration into release73 branch.

However as JDev needs this fix soon, I've merged it into jdev_abrams branch:

changeset:   085c2dd7e5b4
branch:      jdev_abrams
parent:      255694:d092a926a9a5
parent:      255666:03ca4117274e
date:        Thu Mar 14 11:45:24 2013 +0100
Comment 7 Quality Engineering 2013-03-15 01:46:17 UTC
Integrated into 'main-golden', will be available in build *201303142300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/03ca4117274e
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #226084: Making NetbinoxLoader parallel capable on JDK7 and asserting that classloader lock is not held on JDK7 while classloading.
Comment 8 Jaroslav Tulach 2013-05-02 14:13:02 UTC
release73 already contains 03ca4117274e
Comment 9 Jaroslav Tulach 2013-05-06 10:14:30 UTC
The release73 repository is broken and "hg merge" does not work. Doing it manually:

$ hg exp 03ca4117274e | patch -p1
$ hg ci
$ hg tip
changeset:   2292921ae97c
branch:      release73
tag:         tip
user:        Jaroslav Tulach <jtulach@netbeans.org>
date:        Mon May 06 12:13:04 2013 +0200
summary:     Manual backport of #226084: Make Netbinox classloader parallel
Comment 10 Quality Engineering 2013-05-07 00:18:19 UTC
Integrated into 'releases', will be available in build *201305062200* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/2292921ae97c
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: Manual backport of #226084: Make Netbinox classloader parallel
Comment 11 Quality Engineering 2013-05-16 02:27:53 UTC
Integrated into 'main-golden', will be available in build *201305152300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/e2ef3fae1c49
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #226084: Modified for version 7.4 to use direct call rather than reflection


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo