On Thu, 9 Jul 2026 08:06:07 GMT, Andreas Chmielewski <[email protected]> wrote:
>> On 2nd thought, let's keep a timeout for the `visibility` test only. That >> test spawns a new VM per a cipher suite, we'll think how to avoid this. The >> `handshake` test should run fine with a default timeout. > > Looking at the implementation, both the visibility and handshake runs > currently spawn a separate VM per test case. The visibility run uses all > supported suites (~90), while the handshake run uses only the enabled suites > (~30). > Instead of increasing the timeout further, I can combine the visibility and > handshake checks in the same child VM invocation. That would reduce the > number of VM spawns by about 30. > Unfortunately, the test would still need to spawn a VM for each cipher-suite. > With roughly 90 supported suites and three test cases per suite (disable by > cipher suite, disable by bulk cipher, and a positive bulk-cipher test), there > would still be around 270 child VM invocations. > By doing that way we can east least reduce a bit the total execution time. > With that change, I would keep the timeout at 480, as you suggested. > What do you think? I actually looked into this approach. One complication is that building the test matrix requires a fresh JVM where SSLContext has not been initialized yet. Once SSLContext has been initialized, changing jdk.tls.disabledAlgorithms via Security.setProperty() does not appear to have the desired effect anymore. So, i am fine with changing the timeout for the `visibility` test to 480 and keeping the 'default' for the `handshake` test ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31812#discussion_r3550730833
