RFR: 8341778: Some javac tests ignore the result of JavacTask::call

[Vicente Romero]

On Thu, 5 Jun 2025 15:30:30 GMT, Johannes Döbler <duke at openjdk.org> wrote:

>> yes this one was failing quietly, this test is stressing a code that was modified due to pattern matching. It is testing that javac can deal with deeply nested code without throwing SOE. 1000 depth was too much and the test was quietly failing
>
>> It is testing that javac can deal with deeply nested code without throwing SOE.
> 
> The current summary `Javac fails with StackOverflowError when compiling deeply nested synchronized blocks` is confusing and I don't know how it relates to your statement. Does it describe a bug or does it state the purpose of the test? Anyway, why not test with nesting levels of 500 and 1000, assert that task.call() returns true (500) and false (1000), but in the later case does not panic and terminate with a SOE.

the original version of the test was included as part of the fix for [1] as you can see in the related PR [2] method com.sun.tools.javac.jvm.Gen::visitBlock was being visiting every block assuming that every one of them had pattern matching expressions in it. This implied a visitBlock with a higher number of local variables even for 90-98% of blocks that didn't have any pattern matching in them. So the test is checking that javac is not failing with SOE while generating code for a method with deeply nested blocks. Testing that javac will produce SOE after a given threshold is passed adds no information as there always be resource limit for any process. This is why I don't see the value of having a test that passes that threshold, which by the way could move over time and then we will need to go back and fix the test. While on the other hand having a test that will keep javac in check, as in being able to still compile without issues a nested enough code, seems more valuable to me.

[1] https://bugs.openjdk.org/browse/JDK-8322992
[2] https://github.com/openjdk/jdk/pull/18832

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2129342988