Date: Mon, 13 Sep 2010 13:21:38 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-java@freebsd.org Cc: Ivan Voras <ivoras@freebsd.org> Subject: Re: IcedTea6 Mozilla plugin with OpenJDK6 Message-ID: <201009131321.45086.jkim@FreeBSD.org> In-Reply-To: <201009102007.01427.jkim@FreeBSD.org> References: <201009091743.01109.jkim@FreeBSD.org> <201009101900.37004.jkim@FreeBSD.org> <201009102007.01427.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 10 September 2010 08:06 pm, Jung-uk Kim wrote: > 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.h > > > >tm 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/exampl > > >e1 .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(). :-/ I just hacked the IcedTea plugin to initialize the mutexes and a condvar. Please try this instead: http://people.freebsd.org/~jkim/icedtea/openjdk6-icedteanp2.tar.bz2 It may not be complete because I am not 100% sure about the author's intention nor how Linux pthread implementation can cut corners like this. At least, it seems to fix the busy loop problem for me. FYI, a new patch is openjdk6/files/icedtea.patch in the tarball. Cheers, Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009131321.45086.jkim>