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

[Phil Race]

This all looks reasonable. But I wonder if you missed something.
Take a look at sun_jpeg_output_message(). That may also make up-calls.
A pointer to this function is passed to the IJG library and I don't know
the circumstances under which it may call this function.
If it ever might do it whilst we are holding these locks then that would
mean we'd need the same RELEASE/GET in there .. although the challenge
would be that it does not have access to the data to release the arrays.
So
1) Investigate if it is an actual issue,
2) If it is, then decide between a way to ensure the arrays are available to
this function (looks tricky to me), or somehow deferring these up-calls or
eliminating them.

-phil.

On 9/6/2016 11:49 PM, Jayathirth D V wrote:
>
> Fixed typo.
>
> *From:* Jayathirth D V
> *Sent:* Wednesday, September 07, 2016 12:11 PM
> *To:* Philip Race; 2d-dev
> *Subject:* [OpenJDK 2D-Dev] [9] RFR JDK-8162461: Hang due to JNI 
> up-call made whilst holding JNI critical lock.
>
> Hi,
>
> Please review the following fix in JDK9 at your convenience:
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8162461
>
> Webrev : http://cr.openjdk.java.net/~jdv/8162461/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ejdv/8162461/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.
>
> Thanks,
>
> Jay
>