JDK-8367695 : tools/javac/completionDeps/DepsAndAnno.java timed out and PASSed
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 26
  • Priority: P4
  • Status: New
  • Resolution: Unresolved
  • OS: linux
  • CPU: aarch64
  • Submitted: 2025-09-15
  • Updated: 2025-09-15
Related Reports
Causes :  
JDK-8260555 - Change the default TIMEOUT_FACTOR from 4 to 1
Description
The following test timed out in the JDK26 CI:

tools/javac/completionDeps/DepsAndAnno.java

Here's a snippet from the log file:

#section:main
----------messages:(10/499)----------
command: main DepsAndAnno
reason: User specified action: run main/othervm/timeout=10 DepsAndAnno 
started: Mon Sep 15 12:19:25 UTC 2025
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules jdk.compiler --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
Process id: 3074007
Timeout information:
--- Timeout information end.
finished: Mon Sep 15 12:19:50 UTC 2025
elapsed time (seconds): 25.063
----------configuration:(5/196)----------
Boot Layer
  add modules: jdk.compiler                          
  add exports: jdk.compiler/com.sun.tools.javac.api  ALL-UNNAMED
               jdk.compiler/com.sun.tools.javac.main ALL-UNNAMED

----------System.out:(1/35)----------
Timeout signalled after 10 seconds
----------System.err:(1/15)----------
STATUS:Passed.
----------rerun:(50/7922)*----------

So the test timed out at 10 seconds, but PASSed while the timeout
handler was running.

The test is invoked like this:

    run main/othervm/timeout=10 DepsAndAnno

and that 10 second timeout used to be 40 seconds with the
old timeout factor:

JDK-8260555 Change the default TIMEOUT_FACTOR from 4 to 1

Based on this bit from the test's log file:

    elapsed time (seconds): 25.063

and this bit from the task's stdout log:

    -concurrency:4

It looks like 10 seconds is not enough time when
run with a concurrency of 4.
Comments
Here's the "top" info for this test failure: top - 12:19:52 up 4 days, 20:49, 0 users, load average: 5.35, 6.40, 6.10 Tasks: 361 total, 1 running, 360 sleeping, 0 stopped, 0 zombie %Cpu(s): 86.8 us, 2.9 sy, 0.0 ni, 9.6 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st MiB Mem : 30999.0 total, 1785.2 free, 13841.4 used, 15944.8 buff/cache MiB Swap: 6144.0 total, 6119.4 free, 24.6 used. 17157.6 avail Mem so RAM is right at the edge such that we've used a tiny bit of swap. Here's the java processes: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3071380 mach5-r+ 20 0 5297452 1.6g 62076 S 375.0 5.2 22:55.62 java 3057113 mach5-r+ 20 0 6103280 1.6g 62460 S 193.8 5.2 27:56.90 java 3074527 mach5-r+ 20 0 10.7g 133244 42520 S 118.8 0.4 0:09.03 javac <snip> 3042090 mach5-o+ 20 0 4714648 208128 20812 S 0.0 0.7 0:24.41 java <snip> 3042600 mach5-r+ 20 0 11.5g 398220 20360 S 0.0 1.3 0:56.04 java <snip> 3042730 mach5-r+ 20 0 6644464 361164 21848 S 0.0 1.1 1:16.18 java <snip> 3042977 mach5-r+ 20 0 4486780 792256 49192 S 0.0 2.5 5:34.16 java 3042999 mach5-r+ 20 0 4486780 792212 50012 S 0.0 2.5 4:39.86 java 3043026 mach5-r+ 20 0 4486780 808368 49956 S 0.0 2.5 4:11.79 java 3043050 mach5-r+ 20 0 4486780 821264 49708 S 0.0 2.6 4:56.57 java <snip> 3059811 mach5-r+ 20 0 5904876 1.6g 58836 S 0.0 5.4 26:11.91 java <snip> 3072869 mach5-r+ 20 0 5024228 1.1g 44184 S 0.0 3.6 8:50.56 java That's a few more than I was expecting with a concurrency of 4, but there may be a logical explanation.
15-09-2025