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

Bob Vandette bob.vandette at oracle.com
Fri Sep 15 13:05:29 UTC 2017


Are you building OpenJDK from the mobile project repositories?

What version of Android are you running on?

I just got a report yesterday that Thread.sleep will hang on Android 8 but we
have not determined the root cause yet.

Bob Vandette


> On Aug 11, 2017, at 6:54 AM, Aditya Ilkal <adityailkal at gmail.com> 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)*
> 
> 
> 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



More information about the hotspot-runtime-dev mailing list