[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
Wed Oct 5 16:19:18 UTC 2016
+1
-phil.
On 9/29/16, 1:49 AM, Jayathirth D V wrote:
>
> Hi Phil,
>
> New changes are submitted in JDK9 under JDK-8166685.
>
> Please find updated webrev for review in JDK8u:
>
> http://cr.openjdk.java.net/~jdv/8162461.8u/webrev.01/
> <http://cr.openjdk.java.net/%7Ejdv/8162461.8u/webrev.01/>
>
> I have verified JCK, jtreg and JPRT for updated changes in JDK8u.
>
> Thanks,
>
> Jay
>
> *From:*Philip Race
> *Sent:* Friday, September 23, 2016 10:10 PM
> *To:* Jayathirth D V
> *Cc:* 2d-dev
> *Subject:* Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI
> up-call made whilst holding JNI critical lock.
>
> You can't re-use the 9 bug ID in 9. So you will need to create a new
> bug to fix
> that in 9.
>
> But for 8u it can be part of this fix .. it would be weird to
> knowingly check in
> a problem just so you could fix it separately.
>
>
> -phil.
>
> On 9/23/16, 12:13 AM, Jayathirth D V wrote:
>
> Hi Phil,
>
> I assumed setjmp/longjmp functions to be internal error handling
> mechanism rather than C standard library functions which provide
> non-local jumps.
>
> I verified setjmp/longjmp usage in ImageIO JPEG context and we
> need that RELEASE_ARRAYS() call in writeImage() which I have removed.
>
> Does I have to create a new Bug and add the RELEASE_ARRAY() call
> in writeImage() or I have to check-in this change under
> JDK-8162461 only?
>
> After check-in of this modification I will raise new webrev for 8u
> backport.
>
> Thanks,
>
> Jay
>
> *From:*Philip Race
> *Sent:* Thursday, September 22, 2016 9:51 PM
> *To:* Jayathirth D V
> *Cc:* 2d-dev
> *Subject:* Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to
> JNI up-call made whilst holding JNI critical lock.
>
> 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 :
>
> >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/
> <http://cr.openjdk.java.net/%7Ejdv/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20161005/e64739e4/attachment.html>
More information about the 2d-dev
mailing list