Hi David,
On 12/6/17 18:47, David Holmes wrote:
Hi Chris,
On 7/12/2017 8:38 AM, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8191229
http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/
I expected to see the initialization done in JNI_OnLoad, not in a new
init() method.
I see no point to initialize it specifically in the JNI_OnLoad except
for a simplicity.
We just need the testClass set before the locks in the test class are used.
But I see no problem in either case. :)
Thanks,
Serguei
David
-----
The test is testing contended monitor support. After registering the
callback, it gets an unexpected notification of a contended monitor,
which is happening while the finalizer thread is running. In the
callback the test does a FindClass to find a test class, but the
classloader context is not correct when the finalizer thread is
current, so FindClass fails and leaves an exception pending (probably
blowing away the finalzer thread) and also (separately) causes the
test to fail. It's unknown why this callback is suddenly being
triggered, but the callback itself is not a bug, and the test needs
to defend against it.
The fix is to lookup the test class during test initialization and
keep it cached, rather than look it up every time there is a
contended monitor callback.
thanks,
Chris
