From owner-freebsd-java@FreeBSD.ORG Mon Sep 13 17:21:58 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 8A2501065673; Mon, 13 Sep 2010 17:21:57 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-java@freebsd.org Date: Mon, 13 Sep 2010 13:21:38 -0400 User-Agent: KMail/1.6.2 References: <201009091743.01109.jkim@FreeBSD.org> <201009101900.37004.jkim@FreeBSD.org> <201009102007.01427.jkim@FreeBSD.org> In-Reply-To: <201009102007.01427.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201009131321.45086.jkim@FreeBSD.org> Cc: Ivan Voras 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: Mon, 13 Sep 2010 17:21:58 -0000 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 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