Date: Fri, 10 Sep 2010 20:06:48 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-java@freebsd.org Subject: Re: IcedTea6 Mozilla plugin with OpenJDK6 Message-ID: <201009102007.01427.jkim@FreeBSD.org> In-Reply-To: <201009101900.37004.jkim@FreeBSD.org> References: <201009091743.01109.jkim@FreeBSD.org> <AANLkTi=-AUAjxG-amC3-vjwnhmop3QGWfaf%2Bnn6fytuh@mail.gmail.com> <201009101900.37004.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 10 September 2010 07:00 pm, Jung-uk Kim wrote: > On Friday 10 September 2010 06:13 pm, Ivan Voras wrote: > > On 10 September 2010 23:46, Jung-uk Kim <jkim@freebsd.org> wrote: > > > All applets or some applets? Can you test some trivial > > > applets? Something like the following: > > > > > > file:///usr/local/openjdk6/demo/jfc/SwingApplet/SwingApplet.htm > > >l > > > > Surprisingly, yes I can. > > Good. > > > But I cannot start for example this one: > > > > http://java.sun.com/applets/jdk/1.4/demo/applets/ArcTest/example1 > >.h tml > > Probably you want to test it locally: > > file:///usr/local/openjdk6/demo/applets/ArcTest/example1.html > > BTW, IcedTea plugin is not 100% compatible with Sun/Oracle's. Your > mileage may vary. ;-) > > > And even with the simple applet that works I get ridiculous CPU > > usage of firefox: > > > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME > > WCPU COMMAND 647 ivoras 15 44 0 228M 94320K ucond > > 5 1:58 268.95% firefox-bin > > Yes, I know. firefox-bin process gets stuck at ucond state and > ktrace shows it's doing somthing weird like this: > > ... > 22820 firefox-bin 0.000003 CALL _umtx_op(0x80d4d50c0,0x11,0,0,0) > 22820 firefox-bin 0.000005 CALL _umtx_op(0x80d4d50c0,0x12,0,0,0) > 22820 firefox-bin 0.000001 RET _umtx_op 0 > 22820 firefox-bin 0.000006 RET _umtx_op 0 > 22820 firefox-bin 0.000006 CALL _umtx_op(0x80d4d4040,0x11,0,0,0) > 22820 firefox-bin 0.000005 RET _umtx_op 0 > 22820 firefox-bin 0.000003 CALL _umtx_op(0x80d4d4040,0x11,0,0,0) > 22820 firefox-bin 0.000004 RET _umtx_op 0 > 22820 firefox-bin 0.000003 CALL _umtx_op(0x80d4d4040,0x11,0,0,0) > 22820 firefox-bin 0.000003 RET _umtx_op 0 > 22820 firefox-bin 0.000004 CALL _umtx_op(0x80d4d4040,0x11,0,0,0) > 22820 firefox-bin 0.000003 CALL _umtx_op(0x80d4d4040,0x12,0,0,0) > ... > > I am not sure why it happens but my guess is the plugin may > mis-handle mutexes. This is not my department, unfortunately. :-( I *think* there are some mutexes in the plugin that are not initialized properly and they are causing this weird behaviour. %grep pthread_mutex_t * IcedTeaPluginRequestProcessor.cc:pthread_mutex_t message_queue_mutex = PTHREAD_MUTEX_INITIALIZER; IcedTeaPluginRequestProcessor.cc:pthread_mutex_t syn_write_mutex = PTHREAD_MUTEX_INITIALIZER; IcedTeaPluginRequestProcessor.cc: pthread_mutex_t wait_mutex = PTHREAD_MUTEX_INITIALIZER; // This is needed for API compat. and is unused IcedTeaPluginRequestProcessor.h:static pthread_mutex_t tc_mutex = PTHREAD_MUTEX_INITIALIZER; IcedTeaPluginRequestProcessor.h:extern pthread_mutex_t message_queue_mutex; IcedTeaPluginRequestProcessor.h:extern pthread_mutex_t syn_write_mutex; IcedTeaPluginUtils.cc:pthread_mutex_t IcedTeaPluginUtilities::reference_mutex = PTHREAD_MUTEX_INITIALIZER; IcedTeaPluginUtils.h: static pthread_mutex_t reference_mutex; IcedTeaPluginUtils.h: pthread_mutex_t msg_queue_mutex; IcedTeaPluginUtils.h: pthread_mutex_t subscriber_mutex; %grep pthread_mutex_init * IcedTeaPluginUtils.cc: ret = pthread_mutex_init(&subscriber_mutex, NULL); IcedTeaPluginUtils.cc: ret = pthread_mutex_init(&msg_queue_mutex, NULL); %grep pthread_mutex_destroy * IcedTeaPluginUtils.cc: ret = pthread_mutex_destroy(&subscriber_mutex); IcedTeaPluginUtils.cc: ret = pthread_mutex_destroy(&msg_queue_mutex); 5 mutexes are declared and *used* but only two are initialized. I don't know how Linux works without pthread_mutex_init(). :-/ Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009102007.01427.jkim>