Fwd: openjdk runtime consumes almost 100% cpu on Thread.sleep call

[David Holmes]

Hi,

This email only just turned up on the mailing list despite being sent 
back in August!

On 11/08/2017 8:54 PM, Aditya Ilkal wrote:
> Hi,
> 
> We are running openjdk with below version on android os (Linux localhost
> 4.9.31-android-x86)
> 
> *openjdk version "9-internal"*
> *OpenJDK Runtime Environment (build 9-internal+0-adhoc.aditi.dev)*
> *OpenJDK Client VM (build 9-internal+0-adhoc.aditi.dev, mixed mode)*

Where did you obtain this from? Did you build this from the mobile-dev 
project?

I suggest asking on mobile-dev at openjdk.java.net as that is the only 
place we provide any level of Android support. I don't know how sleep is 
implemented on android.

David

> 
> The following is the program
> 
> public static void main(String[] args) throws Throwable {
>         while(true) {
>       System.out.println("sd123");
>      Thread.sleep(30000);
>      System.out.println("sd12");
>      Thread.sleep(10000);
> }
> }
> 
> The processes details on the OS is as below.
> 
> *Main Process*
> PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
> 7206 28501 root S 869m 24.6 0 87.8      /etc/jdk8/images/jre/bin/java
> *Threads of above process*
> PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
> 7208 28501 root R 869m 24.6 0 13.7      {VM Thread}
> 7207 28501 root R 869m 24.6 1 13.3      /etc/jdk8/images/jre/bin/java
> 7212 28501 root R 869m 24.6 0 12.8    {C1 CompilerThre}
> 7222 28501 root R 869m 24.6 1 12.6     {VM Periodic Task thread}
> 7216 28501 root R 869m 24.6 1 12.3    {Sweeper thread}
> 7217 28501 root R 869m 24.6 1 11.7     {Common-Cleaner}
> The same application when run on Ubuntu linux runs very well and the thread
> state of above threads is 'S', where as in android os, it is shown as R and
> consuming CPU.
> 
> Also, the output "sd12" which should print after waiting 30 s, is taking
> more time. This just means sleep interval is not getting calculated
> correctly.
> 
> This can be easily reproducible, hence request you to look in to this issue
> and provide possible insights.
> 
> Thanks,
> Aditya Ilkal
>