On Mon, 13 Jul 2026 07:56:47 GMT, Andreas Chmielewski <[email protected]> wrote:
>> 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. > > Ok. Should I continue with the separation of this test in that PR or in a new > one (as @seanjmullan said)? I actually already separated the tests. The SSLAlgorithmDecomposer coverage is now in a dedicated test that directly verifies the decomposition results. Since it invokes the decomposer directly, all checks run in the same VM and execute very quickly. The handshake test remains responsible for validating jdk.tls.disabledAlgorithms handling (for available cipher suites), without requiring a large number of VM invocations. This separation seems like a good compromise to me. So, to avoid creating a new issue, we can fix this also directly here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31812#discussion_r3570158487
