RFR: 8236108 tools/javac/lambda/LambdaParserTest.java timed out

[Adam Sotona]

Hi,
First thanks for the feedback in the JDK-8236108.

I would like to ask for review of a new patch for the time-outing LambdaParserTest.
The patch filters redundant or non-sense combinations of lambdas and it reduces the number of performed sub-tests from 573 696 to 285 334, which should be suitable to fit into a default timeout even on slow or busy machines.
Filtered are:
- several combinations of parentheses, which generated the same source code (in combination with empty sub-expression)
- all combinations of non-empty lambda sub-expressions with lambda statements, which generated non-sense source code
- all parameters not used in the actual lambda expression template, which also generated the same source code multiple times  

JBS: https://bugs.openjdk.java.net/browse/JDK-8236108
webrev: http://cr.openjdk.java.net/~asotona/8236108/webrev.01/

Thanks for the review,
Adam


> On 2 Jun 2020, at 15:41, Adam Sotona <adam.sotona at oracle.com> wrote:
> 
> Hi,
> I would like to ask for review of LambdaParserTest.java timed out fix.
> This particular test is very complex and intensive. 
> It includes 573696 test actions, each parsing a source fragment. 
> As this single test takes on my powerful machine approx. 1 minute and the default timeout is 2 minutes, so I can imagine situations where it timeouts. 
> 
> Target machine scale factor was 4, so the default timeout was 480s, however the test elapsed time was 523s. 
> 
> Proposed patch extends the timeout by 50% to 180s, so multiplied by the machine-specific timeout scale factor it will give enough time to finish successfully.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8236108
> webrev: http://cr.openjdk.java.net/~asotona/8236108/webrev.00/
> 
> The test is a part of Tier 4 and it is passing for me even without the extended timeout, so I cannot practically verify the patch effectivity unless it fails.
> 
> Thanks,
> Adam