On Wed, 14 Jun 2023 21:54:22 GMT, Leonid Mesnik <lmes...@openjdk.org> wrote:
>> The test gets overloaded with MethodExitEvents, causing them to queue up (in >> the JDI queue) and continue to be processed by the test after the debuggee >> exits. This results in a VMDisconnectedException when the test tries to do >> the following after getting an event: >> >> ` String str = >> ((MethodExitEvent)event).location().declaringType().name(); ` >> >> The test is suppose to add filters to execlude events for all non-test >> classes, but it is only filtering `java.*` and `sun.*`. There are also a >> very large number of `jdk.*` events coming in, and this is what is causing >> the event backlog and the processing of events after disconnect. Filtering >> out `jdk.*` events reduces the total number of events to a few dozen, and >> the test passes. >> >> More details can be found in the CR. >> >> Testing in progress: tier5 svc testing, and also running the failing test on >> all platforms (both debug and product). > > test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001.java > line 77: > >> 75: private String classExclName1 = "java"; >> 76: private String classExclName2 = "sun"; >> 77: private String classExclName3 = "jdk"; > > The fix is reasonable. However, > I think it would be better to use List<String> with List.of(...) and > list.contains() to filter exclusions. With 3 items it's borderline which approach to do. I find it easier to read the way it is now, especially checking the event classname, since it would require a loop that sets a flag that then has to be checked outside of the loop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14480#discussion_r1230260039
