[LUCENE-9110] Use StackWalker in tests instead of iterating through StackTraceElement arrays

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 9.0, 8.5
• Component/s: general/test
• Lucene Fields: New
• Assignee: Uwe Schindler
• Reporter: Uwe Schindler
• Created: 24/Dec/19 15:52
• Updated: 28/Aug/22 15:54
• Resolved: 27/Dec/19 11:14

Description

Followup of LUCENE-9109:
There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in their call stack.

This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of sometimes >>2 times (depending on how deep you dive into call stack).

There are a few tests (only 3) that do more complex stack trace analysis. Those should be refactored at some point. For now I added a deprecated method to get the whole StackTrace in Java 11, which is still 2 times faster than using an Exception.

For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive).

So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames.

One important thing is: Using StackWalker makes sure that the stack is "correct". Stacks from Thread or Exception may miss some frames, as it does not deoptimize the code. So depending on JVMs and optimizations (e.g. Graal), call stacks may change if we still use old code for analysis. This is no longer an issue for Java 8, but may be in future.

Issue Links

• relates to: LUCENE-9109 Use Java 9+ StackWalker to implement TestSecurityManager's detection of JVM exit
• links to: GitHub Pull Request #1120