I see this is mostly what I approved for JDK9 but I noticed you made a
change
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 :
Advertising
>Regarding "2856 RELEASE_ARRAYS(env, data, (const JOCTET
*)(dest->next_output_byte));".
>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 :
>http://cr.openjdk.java.net/~jdv/8162461/webrev.02/
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.
-phil.
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
