On Thu, 9 Jul 2026 10:10:07 GMT, Andreas Chmielewski <[email protected]> wrote:
>> 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 I think changing the `visibility` test to 480 is a good short-term fix. However, I don't think spawning 270 VMs is a good use of test resources for a single test. We need to keep in mind that these tests are run continuously by many developers. I'd suggest filing another issue and explore a couple of different ways to reduce the number of VMs: 1) you could reduce the number of VMs significantly by setting the `jdk.tls.disabledAlgorithms` property set to all of the cipher suites that are to be tested, and then test TLS with each cipher suite to ensure it is properly disabled. Though this would not give you the isolation that you have now, I think it would still catch the issue that caused this bug. 2) You could randomly select a subset of cipher suites to be tested, instead of all of them. And you could add a 3rd run option that would be a manual test which would run all of them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31812#discussion_r3551492590
