[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8279358: vmTestbase/nsk/jvmti/scenarios/jni_interception/JI03/ji03t003/TestDescription.java
From:       Chris Plummer <cjplummer () openjdk ! java ! net>
Date:       2022-04-29 22:17:32
Message-ID: a2XdNAHLq38xzS_CitYAk-rh3hslCHbL8CZcau_8nzQ=.fb7e3c1e-a2b2-439c-8cdb-0884d41b138a () github ! com
[Download RAW message or body]

On Fri, 29 Apr 2022 21:39:20 GMT, Alex Menkov <amenkov@openjdk.org> wrote:

> The test counts calls of intercepted JNI functions, but doesn't completely filter \
> out calls from other threads. Function isThreadExpected is used only for \
> ExceptionOccurred function and the function checks only some known JFR/Graal \
> threads. 
> The change:
> - updates the test to count only the calls on the test thread;
> - adds verbose output.

Also there is [JDK-8284027](https://bugs.openjdk.java.net/browse/JDK-8284027), which \
also is a failure related to unexpected threads and fails because isThreadExpected() \
is not filtering all the proper threads (loom makes this issue worse). It looks like \
you are trying to make the individual tests smarter rather than fixing \
isThreadExpected(). I'm not saying this is the wrong approach, but we should apply \
the approach to all tests that use isThreadExpected() .

-------------

PR: https://git.openjdk.java.net/jdk/pull/8475


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic