From owner-freebsd-java@FreeBSD.ORG Sat Sep 11 00:07:10 2010 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 5D99B106566C; Sat, 11 Sep 2010 00:07:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Ivan Voras Date: Fri, 10 Sep 2010 20:06:48 -0400 User-Agent: KMail/1.6.2 References: <201009091743.01109.jkim@FreeBSD.org> <201009101900.37004.jkim@FreeBSD.org> In-Reply-To: <201009101900.37004.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201009102007.01427.jkim@FreeBSD.org> Cc: freebsd-java@freebsd.org Subject: Re: IcedTea6 Mozilla plugin with OpenJDK6 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Sep 2010 00:07:11 -0000 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 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