IcedTeaPlugin on powerpc (both Zero port and Cacao)

[Deepak Bhole]

* Mark Wielaard <mark at klomp.org> [2008-10-29 05:20]:
> Hi Matthias,
> 
> 
> On Tue, 2008-10-28 at 23:14 +0100, Matthias Klose wrote:
> > This was just a quick test, with revision 1154:
> > 
> >  - the classpath.org applet bounces, but firefox shows 100% CPU all the time
> >  - the (fixed) ColorBlockApplet intializes (yellow box), but doesn't react
> >    to anything, the browser again at 100% CPU.
> 
> Do you know where the plugin/vm is stuck spinning at 100%?
> 
> I couldn't easily replicate it on x86_64 (hotspot) but I have seen the
> IcedTeaPlugin stuck on 100% once or twice in something like:
> 
>    while (initialized == PR_FALSE)
>      PROCESS_PENDING_EVENTS;
> 
> Where PROCESS_PENDING_EVENTS is defined as:
> 
> #define PROCESS_PENDING_EVENTS \
>     PRBool hasPending;  \
>     factory->current->HasPendingEvents(&hasPending); \
>     if (hasPending == PR_TRUE) { \
>         PRBool processed = PR_FALSE; \
>         factory->current->ProcessNextEvent(PR_TRUE, &processed); \
>     } \
>     if (g_main_context_pending (NULL)) { \
>        g_main_context_iteration(NULL, false); \
>     } else \
>     { \
>        PR_Sleep(PR_INTERVAL_NO_WAIT); \
>     }
> 
> Since PR_Sleep(PR_INTERVAL_NO_WAIR) is basically a PR_Yield() this is
> essentially a busy wait if both hasPending and initialized are false. I
> don't know what can cause that though. And I don't have any reliable
> reproducer.
> 
> [... little sanity check later ...]
> 

Right. So everytime we send a message to Java, we enter the
PROCESS_PENDING_EVENTS macro, which processes any mozilla events for
that thread, and then any glib events. The mozilla events needs to be
processed for UI responsiveness, and glib events needs to be processed
so that the C++ <-> Java message pipe callbacks are activated.

> This code seems to have been cleaned up a bit with explicit timeouts, so
> it might be my issue already been fixed.
>

Yeah, I added timeouts in the parts where it was waiting for VM
initialization, so that if the VM failed to come up, mozilla wouldn't
hang.
 
> Still would be interesting to know if you could pin-point the
> busy-wait/100% cpu load with something like a debugger if possible.
> 
> And I am still a little suspicious of the usage of
> PR_Sleep(PR_INTERVAL_NO_WAIT).
> 

I agree, and will be refactoring once all the main issues/features are
done. Not sure if we should get rid of PR_INTERVAL_NO_WAIT though.
AFAIK, the smallest interval that can be waited for is 1ms. When an
initial JS->Java call happens, over 6000 messages are passed back and
forth. That is 6 seconds of forced wait. That is why I made it yield :/
I am welcome to suggestions though!

Deepak

> Cheers,
> 
> Mark
>