[petermm]

The xtensa JIT jobs run this suite under qemu-user, where every module is compiled to native code at load time and the whole run takes about 18 to 19 minutes. The 20 minute limit left no headroom: on a slightly slower runner the suite was killed while the last module (test_net_kernel) was still running, ~10 seconds short of the final "Return value: ok".

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

[gabrielmancini]

Some data from the release-0.7 push runs that supports this. Duration of the Test: test_estdlib.avm step on the three xtensa jobs:

run (release-0.7)	xtensa	xtensa JIT jobs
8559e0f (10-30)	3.8 min	20.2 ❌, 20.2 ❌
f316c45 (10-30)	4.3	18.5, 15.0
d749c4c (10-29)	5.4	19.6, 19.5
7d69c3e (10-27)	4.0	14.8, 16.7
90810d5 (10-26)	5.2	14.8, 19.7
c8fbd4c (10-13)	4.9	15.6, 16.8

The JIT jobs have been close to the 20 minute limit for weeks, and the same runner-to-runner variation (~5 min) is what pushed both over on 8559e0f. So the red "Build and Test" on that merge (#2419) is this timeout, not the change itself, which only touches src/platforms/esp32. The other failure in that run, riscv32, is the snap install valgrind download failing (api.snapcraft.io … read), also unrelated.

30 minutes leaves about 10 minutes over the slowest run above.