harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: Re: [equinox-dev] buddy classloading & deadlock
Date Fri, 04 Aug 2006 05:53:40 GMT
Alex,

At DRLVM we developed the following rules for holding synchronization
primitives:
1) Never hold any native synchronization primivite while calling to java
from the VM;
2) Never hold any synchronization primitive while calling to user code
(especially class loaders) from the VM.

As far as I may observe, we strictly followed these rules up to now.

I wonder if it is posible to reproduce the scenario, described in the
forwarded mail, on Harmony running Eclipse...

Regards,
    Pavel Pervov.
Intel Middleware Products Division.

On 8/4/06, Alex Blewitt <alex.blewitt@gmail.com> wrote:
>
> This message came up on equinox-dev recently. It highlights a
> potential deadlock when the Sun VM locks the classloader prior to
> calling loadClassInternal. I have no idea if this is an issue for the
> VM we're using, but if it is, we ought to consider what can be done to
> fix it.
>
> Alex.
>
> ---------- Forwarded message ----------
> From: Thomas Watson
> Date: 03-Aug-2006 16:32
> Subject: Re: [equinox-dev] buddy classloading & deadlock
> To: Equinox development mailing list
>
>
>
> What vendor/version of the VM are you using?
>
> There has been a long standing bug open against Sun on a similar
> issue.  It all boils down to the native VM locking the classloader
> before loading a class from it using the ClassLoader.loadClassInternal
> method.  In your stacktrace below this happens when the VM calls
> ClassLoader.loadClassInternal
> (DefaultClassLoader(ClassLoader).loadClassInternal(String) line: 319).
> The VM locks the classloader in native code before it ever calls into
> the ClassLoader.  This leaves us with no options, even if we override
> the loadClassInternal method to make it non-synchronized it will make
> no difference because the native code locks the ClassLoader no matter
> what the method signature is for loadClassInternal.  I have been told
> that Sun plans to fix this in a future release of the VM, it may be
> fixed in the latest 1.5 Sun VM.  The IBM VMs have fixed this issue,
> they will NOT lock the classloader before invoking it from the native
> VM code.
>
> Tom
>
> ---
>
> Hi all,
>
> I noticed that multithreading combined with buddy classloading can
> produce some scary deadlocks. I had one in a project last week and
> managed to recreate it in a toy example. Now I'm wondering if this is
> just one of the dangers of breaking the classloading hierarchy or if
> the framework could do something to avoid this ?
>
> My toy example (also in attachment):
>
> The main project has just one Application class:
>
> public class Application implements IPlatformRunnable{
>
>                 public Object run(Object args) throws Exception {
>                                  new Activator();
>                                  return true;
>                 }
>
> }
>
>
> and the dependent project has an Activator
>
> public class Activator implements BundleActivator {
>
> public void start(BundleContext context) throws Exception {
> new Thread(new Runnable() {
>                 public void run() {
>                 try {
>                    Class.forName("main.Application");
>                } catch (ClassNotFoundException e) { }
> }).start();
>
> // let other thread run to induce deadlock
> try { Thread.sleep(100); } catch (InterruptedException e) {}
> }
>
> public void stop(BundleContext context) throws Exception {}
>
> }
>
>
> The main project depends on dependent, and the dependent project has a
> global buddy policy.
>
>
> This causes the following deadlock:
>
> Thread [main] (Suspended)
>                 owns: DefaultClassLoader  (id=16)
>                 waiting for: DefaultClassLoader  (id=15)
>                 ClasspathManager.findLocalClassImpl(String,
> ClassLoadingStatsHook[]) line: 422
>                 ClasspathManager.findLocalClass(String) line: 410
>                 DefaultClassLoader.findLocalClass(String) line: 188
>                 BundleLoader.findLocalClass(String) line: 339
>                 SingleSourcePackage.loadClass(String) line: 37
>                 BundleLoader.findClass(String, boolean) line: 388
>                 BundleLoader.findClass(String) line: 352
>                 DefaultClassLoader.loadClass(String, boolean) line:
> 83
>                 DefaultClassLoader(ClassLoader).loadClass(String)
> line: 251
>
> DefaultClassLoader(ClassLoader).loadClassInternal(String) line: 319
>                 Application.run(Object) line: 11
>                 PlatformActivator$1.run(Object) line: 78
>                 EclipseAppLauncher.runApplication(Object) line: 92
>                 EclipseAppLauncher.start(Object) line: 68
>                 EclipseStarter.run(Object) line: 400
>                 EclipseStarter.run(String[], Runnable) line: 177
>                 NativeMethodAccessorImpl.invoke0(Method, Object,
> Object[]) line: not
> available [native method]
>                 NativeMethodAccessorImpl.invoke(Object, Object[])
> line: 39
>                 DelegatingMethodAccessorImpl.invoke(Object, Object[])
> line: 25
>                 Method.invoke(Object, Object...) line: 585
>                 Main.invokeFramework(String[], URL[]) line: 336
>                 Main.basicRun(String[]) line: 280
>                 Main.run(String[]) line: 977
>                 Main.main(String[]) line: 952
>
> Thread [Thread-1] (Suspended)
>                 owns: DefaultClassLoader  (id=15)
>                 waiting for: DefaultClassLoader  (id=16)
>                 ClasspathManager.findLocalClassImpl(String,
> ClassLoadingStatsHook[]) line: 422
>                 ClasspathManager.findLocalClass(String) line: 410
>                 DefaultClassLoader.findLocalClass(String) line: 188
>                 BundleLoader.findLocalClass(String) line: 339
>                 BundleLoader.findClass(String, boolean) line: 391
>                 BundleLoader.findClass(String) line: 352
>                 DefaultClassLoader.loadClass(String, boolean) line:
> 83
>                 DefaultClassLoader(ClassLoader).loadClass(String)
> line: 251
>                 BundleLoader.loadClass(String) line: 276
>                 BundleHost.loadClass(String, boolean) line: 227
>                 BundleHost(AbstractBundle).loadClass(String) line:
> 1245
>                 GlobalPolicy.loadClass(String) line: 39
>                 PolicyHandler.doBuddyClassLoading(String) line: 138
>                 BundleLoader.findClass(String, boolean) line: 402
>                 BundleLoader.findClass(String) line: 352
>                 DefaultClassLoader.loadClass(String, boolean) line:
> 83
>                 DefaultClassLoader(ClassLoader).loadClass(String)
> line: 251
>
> DefaultClassLoader(ClassLoader).loadClassInternal(String) line: 319
>                 Class<T>.forName0(String, boolean, ClassLoader) line:
> not available
> [native method]
>                 Class<T>.forName(String) line: 164
>                 Activator$1.run() line: 12
>                 Thread.run() line: 595
> [attachment "buddy-classloading-deadlock.zip" deleted by Thomas
> Watson/Austin/IBM] _______________________________________________
> equinox-dev mailing list
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message