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). Ping! I could use one more review. TIA! ------------- PR Comment: https://git.openjdk.org/jdk/pull/31263#issuecomment-4559298379
