IcedTea6 Mozilla plugin with OpenJDK6

Jung-uk Kim jkim at FreeBSD.org
Mon Sep 13 17:21:58 UTC 2010


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 at 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


More information about the freebsd-java mailing list