This tests enables jdb method tracing, which relies on JDWP/JDI
MethodEnter/Exit events. Over the years the test has made performance
improvements by filtering out more and more classes, but this is only filtering
out the events at the JDWP level. JVMTI events are still generated for every
method call, and the debug agent needs to process and filter them, and this
takes a lot of time. The fix is to trigger some early class loading an
initialization before tracing is enabled rather than while tracing is enable.
In particular, the following line from MyThread.run(), which is execute while
tracing is enabled, triggers a lot of class loading and initialization:
String caltype = GregorianCalendar.getInstance().getCalendarType();
Moving this to the main() method of the debuggee gets it out of the way early.
I was seeing about 1.1m method calls while tracing was enabled, and this jumped
to 2.2m after [JDK-8384569](https://bugs.openjdk.org/browse/JDK-8384569). It's
about 500 calls after this change.
Tested by running the test 100's of times on windows-x64 and also running all
svc tier1, tier2, and tier5 tests.
---------
- [x] I confirm that I make this contribution in accordance with the [OpenJDK
Interim AI Policy](https://openjdk.org/legal/ai).
-------------
Commit messages:
- pre-init classes to reduce method calls
Changes: https://git.openjdk.org/jdk/pull/31263/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=31263&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8375062
Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/31263.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/31263/head:pull/31263
PR: https://git.openjdk.org/jdk/pull/31263
