On 4/9/18 3:04 PM, Alex Menkov wrote:
(javaEnv is replaced with jni_env)
One thing to be careful of is that testResultClass and testResultObject
may not be valid in the thread that is doing the GetFieldID() call.
These were setup in Java_FieldAccessWatch_startTest() which might have
been a different thread, with a different ClassLoader hierarchy, than
the callback thread. I ran into this problem in another test where there
was an unexpected callback from a finalizer thread. Probably in this
case the worse that can happen is an exception, and the test deals with
On 04/09/2018 14:35, David Holmes wrote:
Though I'd also like to understand why the test only fails sometimes
and which other thread is involved?
It always fails with Graal compiler on win, linux and macosx.
Looks like with Graal compiler access/modification events are sent on
several threads (sorry, I don't have enough knowledge about Graal).
On 10/04/2018 7:28 AM, Chris Plummer wrote:
I'd suggest renaming javaEnv to jni_env to be consistent. Not sure
why javaEnv was chosen in the original implementation. Otherwise the
changes look good.
On 4/9/18 2:13 PM, Alex Menkov wrote:
Please review a fix for
The problem with the test is it uses cached JNIEnv value instead
using a value passed to the callbacks. JNIEnv is valid only for the