IcedTeaPlugin on powerpc (both Zero port and Cacao)

[Mark Wielaard]

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 ...]

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

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).

Cheers,

Mark