On Fri, 22 May 2026 22:49:11 GMT, Chris Plummer <[email protected]> wrote:
> 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). This seems a problem that could affect many tests and which will only get worse over time. In the absence of any kind of general mechanism to either control events at the JVM TI level, or do more structured pre-loading/initialization, then this suffices to address the testing problem. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/31263#pullrequestreview-4354436895
