[OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock.

Philip Race philip.race at oracle.com
Thu Sep 22 16:20:38 UTC 2016

I see this is mostly what I approved for JDK9 but I noticed you made a 
after I approved it and I did not see or approve the updated version.
I am concerned about this comment you posted for the JDK 9 webrev :

 >Regarding  "2856         RELEASE_ARRAYS(env, data, (const JOCTET 
 >We don't need this RELEASE_ARRAY() call at this place as we have not 
yet pinned any buffer.
 > So I have removed it.
 >Please find updated webrev for review :

What makes you so sure we have not pinned a buffer by then ?
setjmp is special. It may return from any point in the writing process.

In other words that removal looks wrong to me.


On 9/15/16, 1:29 AM, Jayathirth D V wrote:
> Hi,
> Please review the following backport to JDK-8u from JDK-9 at your 
> convenience:
> JDK-9 review thread : 
> http://mail.openjdk.java.net/pipermail/2d-dev/2016-September/007601.html
> Bug : https://bugs.openjdk.java.net/browse/JDK-8162461
> JDK-8u Webrev : http://cr.openjdk.java.net/~jdv/8162461.8u/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ejdv/8162461.8u/webrev.00/>
> Issue : If we try to perform operations like 
> reader.abort()/reader.dispose()/ reader.reset() in any of the 
> IIOReadUpdateListener callbacks, JVM will throw deadlock error.
> Root cause : We are making callbacks from native side to Java by 
> holding some resources in JNI critical lock.
> Solution : We have to release the JNI critical lock on the resources 
> before we call Java function from native side. If we have JNI critical 
> lock and we throw an Exception in that case also we should release the 
> lock.
> I have verified jtreg, JCK and JPRT in JDK8u-dev also.
> Thanks,
> Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160922/ccd8d1b5/attachment.html>

More information about the 2d-dev mailing list