Eric Feigenson wrote:
>I'm not even sure a workaround would work, since the actually hang, which
>indirectly is causing the lock on java.lang.Runtime.loadLibrary0 to be
>held, is happening in the native method
>java.lang.ClassLoader$NativeLibrary.load, so it might hang there ANYWAY,
>since the AWT thread will have the lock on loadLibrary0 (which it does in
>my current situation).
Yes, but the timing might cause a workaround to succeed. There's no way to
tell except by attempting a workaround.
A few comments on the full thread-dump.
1) I see no apparent deadlocks, but I think the operative word is
"apparent". I have no idea what native-library dependencies there might
be, nor what lib-setup code might be run, for the requested "awt" lib.
That JNI-lib is pretty big, and no doubt complex. If it happens to make
any initializing callbacks to Java methods, it might easily deadlock and be
invisible to a full thread-dump.
2) It's interesting that the loading of AWT appears to be triggered by the
loading of the Component class, specifically its static initializer (named
<clinit>).
3) It's also interesting that a fair number of threads have been spawned by
the time Thread-0 eventually gets around to loading AWT's native lib.
Maybe if you can trigger AWT's loading sooner, it might avoid the hang. In
particular, I would try putting code in place that runs on the main thread
and triggers AWT. As I recall, a Toolkit.getDefaultToolkit() is enough to
trigger AWT's loading. This can be a simple single-purpose hack:
public class Setup
{
public static void setup()
{
new java.util.zip.CRC32(); // trigger zip loading
java.awt.Toolkit.getDefaultToolkit(); // trigger AWT loading
}
}
Then you just call Setup.setup() early on, to trigger the various loads
before the rest of your program gets very far. You can adjust what
Setup.setup() does to vary the workaround's actual behavior. The native
code just calls one place.
4) I didn't recognize what "JDWP" represented, but a-googling I see it's
the Java Debug Wire Protocol. Which makes me think you're doing some
remote debugging. And maybe that's factoring into the mix, too. In
particular, I'm wondering if the loading of JNI libs is somehow calling the
JDWP/JPDA components as a debugging thing, and the act of observation by
the debugger might lead to failure (a Heisenbug).
Also, remote debugging makes me think you might want to take a shot at the
1.5 JVM, and use jconsole to get access to internal JMX'able objects. Not
sure how relevant it would be, but it might be revealing. Just a random
thought.
Another random thought...
Use the sampling capabilities of Activity Monitor.app to take samples after
the hang occurs, and hope that the place it's hung at occupies a large
number of the samples. Not guaranteed it would, but worth a shot.
>I did find, poking around in XCode, that the AWT thread, in the native code
>of ClassLoader$NativeLibrary.load it calls JNI_OnLoad which calls something
>very Objective-C-ish which looks like +[AWTStarter :start] (not sure if I
>have that exactly right). And THAT is where the hang in happening.
That sounds useful, if you can track it down further from there.
Or just take a shotgun-in-the-dark approach, call a workaround like
Setup.setup() early, and see if it changes things around enough to make it
work.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
