RFR: 8308499: Test vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java failed: VMDisconnectedException

[Chris Plummer]

On Wed, 14 Jun 2023 21:54:22 GMT, Leonid Mesnik <lmesnik at 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