Thread suspension in Dalvik VM

[Yunan He]

Hi Folks,

I found in DalvikVM, the GC thread may use sleep rather than
sched_yield in waiting for thread suspension. There’re some comments
in the code:

---
Thread.c, Function waitForThreadSuspend:

If we're running at a higher priority, sched_yield() may not do
anything, so we need to sleep for "long enough" to guarantee that the
other thread has a chance to finish what it's doing.
---

Do you know what kind of workload/scenario can cause this problem? Is
there any test case covering this issue? Thanks.

Thanks,
Yunan

[freakingtux]

Hi

 
I don't know any details but think this indeed might happen. the JVM uses native threads and android makes heavy use of booth
process priorities (as thread.setPriority and Proccess.setTheadsPriority booth in the end change the process priority heavily ) and scheduling groups
 (10 v.s. 90 % cpu ) have a big impact on scheduling. To me it sounds reasonable that a high priority (Activity) will get rescheduled before the other threads.

I wonder why it would not be possible to wait for a condition to happen but that perhaps this is performance related.

Greetings

[fadden]

On Jun 27, 12:45 am, Yunan He <yunan.he...@gmail.com> wrote:
> ---
> Thread.c, Function waitForThreadSuspend:
>
> If we're running at a higher priority, sched_yield() may not do
> anything, so we need to sleep for "long enough" to guarantee that the
> other thread has a chance to finish what it's doing.
> ---
>
> Do you know what kind of workload/scenario can cause this problem? Is
> there any test case covering this issue? Thanks.

In some implementations of the Linux kernel, sched_yield() literally
does nothing. If you enable one of the "real-time" schedulers and
raise the thread priority, it will starve out everything else (which
is by design). In practice, the Android kernel does support
sched_yield(), and the Android runtime does not use real-time
threads. However, some experiments I did suggested that sched_yield()
was equivalent to a 10ms sleep call, which may not be the desired
behavior.

[Chen Yang]

Fadden,
So are you saying that sleep for 10ms is just one workaround? Do you
see some obvious problem using sched_yeild instead of sleep? It seems
to me that since android is not using real-time scheduler, it doesn't
have so called "startvation" problem you described.

Meanwhile, it seems to me the duration of sleep really depends on the
platform performance, can you share some methodology in deciding the
best value for the particular platform?
Thanks.
--
Chen

> --
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>
>

[fadden]

On Jul 2, 3:41 am, Chen Yang <sunsety...@gmail.com> wrote:
> So are you saying that sleep for 10ms is just one workaround? Do you
> see some obvious problem using sched_yeild instead of sleep? It seems
> to me that since android is not using real-time scheduler, it doesn't
> have so called "startvation" problem you described.

The comment dates back to a time when we were considering the use of
real-time threads. I don't know how sched_yield() interacts with the
current scheduler. Which is, really, the crux of the issue.

> Meanwhile, it seems to me the duration of sleep really depends on the
> platform performance, can you share some methodology in deciding the
> best value for the particular platform?

The VM sleeps for progressively longer periods. That way if the sleep
duration is below the scheduler quantum and the kernel just keeps
handing control back, eventually we will get to a duration where that
is not the case.

Ideally we wouldn't be polling at all.