This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | NetbinoxLoader needs to be parallel capable | ||
|---|---|---|---|
| Product: | platform | Reporter: | stoto79 |
| Component: | Netigso | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mmirilovic |
| Priority: | P2 | ||
| Version: | 7.4 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | patch for NetbinoxLoader | ||
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? 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? 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 ergonomics#03ca4117274e I'd like to merge this fix into release73. (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 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 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. release73 already contains 03ca4117274e 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 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 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 |
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.