From rob.mckenna at oracle.com Mon Jan 2 13:45:03 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 2 Jan 2017 13:45:03 +0000 Subject: [8u-dev] Request for approval 8171949: [macosx] AWT_ZoomFrame Automated tests fail with error: The bitwise mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state In-Reply-To: <434B4322-5697-4995-BFEF-ED5AD06BC5D4@oracle.com> References: <434B4322-5697-4995-BFEF-ED5AD06BC5D4@oracle.com> Message-ID: <20170102134503.GA3797@tecra> Approved -Rob On 29/12/16 12:47, Dmitry Markov wrote: > Hello, > > Can I get an approval to port the fix for 8171949 to jdk8u-dev, please? The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8171949 > Webrev: http://cr.openjdk.java.net/~dmarkov/8171949/jdk8u/webrev.00/ > Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-December/012485.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b69ce768cb7d > > Thanks, > Dmitry From rob.mckenna at oracle.com Mon Jan 2 13:45:44 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 2 Jan 2017 13:45:44 +0000 Subject: [8u-dev] Request for approval 8171952: [macosx] AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked. In-Reply-To: <093CA487-CD70-4C5A-BC19-33057F7EAC9D@oracle.com> References: <093CA487-CD70-4C5A-BC19-33057F7EAC9D@oracle.com> Message-ID: <20170102134544.GB3797@tecra> Approved -Rob On 29/12/16 08:47, Dmitry Markov wrote: > Hello, > > Can I get an approval to port the fix for 8171952 to jdk8u-dev, please? The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8171952 > Webrev: http://cr.openjdk.java.net/~dmarkov/8171952/jdk8u/webrev.00/ > Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2016-December/012489.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/9adbdbedae4f > > Thanks, > Dmitry From erik.joelsson at oracle.com Tue Jan 3 12:43:38 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 3 Jan 2017 13:43:38 +0100 Subject: RFC: nashorn sources are missing in src.zip In-Reply-To: <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> References: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> Message-ID: Hello Jiri, From a pure build point of view, the change looks ok, but I don't think we are allowed to accept patches not hosted on openjdk infrastructure. The suitability of the change is a topic for jdk8u-dev (added). This should be considered an enhancement though. The restrictive inclusion of packages in JDK 8 and older was intentional and changing it in JDK 9 was definitely an enhancement. (Note that JDK 9 recently changed the src.zip again) One could argue that your original change to just include the jdk package is a bug fix since the intention of the original filtering was to just include public APIs. /Erik On 2017-01-03 13:12, Jiri Vanek wrote: > Hello! > > Thank you very much for kind answer and additional resources. > There is modified backport of patch you mentioned: > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v2/webrev/ > > > Except the backport itself, I had to add also nashorn sources (as jdk9 > is handling this a bit differently). > At the end I added also sources for zipfs, as jdk9 have them too, and > they were the last missing bits as far as I saw. > > The size of src.zip grown from 26 to 52MB (still less then 62 of jdk9). > > I think the change i suitable for 8u, as it is bug in truth. I found > it when I faced strange behaviour in rhino and wonted to step in (with > src.zip linked to ide)...and... nothing. So it was not nice surprise. > > Tahnx again! > J. > > On 01/03/2017 09:03 AM, Erik Joelsson wrote: >> Hello Jiri, >> >> Please see related issue [1] which was included early in JDK 9 but >> the backport was never done. I >> don't personally mind including more sources in src.zip for OpenJDK, >> but instead of adding them >> piecemeal I would argue for reopening the backport. I don't know if >> such a change is suitable for 8u >> at this point though. The size of src.zip increases quite >> dramatically. However, it should be noted >> that it's only included in the JDK image and not the JRE. >> >> For anyone unsure of the role of src.zip, it's only use is for IDEs >> to see the JDK sources to aid >> debugging of other applications. >> >> /Erik >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8044235 >> >> On 2017-01-02 17:41, Jiri Vanek wrote: >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ >>> >>> >>> Hello good people! >>> >>> I have found, that nashorn sources are missing in src.zip. >>> It is easily fixable by webrev above. >>> >>> If you will think about it as "private api", jdk9 *have* nashorn >>> module sources included. >>> >>> Actually more sun* sources are missing. Or even more sources which >>> result to ext directory. Imho >>> they should be included too. I will prepare patches for each set >>> separately, if it will be agreed. >>> >>> I know that sun* are somehow deprecated. But it is sad when you can >>> not easily debug inside the >>> JDK. The absence of theirs in src.zip is not the cure. >>> >>> Thanx! >>> J. >> > From jvanek at redhat.com Tue Jan 3 15:11:30 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 3 Jan 2017 16:11:30 +0100 Subject: RFC: nashorn sources are missing in src.zip In-Reply-To: References: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> Message-ID: <5e1001c2-e143-ded1-9992-035391613ca4@redhat.com> On 01/03/2017 01:43 PM, Erik Joelsson wrote: > Hello Jiri, > > From a pure build point of view, the change looks ok, but I don't think we are allowed to accept > patches not hosted on openjdk infrastructure. Those patches were already accepted. And the policy "patch first, member later" is actually enforcing patch elsewhere. I'm already in author group (jdk9 project only) so I should have place on java.net, so if this is blocker, it can be fixed. > > The suitability of the change is a topic for jdk8u-dev (added). This should be considered an Thanx! > enhancement though. The restrictive inclusion of packages in JDK 8 and older was intentional and > changing it in JDK 9 was definitely an enhancement. (Note that JDK 9 recently changed the src.zip > again) > > One could argue that your original change to just include the jdk package is a bug fix since the > intention of the original filtering was to just include public APIs. Its up to you and build-dev to decide this. If nashorn-only change will be accepted, Then I will very soon post also zipfs patch, as it is very similar. If not, then it will become just another distro-only (fedora/rhel) patch, as those sources *are* missing (if not all then nashorn definitely) Thanx a lot! All the best, J. > > /Erik > > On 2017-01-03 13:12, Jiri Vanek wrote: >> Hello! >> >> Thank you very much for kind answer and additional resources. >> There is modified backport of patch you mentioned: >> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v2/webrev/ >> >> Except the backport itself, I had to add also nashorn sources (as jdk9 is handling this a bit >> differently). >> At the end I added also sources for zipfs, as jdk9 have them too, and they were the last missing >> bits as far as I saw. >> >> The size of src.zip grown from 26 to 52MB (still less then 62 of jdk9). >> >> I think the change i suitable for 8u, as it is bug in truth. I found it when I faced strange >> behaviour in rhino and wonted to step in (with src.zip linked to ide)...and... nothing. So it was >> not nice surprise. >> >> Tahnx again! >> J. >> >> On 01/03/2017 09:03 AM, Erik Joelsson wrote: >>> Hello Jiri, >>> >>> Please see related issue [1] which was included early in JDK 9 but the backport was never done. I >>> don't personally mind including more sources in src.zip for OpenJDK, but instead of adding them >>> piecemeal I would argue for reopening the backport. I don't know if such a change is suitable for 8u >>> at this point though. The size of src.zip increases quite dramatically. However, it should be noted >>> that it's only included in the JDK image and not the JRE. >>> >>> For anyone unsure of the role of src.zip, it's only use is for IDEs to see the JDK sources to aid >>> debugging of other applications. >>> >>> /Erik >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8044235 >>> >>> On 2017-01-02 17:41, Jiri Vanek wrote: >>>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ >>>> >>>> Hello good people! >>>> >>>> I have found, that nashorn sources are missing in src.zip. >>>> It is easily fixable by webrev above. >>>> >>>> If you will think about it as "private api", jdk9 *have* nashorn module sources included. >>>> >>>> Actually more sun* sources are missing. Or even more sources which result to ext directory. Imho >>>> they should be included too. I will prepare patches for each set separately, if it will be agreed. >>>> >>>> I know that sun* are somehow deprecated. But it is sad when you can not easily debug inside the >>>> JDK. The absence of theirs in src.zip is not the cure. >>>> >>>> Thanx! >>>> J. >>> >> > From david.holmes at oracle.com Tue Jan 3 20:50:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Jan 2017 06:50:06 +1000 Subject: RFC: nashorn sources are missing in src.zip In-Reply-To: <5e1001c2-e143-ded1-9992-035391613ca4@redhat.com> References: <88786c07-b3a5-b75a-6842-77d005ada5e4@redhat.com> <4781075b-f82a-b251-d368-0f8593d41f08@oracle.com> <5dd83013-6764-ab0c-3116-a63e51be531a@redhat.com> <5e1001c2-e143-ded1-9992-035391613ca4@redhat.com> Message-ID: Hi Jiri, On 4/01/2017 1:11 AM, Jiri Vanek wrote: > On 01/03/2017 01:43 PM, Erik Joelsson wrote: >> Hello Jiri, >> >> From a pure build point of view, the change looks ok, but I don't >> think we are allowed to accept >> patches not hosted on openjdk infrastructure. > > Those patches were already accepted. And the policy "patch first, member > later" is actually enforcing patch elsewhere. > > I'm already in author group (jdk9 project only) so I should have place > on java.net, so if this is blocker, it can be fixed. Yes please fix, it is a requirement for contribution acceptance. >> >> The suitability of the change is a topic for jdk8u-dev (added). This >> should be considered an > > Thanx! > >> enhancement though. The restrictive inclusion of packages in JDK 8 and >> older was intentional and >> changing it in JDK 9 was definitely an enhancement. (Note that JDK 9 >> recently changed the src.zip >> again) >> >> One could argue that your original change to just include the jdk >> package is a bug fix since the >> intention of the original filtering was to just include public APIs. > > > Its up to you and build-dev to decide this. > If nashorn-only change will be accepted, Then I will very soon post also > zipfs patch, as it is very similar. This is an enhancement and needs to follow the process described here: http://openjdk.java.net/projects/jdk8u/enhancement-template.html that process itself is somewhat hard to find but referenced from Rule 3 here: http://openjdk.java.net/projects/jdk8u/groundrules.html Thanks, David > If not, then it will become just another distro-only (fedora/rhel) > patch, as those sources *are* missing (if not all then nashorn definitely) > > Thanx a lot! > > All the best, > J. >> >> /Erik >> >> On 2017-01-03 13:12, Jiri Vanek wrote: >>> Hello! >>> >>> Thank you very much for kind answer and additional resources. >>> There is modified backport of patch you mentioned: >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v2/webrev/ >>> >>> >>> Except the backport itself, I had to add also nashorn sources (as >>> jdk9 is handling this a bit >>> differently). >>> At the end I added also sources for zipfs, as jdk9 have them too, >>> and they were the last missing >>> bits as far as I saw. >>> >>> The size of src.zip grown from 26 to 52MB (still less then 62 of jdk9). >>> >>> I think the change i suitable for 8u, as it is bug in truth. I found >>> it when I faced strange >>> behaviour in rhino and wonted to step in (with src.zip linked to >>> ide)...and... nothing. So it was >>> not nice surprise. >>> >>> Tahnx again! >>> J. >>> >>> On 01/03/2017 09:03 AM, Erik Joelsson wrote: >>>> Hello Jiri, >>>> >>>> Please see related issue [1] which was included early in JDK 9 but >>>> the backport was never done. I >>>> don't personally mind including more sources in src.zip for OpenJDK, >>>> but instead of adding them >>>> piecemeal I would argue for reopening the backport. I don't know if >>>> such a change is suitable for 8u >>>> at this point though. The size of src.zip increases quite >>>> dramatically. However, it should be noted >>>> that it's only included in the JDK image and not the JRE. >>>> >>>> For anyone unsure of the role of src.zip, it's only use is for IDEs >>>> to see the JDK sources to aid >>>> debugging of other applications. >>>> >>>> /Erik >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8044235 >>>> >>>> On 2017-01-02 17:41, Jiri Vanek wrote: >>>>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/nashornMissingInSrcZip/v1/webrev/ >>>>> >>>>> >>>>> Hello good people! >>>>> >>>>> I have found, that nashorn sources are missing in src.zip. >>>>> It is easily fixable by webrev above. >>>>> >>>>> If you will think about it as "private api", jdk9 *have* nashorn >>>>> module sources included. >>>>> >>>>> Actually more sun* sources are missing. Or even more sources which >>>>> result to ext directory. Imho >>>>> they should be included too. I will prepare patches for each set >>>>> separately, if it will be agreed. >>>>> >>>>> I know that sun* are somehow deprecated. But it is sad when you can >>>>> not easily debug inside the >>>>> JDK. The absence of theirs in src.zip is not the cure. >>>>> >>>>> Thanx! >>>>> J. >>>> >>> >> > From nikita.j.jain at oracle.com Wed Jan 4 05:08:14 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 3 Jan 2017 21:08:14 -0800 (PST) Subject: [8u] RFA for backport of JDK-7052625: com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently In-Reply-To: <8af14f4c-5a16-49eb-8c6c-9a0ffeb907d5@default> References: <8af14f4c-5a16-49eb-8c6c-9a0ffeb907d5@default> Message-ID: <4ce958de-4a2d-4df4-8518-e2935747c858@default> Hi All, I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-7052625 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e5a09bc70308 Public review: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-February/017930.html JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/7052625/webrev.00/ Tested with jprt. Would you please help with approval of the backport? Thanks in advance, Nikita From nikita.j.jain at oracle.com Wed Jan 4 05:10:53 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 3 Jan 2017 21:10:53 -0800 (PST) Subject: FW: [8u] RFA for backport of JDK-7102702: java/net/PortUnreachableException/OneExceptionOnly.java failing In-Reply-To: References: Message-ID: <0119e6be-d58b-4e35-8a5a-b9b82a2bbe7b@default> Hi All, I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-7102702 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e9004951beea Public review: http://mail.openjdk.java.net/pipermail/net-dev/2013-December/008052.html JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/7102702/webrev.00/ Tested with jprt. Would you please help with approval of the backport? Thanks in advance, Nikita From nikita.j.jain at oracle.com Wed Jan 4 05:11:25 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 3 Jan 2017 21:11:25 -0800 (PST) Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed In-Reply-To: <29d048f7-42f5-4607-a78e-4cd4b76f8146@default> References: <29d048f7-42f5-4607-a78e-4cd4b76f8146@default> Message-ID: <7030bf10-d252-4652-ab4f-ea89a694b4c4@default> Hi All, I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8157665 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/dc99fd161d90 Public review: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014077.html JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/8157665/webrev.00/ Tested with jprt. Would you please help with approval of the backport? Thanks in advance, Nikita From nikita.j.jain at oracle.com Wed Jan 4 05:11:51 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 3 Jan 2017 21:11:51 -0800 (PST) Subject: [8u] RFA for backport of JDK-6772009: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: References: Message-ID: Hi All, I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-6772009 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e0ed6b05df7 Public review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023428.html JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/6772009/webrev.00/ Tested with jprt. Would you please help with approval of the backport? Thanks in advance, Nikita From nikita.j.jain at oracle.com Wed Jan 4 05:26:23 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 3 Jan 2017 21:26:23 -0800 (PST) Subject: [8u] RFA for backport of JDK-7052625: com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently In-Reply-To: <4ce958de-4a2d-4df4-8518-e2935747c858@default> References: <8af14f4c-5a16-49eb-8c6c-9a0ffeb907d5@default> <4ce958de-4a2d-4df4-8518-e2935747c858@default> Message-ID: <324ffa93-a08c-4676-be04-422539ac1124@default> Sorry, previous public review link was incorrect. Sending the updated public review link: http://mail.openjdk.java.net/pipermail/net-dev/2014-February/008253.html Thanks, Nikita From: Nikita Jain Sent: Wednesday, January 4, 2017 10:38 AM To: jdk8u-dev at openjdk.java.net Subject: [8u] RFA for backport of JDK-7052625: com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently Hi All, I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-7052625 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e5a09bc70308 Public review: http://mail.openjdk.java.net/pipermail/net-dev/2014-February/008253.html JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/7052625/webrev.00/ Tested with jprt. Would you please help with approval of the backport? Thanks in advance, Nikita From david.buck at oracle.com Wed Jan 4 05:41:05 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 4 Jan 2017 14:41:05 +0900 Subject: [8u] RFA for backport of JDK-7052625: com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently In-Reply-To: <324ffa93-a08c-4676-be04-422539ac1124@default> References: <8af14f4c-5a16-49eb-8c6c-9a0ffeb907d5@default> <4ce958de-4a2d-4df4-8518-e2935747c858@default> <324ffa93-a08c-4676-be04-422539ac1124@default> Message-ID: <586C8AF1.50207@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/01/04 14:26, Nikita Jain wrote: > Sorry, previous public review link was incorrect. Sending the updated > > > > public review link: http://mail.openjdk.java.net/pipermail/net-dev/2014-February/008253.html > > > > Thanks, > > Nikita > > > > From: Nikita Jain > Sent: Wednesday, January 4, 2017 10:38 AM > To: jdk8u-dev at openjdk.java.net > Subject: [8u] RFA for backport of JDK-7052625: com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently > > > > Hi All, > > > > I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-7052625 > > Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e5a09bc70308 > > Public review: http://mail.openjdk.java.net/pipermail/net-dev/2014-February/008253.html > > JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/7052625/webrev.00/ > > > > Tested with jprt. Would you please help with approval of the backport? > > > > Thanks in advance, > > Nikita > From david.buck at oracle.com Wed Jan 4 05:47:30 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 4 Jan 2017 14:47:30 +0900 Subject: FW: [8u] RFA for backport of JDK-7102702: java/net/PortUnreachableException/OneExceptionOnly.java failing In-Reply-To: <0119e6be-d58b-4e35-8a5a-b9b82a2bbe7b@default> References: <0119e6be-d58b-4e35-8a5a-b9b82a2bbe7b@default> Message-ID: <586C8C72.9000209@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/01/04 14:10, Nikita Jain wrote: > Hi All, > > > > I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-7102702 > > Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e9004951beea > > Public review: http://mail.openjdk.java.net/pipermail/net-dev/2013-December/008052.html > > JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/7102702/webrev.00/ > > > > > > Tested with jprt. Would you please help with approval of the backport? > > > > Thanks in advance, > > Nikita > > > From nikita.j.jain at oracle.com Wed Jan 4 07:02:04 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 3 Jan 2017 23:02:04 -0800 (PST) Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed In-Reply-To: <7030bf10-d252-4652-ab4f-ea89a694b4c4@default> References: <29d048f7-42f5-4607-a78e-4cd4b76f8146@default> <7030bf10-d252-4652-ab4f-ea89a694b4c4@default> Message-ID: Sorry, I made a mistake. The trivial backport requires a code review. JDK8 webrev link is mentioned in previous mail. The changeset didn't apply cleanly. I had edited it manually, since it was just removing the test entries from the ProblemList.txt. From: Nikita Jain Sent: Wednesday, January 4, 2017 10:41 AM To: jdk8u-dev at openjdk.java.net Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed Hi All, I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8157665 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/dc99fd161d90 Public review: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014077.html JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/8157665/webrev.00/ Tested with jprt. Would you please help with approval of the backport? Thanks in advance, Nikita From nikita.j.jain at oracle.com Wed Jan 4 07:14:42 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 3 Jan 2017 23:14:42 -0800 (PST) Subject: [8u] RFA for backport of JDK-6772009: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: References: Message-ID: <34bc589d-e19d-4d9f-a0f1-2ad4e6b6685a@default> Hi All, The Public review thread is spanning across months. The link is mentioned below: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/023664.html Thanks, Nikita From: Nikita Jain Sent: Wednesday, January 4, 2017 10:42 AM To: jdk8u-dev at openjdk.java.net Subject: [8u] RFA for backport of JDK-6772009: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' Hi All, I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-6772009 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e0ed6b05df7 Public review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023428.html JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/6772009/webrev.00/ Tested with jprt. Would you please help with approval of the backport? Thanks in advance, Nikita From david.buck at oracle.com Wed Jan 4 07:30:12 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 4 Jan 2017 16:30:12 +0900 Subject: [8u] RFA for backport of JDK-6772009: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' In-Reply-To: <34bc589d-e19d-4d9f-a0f1-2ad4e6b6685a@default> References: <34bc589d-e19d-4d9f-a0f1-2ad4e6b6685a@default> Message-ID: <586CA484.2030400@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/01/04 16:14, Nikita Jain wrote: > Hi All, > > The Public review thread is spanning across months. The link is mentioned below: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/023664.html > > Thanks, > Nikita > > > From: Nikita Jain > Sent: Wednesday, January 4, 2017 10:42 AM > To: jdk8u-dev at openjdk.java.net > Subject: [8u] RFA for backport of JDK-6772009: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2' > > Hi All, > > I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6772009 > Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1e0ed6b05df7 > Public review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023428.html > JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/6772009/webrev.00/ > > > Tested with jprt. Would you please help with approval of the backport? > > Thanks in advance, > Nikita > From martin.doerr at sap.com Wed Jan 4 10:31:11 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 4 Jan 2017 10:31:11 +0000 Subject: [8u] request for approval: "8172145: C2: anti dependence missed because store hidden by membar" Message-ID: <0dc8127cc8064f238cfaa70fc86adb1e@dewdfe13de06.global.corp.sap> Hi, could you please approve the backport of the following C2 fix to jdk8u-dev: 8172145: C2: anti dependence missed because store hidden by membar This small fix prevents wrong generated code by C2 compiler in rare situations. Bug: https://bugs.openjdk.java.net/browse/JDK-8172145 Webrev: http://cr.openjdk.java.net/~mdoerr/8172145_C2_antidep/webrev.01/ Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-January/025252.html URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/9102f200c421 The original patch cleanly applies. Thanks and best regards, Martin From david.buck at oracle.com Wed Jan 4 11:05:26 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 4 Jan 2017 20:05:26 +0900 Subject: [8u] request for approval: "8172145: C2: anti dependence missed because store hidden by membar" In-Reply-To: <0dc8127cc8064f238cfaa70fc86adb1e@dewdfe13de06.global.corp.sap> References: <0dc8127cc8064f238cfaa70fc86adb1e@dewdfe13de06.global.corp.sap> Message-ID: <586CD6F6.80307@oracle.com> approved for backport to 8u-dev once appropriate noreg label has been added to the bug report. [ noreg labels ] http://openjdk.java.net/guide/changePlanning.html#noreg Cheers, -Buck On 2017/01/04 19:31, Doerr, Martin wrote: > Hi, > > > > could you please approve the backport of the following C2 fix to jdk8u-dev: > > > > 8172145: C2: anti dependence missed because store hidden by membar > > > > This small fix prevents wrong generated code by C2 compiler in rare situations. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172145 > > Webrev: http://cr.openjdk.java.net/~mdoerr/8172145_C2_antidep/webrev.01/ > > Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-January/025252.html > > URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/9102f200c421 > > > > The original patch cleanly applies. > > Thanks and best regards, > Martin > From sean.coffey at oracle.com Wed Jan 4 11:14:35 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 4 Jan 2017 11:14:35 +0000 Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed In-Reply-To: References: <29d048f7-42f5-4607-a78e-4cd4b76f8146@default> <7030bf10-d252-4652-ab4f-ea89a694b4c4@default> Message-ID: <586CD91B.3040802@oracle.com> The changes look fine. Please ensure that the tests pass on JPRT solaris platforms before pushing. Approved. Regards, Sean. On 04/01/17 07:02, Nikita Jain wrote: > Sorry, I made a mistake. The trivial backport requires a code review. JDK8 webrev link is mentioned in previous mail. > > > > The changeset didn't apply cleanly. I had edited it manually, since it was just removing the test entries from the ProblemList.txt. > > > > From: Nikita Jain > Sent: Wednesday, January 4, 2017 10:41 AM > To: jdk8u-dev at openjdk.java.net > Subject: [8u] RFA for backport of JDK-8157665: ProblemList.txt needs to be updated as 7041639 closed > > > > Hi All, > > > > I'd like to backport this fix to jdk8u-dev. The fix applies cleanly. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157665 > > Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/dc99fd161d90 > > Public review: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014077.html > > JDK8u Webrev: http://cr.openjdk.java.net/~shshahma/Nikita/8157665/webrev.00/ > > > > > > Tested with jprt. Would you please help with approval of the backport? > > > > Thanks in advance, > > Nikita > > > > > > From volker.simonis at gmail.com Wed Jan 4 16:01:02 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Jan 2017 17:01:02 +0100 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) Message-ID: Hi, can I please have get the approval for pushing the following small, ppc64-only fix to jdk8u-dev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ https://bugs.openjdk.java.net/browse/JDK-8172053 The change has been reviewed by dholms and erikj in this mail thread: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-December/006295.html Thank you and best regards, Volker From rob.mckenna at oracle.com Wed Jan 4 16:03:52 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 4 Jan 2017 16:03:52 +0000 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) In-Reply-To: References: Message-ID: <20170104160352.GA3816@tecra> Approved -Rob On 04/01/17 05:01, Volker Simonis wrote: > Hi, > > can I please have get the approval for pushing the following > small, ppc64-only fix to jdk8u-dev: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ > https://bugs.openjdk.java.net/browse/JDK-8172053 > > The change has been reviewed by dholms and erikj in this mail thread: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-December/006295.html > > Thank you and best regards, > Volker From vladimir.kozlov at oracle.com Wed Jan 4 18:30:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 Jan 2017 10:30:52 -0800 Subject: [8u] request for approval: "8172145: C2: anti dependence missed because store hidden by membar" In-Reply-To: <586CD6F6.80307@oracle.com> References: <0dc8127cc8064f238cfaa70fc86adb1e@dewdfe13de06.global.corp.sap> <586CD6F6.80307@oracle.com> Message-ID: Martin updated bug's report with noreg label. I will sponsor this backport. Thanks, Vladimir On 1/4/17 3:05 AM, David Buck wrote: > approved for backport to 8u-dev once appropriate noreg label has been added to the bug report. > > [ noreg labels ] > http://openjdk.java.net/guide/changePlanning.html#noreg > > Cheers, > -Buck > > On 2017/01/04 19:31, Doerr, Martin wrote: >> Hi, >> >> >> >> could you please approve the backport of the following C2 fix to jdk8u-dev: >> >> >> >> 8172145: C2: anti dependence missed because store hidden by membar >> >> >> >> This small fix prevents wrong generated code by C2 compiler in rare situations. >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172145 >> >> Webrev: http://cr.openjdk.java.net/~mdoerr/8172145_C2_antidep/webrev.01/ >> >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-January/025252.html >> >> URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/9102f200c421 >> >> >> >> The original patch cleanly applies. >> >> Thanks and best regards, >> Martin >> From rob.mckenna at oracle.com Thu Jan 5 01:58:13 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 5 Jan 2017 01:58:13 +0000 Subject: [8u] Request for enhancement backport approval for CR 8170888: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments In-Reply-To: <39b485f8-b705-562c-d07e-11772d3d2f21@oracle.com> References: <39b485f8-b705-562c-d07e-11772d3d2f21@oracle.com> Message-ID: <20170105015813.GD3816@tecra> Hi David, this enhancement request was approved. Can you file a push approval request? -Rob On 20/12/16 07:11, David Holmes wrote: > Please consider approving this enhancement for 8u: > > https://bugs.openjdk.java.net/browse/JDK-8170888 > > This enhancement adds experimental support for observing the memory limits > imposed by Linux cgroups, and in particular a container environment like > Docker. > > As this is an opt-in, experimental, VM option, there is zero risk associated > with this enhancement. > > Thanks, > David From david.holmes at oracle.com Thu Jan 5 03:50:48 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Jan 2017 13:50:48 +1000 Subject: [8u] Request for enhancement backport approval for CR 8170888: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments In-Reply-To: <20170105015813.GD3816@tecra> References: <39b485f8-b705-562c-d07e-11772d3d2f21@oracle.com> <20170105015813.GD3816@tecra> Message-ID: <38e8557a-b11b-5337-bdef-7a6af6ca88ca@oracle.com> On 5/01/2017 11:58 AM, Rob McKenna wrote: > Hi David, this enhancement request was approved. Can you file a push > approval request? Will do! Thanks, David > -Rob > > On 20/12/16 07:11, David Holmes wrote: >> Please consider approving this enhancement for 8u: >> >> https://bugs.openjdk.java.net/browse/JDK-8170888 >> >> This enhancement adds experimental support for observing the memory limits >> imposed by Linux cgroups, and in particular a container environment like >> Docker. >> >> As this is an opt-in, experimental, VM option, there is zero risk associated >> with this enhancement. >> >> Thanks, >> David From jvanek at redhat.com Thu Jan 5 12:15:16 2017 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 5 Jan 2017 13:15:16 +0100 Subject: [8u] Request for enhancement backport approval for CR 8044235 - nashorn (and other) sources are missing in src.zip Message-ID: Hello! There is a lot of sources missing in src.zip from jdk8 build. All those are present in jdk9 src.zip. Even as jdk8 had intention to hide "private" sources, from the src.zip, missing nashorn can be considered as bug. However, when jdk9 reconsidered, jdk8 should follow. Most of the distros adapted the patch from 8044235[1] anyway. There are two approaches possible: - add only nashorn [2] and maybe later (or during this review) also zipfs - backport (and adapt) whole 8044235 patch [3] For [2], the src.zip grows by 1MB (from 23->24MB) For [3], the src.zip grow double - 51MB (jdk9 have src.zip of 62MB) Only SDK image is affected. note - src.zip i used only for IDEs to make debugging easy, and when debugging jdk itself (when *your* application is misbehaving), you are stepping through all binaries, so it is not correct to hide the sources for something you can step inside anyway. Skippable longstory: Recently I was debugging nashorn in jdk8, and realized, that nashorn sources are missing in it, although they are present in jdk9. Quick patch followed to build-dev: http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018460.html There I was made aware about https://bugs.openjdk.java.net/browse/JDK-8044235 and fact that it was long ago recommended for backport, but never done. However, the backport is much more complex then simple "add nashorn sources": http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018462.html From review later flown up taht it should be considered as enhancement instead of simple bugfix,but in al cases it should go over 8u-dev so here it is. Please see the whole thread of "RFC: nashorn sources are missing in src.zip" on http://mail.openjdk.java.net/pipermail/build-dev/2017-January/thread.html#start for complex info. As the result of this thread I copied the patches from fedorapeople.org to cr.openjdk.net. Bes regards from CZ, J. [1] https://bugs.openjdk.java.net/browse/JDK-8044235 [2] http://cr.openjdk.java.net/~jvanek/nashornMissingInSrcZip/v1/webrev/ [3] http://cr.openjdk.java.net/~jvanek/nashornMissingInSrcZip/v2/webrev/ From rob.mckenna at oracle.com Thu Jan 5 15:11:36 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 5 Jan 2017 15:11:36 +0000 Subject: [8u] Request for enhancement backport approval for CR 8044235 - nashorn (and other) sources are missing in src.zip In-Reply-To: References: Message-ID: <20170105151136.GA6561@tecra> Thanks Jiri, this has been submitted for approval. I'll keep you posted. -Rob On 05/01/17 01:15, Jiri Vanek wrote: > Hello! > > There is a lot of sources missing in src.zip from jdk8 build. All those are present in jdk9 src.zip. > Even as jdk8 had intention to hide "private" sources, from the src.zip, > missing nashorn can be considered as bug. > However, when jdk9 reconsidered, jdk8 should follow. Most of the distros > adapted the patch from 8044235[1] anyway. > > There are two approaches possible: > - add only nashorn [2] and maybe later (or during this review) also zipfs > - backport (and adapt) whole 8044235 patch [3] > > For [2], the src.zip grows by 1MB (from 23->24MB) > For [3], the src.zip grow double - 51MB (jdk9 have src.zip of 62MB) > > Only SDK image is affected. > > note - src.zip i used only for IDEs to make debugging easy, and when > debugging jdk itself (when *your* application is misbehaving), you are > stepping through all binaries, so it is not correct to hide the sources for > something you can step inside anyway. > > > Skippable longstory: > Recently I was debugging nashorn in jdk8, and realized, that nashorn sources > are missing in it, although they are present in jdk9. > Quick patch followed to build-dev: > http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018460.html > There I was made aware about > https://bugs.openjdk.java.net/browse/JDK-8044235 and fact that it was long > ago recommended for backport, but never done. > However, the backport is much more complex then simple "add nashorn > sources": > http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018462.html > > From review later flown up taht it should be considered as enhancement > instead of simple bugfix,but in al cases it should go over 8u-dev so here it > is. > > Please see the whole thread of "RFC: nashorn sources are missing in src.zip" > on http://mail.openjdk.java.net/pipermail/build-dev/2017-January/thread.html#start > for complex info. > As the result of this thread I copied the patches from fedorapeople.org to cr.openjdk.net. > > Bes regards from CZ, > J. > > [1] https://bugs.openjdk.java.net/browse/JDK-8044235 > [2] http://cr.openjdk.java.net/~jvanek/nashornMissingInSrcZip/v1/webrev/ > [3] http://cr.openjdk.java.net/~jvanek/nashornMissingInSrcZip/v2/webrev/ From maurizio.cimadamore at oracle.com Thu Jan 5 18:43:09 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Jan 2017 18:43:09 +0000 Subject: [8u-dev] Request for approval for 8168774: Polymorhic signature method check crashes javac Message-ID: Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8168774 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6a79477df95d Backport review thread: http://mail.openjdk.java.net/pipermail/compiler-dev/2017-January/010633.html The changes did not apply cleanly because of minor changes in JDK 9 (see link to backport review). Cheers Maurizio From rob.mckenna at oracle.com Thu Jan 5 18:47:30 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 5 Jan 2017 18:47:30 +0000 Subject: [8u-dev] Request for approval for 8168774: Polymorhic signature method check crashes javac In-Reply-To: References: Message-ID: <20170105184730.GC6561@tecra> Approved -Rob On 05/01/17 06:43, Maurizio Cimadamore wrote: > Please approve. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168774 > JDK 9 changeset: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/6a79477df95d > Backport review thread: http://mail.openjdk.java.net/pipermail/compiler-dev/2017-January/010633.html > > > The changes did not apply cleanly because of minor changes in JDK 9 (see link to backport review). > > Cheers > Maurizio > From david.holmes at oracle.com Thu Jan 5 23:50:58 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Jan 2017 09:50:58 +1000 Subject: [8u] Request for Approval: 8170888: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments Message-ID: <60b6eca3-f6ec-2047-c10d-115ebc9de80d@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888 This enhancement adds experimental support for observing the memory limits imposed by Linux cgroups, and in particular a container environment like Docker. The enhancement request was approved here: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-January/006325.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/ The changeset can't apply cleanly due to use of unified logging, but that is the only change. It was re-reviewed here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-January/025702.html Thanks, David From david.buck at oracle.com Fri Jan 6 02:40:24 2017 From: david.buck at oracle.com (David Buck) Date: Fri, 6 Jan 2017 11:40:24 +0900 Subject: [8u] Request for Approval: 8170888: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments In-Reply-To: <60b6eca3-f6ec-2047-c10d-115ebc9de80d@oracle.com> References: <60b6eca3-f6ec-2047-c10d-115ebc9de80d@oracle.com> Message-ID: <586F0398.8020904@oracle.com> approved for push to 8u-dev Cheers, -Buck On 2017/01/06 8:50, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8170888 > > This enhancement adds experimental support for observing the memory > limits imposed by Linux cgroups, and in particular a container > environment like Docker. > > The enhancement request was approved here: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-January/006325.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49 > > 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/ > > The changeset can't apply cleanly due to use of unified logging, but > that is the only change. It was re-reviewed here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-January/025702.html > > Thanks, > David From david.holmes at oracle.com Fri Jan 6 03:11:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Jan 2017 13:11:47 +1000 Subject: [8u] Request for Approval: 8170888: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments In-Reply-To: <586F0398.8020904@oracle.com> References: <60b6eca3-f6ec-2047-c10d-115ebc9de80d@oracle.com> <586F0398.8020904@oracle.com> Message-ID: <5a2e15f7-3ec1-6586-10ca-bd8c5fc8cdd1@oracle.com> Thanks David! David H. On 6/01/2017 12:40 PM, David Buck wrote: > approved for push to 8u-dev > > Cheers, > -Buck > > On 2017/01/06 8:50, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888 >> >> This enhancement adds experimental support for observing the memory >> limits imposed by Linux cgroups, and in particular a container >> environment like Docker. >> >> The enhancement request was approved here: >> >> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-January/006325.html >> >> JDK 9 changeset: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49 >> >> 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/ >> >> The changeset can't apply cleanly due to use of unified logging, but >> that is the only change. It was re-reviewed here: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-January/025702.html >> >> >> Thanks, >> David From rob.mckenna at oracle.com Fri Jan 6 13:50:13 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 6 Jan 2017 13:50:13 +0000 Subject: [8u] Request for Approval: 8170888: [linux] Experimental support for cgroup memory limits in container (ie Docker) environments In-Reply-To: <60b6eca3-f6ec-2047-c10d-115ebc9de80d@oracle.com> References: <60b6eca3-f6ec-2047-c10d-115ebc9de80d@oracle.com> Message-ID: <20170106135013.GA3708@tecra> Approved. Please add an appropriate noreg label to the bug. -Rob On 06/01/17 09:50, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8170888 > > This enhancement adds experimental support for observing the memory limits > imposed by Linux cgroups, and in particular a container environment like > Docker. > > The enhancement request was approved here: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-January/006325.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49 > > 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/ > > The changeset can't apply cleanly due to use of unified logging, but that is > the only change. It was re-reviewed here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-January/025702.html > > Thanks, > David From jamsheed.c.m at oracle.com Fri Jan 6 12:11:09 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 6 Jan 2017 17:41:09 +0530 Subject: RFR[8u]: 8164293: HotSpot leaking memory in long-running requests In-Reply-To: <58356BD2.80605@oracle.com> References: <850634c4-12f8-f1b0-52c3-3e28d091af54@oracle.com> <58340183.50508@oracle.com> <63eb1cab-fb3c-86d7-d446-87445d06cb99@oracle.com> <58356BD2.80605@oracle.com> Message-ID: <053df620-54c3-8dde-e6aa-56a1f10139c7@oracle.com> Thank you for the review, Tobias. could i get a second review please. also, request for approval from 8u-dev. Best Regards, Jamsheed On 11/23/2016 3:43 PM, Tobias Hartmann wrote: > Hi Jamsheed, > > On 22.11.2016 17:41, Jamsheed C m wrote: >> Hi, >> >> On 11/22/2016 6:09 PM, Jamsheed C m wrote: >>> Hi Tobias, >>> >>> On 11/22/2016 1:57 PM, Tobias Hartmann wrote: >>>> Hi Jamsheed, >>>> >>>> On 22.11.2016 08:37, Jamsheed C m wrote: >>>>> Hi All, >>>>> >>>>> Request for review. >>>>> >>>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8164293 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jcm/8164293/webrev.00/ >>>> I think the resource marks in the sweeper could be "moved up" in the scope but looking at the JDK 9 code, we have them at the places you suggested so I think it's fine for consistency reasons. The JDK 9 code is not affected because it was fixed with JDK-8046809, right? >>> Yes, Done. >>>> Please add this as a comment to the bug. >>>> >>>> Why do we need a RM in nmethod::clear_ic_stubs()? It's also missing in JDK 9 code. >>> This one was causing the leak in sweeper task(product build without logging option). RM added in NMethodSweeper::sweep_code_cache should be enough as it is sole user of the function. I added RM in clear_ic_stubs too to make sure that there is no misses in future. It is good to have change in JDK9, as said in (https://bugs.openjdk.java.net/browse/JDK-8059675) >>> >>>>> Desc: There were a few memory leaks in thread arena due to sweeper task. >>>>> >>>>> Fix: Applied ResourceMark wherever applicable. >>>>> >>>>> The slow growth of mtClass malloc(the one reported in bug) is not memory leak. It is application behavior in low codecache size setting( frequent sweeps), more InstanceKlass requires OopMapCache initialized here. >>>> Could you please elaborate on this? Why do we create more InstanceKlasses? And why is this behavior not stabilizing? >>> It doesn't create more InstanceKlasses. No of InstanceKlasses is 5649 is kind of stable. OopMapCache for an InstanceKlass get initialized on first request (Interpreter frame walk during gc). Stabilizing thing is yet to be checked as i did all my analysis in debug mode(with gdb attached). It is confirmed that the rate of memory growth in steadily decreasing, and all OopMapCache allocation happen for unique InstanceKlass. >> i meant "each OopMapCache allocation happen for unique InstanceKlass", sorry for the typo. > Okay, as we discussed offline, please file a new bug to keep track of the OopMapCache issue. > > I'm fine with the current sweeper fix (not an 8u reviewer). > > Thanks, > Tobias > >> Best Regards, >> Jamsheed >>> i have a product instance with fixes running now for a day. i can wait a few more days to confirm that i don't miss anything. >>> >>> Best Regards, >>> Jamsheed >>> >>> >>> >>>> Thanks, >>>> Tobias >>>> >>>>> Best Regards, >>>>> >>>>> Jamsheed >>>>> From vladimir.kozlov at oracle.com Tue Jan 10 17:09:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 Jan 2017 09:09:36 -0800 Subject: RFR[8u]: 8164293: HotSpot leaking memory in long-running requests In-Reply-To: <053df620-54c3-8dde-e6aa-56a1f10139c7@oracle.com> References: <850634c4-12f8-f1b0-52c3-3e28d091af54@oracle.com> <58340183.50508@oracle.com> <63eb1cab-fb3c-86d7-d446-87445d06cb99@oracle.com> <58356BD2.80605@oracle.com> <053df620-54c3-8dde-e6aa-56a1f10139c7@oracle.com> Message-ID: Good. Thanks, Vladimir On 1/6/17 4:11 AM, Jamsheed C m wrote: > Thank you for the review, Tobias. > > could i get a second review please. also, request for approval from > 8u-dev. > > Best Regards, > > Jamsheed > > > On 11/23/2016 3:43 PM, Tobias Hartmann wrote: >> Hi Jamsheed, >> >> On 22.11.2016 17:41, Jamsheed C m wrote: >>> Hi, >>> >>> On 11/22/2016 6:09 PM, Jamsheed C m wrote: >>>> Hi Tobias, >>>> >>>> On 11/22/2016 1:57 PM, Tobias Hartmann wrote: >>>>> Hi Jamsheed, >>>>> >>>>> On 22.11.2016 08:37, Jamsheed C m wrote: >>>>>> Hi All, >>>>>> >>>>>> Request for review. >>>>>> >>>>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8164293 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jcm/8164293/webrev.00/ >>>>> I think the resource marks in the sweeper could be "moved up" in >>>>> the scope but looking at the JDK 9 code, we have them at the places >>>>> you suggested so I think it's fine for consistency reasons. The JDK >>>>> 9 code is not affected because it was fixed with JDK-8046809, right? >>>> Yes, Done. >>>>> Please add this as a comment to the bug. >>>>> >>>>> Why do we need a RM in nmethod::clear_ic_stubs()? It's also missing >>>>> in JDK 9 code. >>>> This one was causing the leak in sweeper task(product build >>>> without logging option). RM added in >>>> NMethodSweeper::sweep_code_cache should be enough as it is sole user >>>> of the function. I added RM in clear_ic_stubs too to make sure that >>>> there is no misses in future. It is good to have change in JDK9, as >>>> said in (https://bugs.openjdk.java.net/browse/JDK-8059675) >>>> >>>>>> Desc: There were a few memory leaks in thread arena due to >>>>>> sweeper task. >>>>>> >>>>>> Fix: Applied ResourceMark wherever applicable. >>>>>> >>>>>> The slow growth of mtClass malloc(the one reported in bug) is not >>>>>> memory leak. It is application behavior in low codecache size >>>>>> setting( frequent sweeps), more InstanceKlass requires OopMapCache >>>>>> initialized here. >>>>> Could you please elaborate on this? Why do we create more >>>>> InstanceKlasses? And why is this behavior not stabilizing? >>>> It doesn't create more InstanceKlasses. No of InstanceKlasses is >>>> 5649 is kind of stable. OopMapCache for an InstanceKlass get >>>> initialized on first request (Interpreter frame walk during gc). >>>> Stabilizing thing is yet to be checked as i did all my analysis in >>>> debug mode(with gdb attached). It is confirmed that the rate of >>>> memory growth in steadily decreasing, and all OopMapCache allocation >>>> happen for unique InstanceKlass. >>> i meant "each OopMapCache allocation happen for unique >>> InstanceKlass", sorry for the typo. >> Okay, as we discussed offline, please file a new bug to keep track of >> the OopMapCache issue. >> >> I'm fine with the current sweeper fix (not an 8u reviewer). >> >> Thanks, >> Tobias >> >>> Best Regards, >>> Jamsheed >>>> i have a product instance with fixes running now for a day. i can >>>> wait a few more days to confirm that i don't miss anything. >>>> >>>> Best Regards, >>>> Jamsheed >>>> >>>> >>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> Best Regards, >>>>>> >>>>>> Jamsheed >>>>>> > From karl at xk72.com Tue Jan 10 19:44:48 2017 From: karl at xk72.com (Karl von Randow) Date: Wed, 11 Jan 2017 08:44:48 +1300 Subject: [PATCH] Deadlock in CGLGraphicsConfig.getCGLConfigInfo Message-ID: I have encountered a deadlock in Java 1.8.0_112 when changing between discrete and integrated GPU on a retina MacBook Pro. The deadlock is between: CGLGraphicsConfig.getCGLConfigInfo, running on AWT.EventQueue, trying to call [GraphicsConfigUtil _getCGLConfigInfo:] on the main thread (AppKit thread) while it holds the AWT lock and is synchronized on CGraphicsEnvironment. and A) the AppKit main thread trying to call CGraphicsEnvironment._displayReconfiguration (via displaycb_handle in CGraphicsEnv.m) and synchronizing on CGraphicsEnvironment?deadlock. or B) the AppKit main thread trying to render, and trying to acquire the OGLRenderQueue lock (which is the the AWT lock) SUPPORTING STACK DUMPS - SCENARIO A CGraphicsEnvironment._displayReconfiguration is called on the main thread since 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 ) which appears as changeset 11227. In the native thread dump below you can see the frame for displaycb_handle which is the block dispatched to the main thread to call CGraphicsEnvironment._displayReconfiguration. Java stacks "AWT-EventQueue-0" #16 prio=6 os_prio=31 tid=0x00007fbc72a0a800 nid=0x1251f runnable [0x000070000e443000] java.lang.Thread.State: RUNNABLE at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) [SNIP] at java.awt.Container.layout(Container.java:1510) at java.awt.Container.doLayout(Container.java:1499) at java.awt.Container.validateTree(Container.java:1695) [SNIP] at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1750) [SNIP] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fbc75046800 nid=0x307 waiting for monitor entry [0x00007fff5b579000] java.lang.Thread.State: BLOCKED (on object monitor) at sun.awt.CGraphicsEnvironment._displayReconfiguration(CGraphicsEnvironment.java:129) - waiting to lock <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) Native stacks Thread 0x6828c3 DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) cpu time <0.001 1000 start + 52 (Charles + 5156) [0x104682424] 1000 main + 153 (Charles + 5321) [0x1046824c9] 1000 launch + 10872 (Charles + 16520) [0x104685088] 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x104702624] 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x1047068fd] 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x113081dff] 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x1130fa14d] [SNIP] 1000 +[JNFRunLoop _performCopiedBlock:] + 17 (JavaNativeFoundation + 28474) [0x112d0df3a] 1000 __displaycb_handle_block_invoke_1 + 172 (libawt_lwawt.dylib + 119659) [0x11305936b] 1000 JNFPerformEnvBlock + 87 (JavaNativeFoundation + 27229) [0x112d0da5d] 1000 __displaycb_handle_block_invoke_2 + 80 (libawt_lwawt.dylib + 119988) [0x1130594b4] 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x112d0a5af] 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x106301539] 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10630ec03] 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] 1000 ??? [0x113db94e7] 1000 ??? [0x113dde021] 1000 InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) + 165 (libjvm.dylib + 2995347) [0x1062ef493] 1000 ObjectMonitor::enter(Thread*) + 472 (libjvm.dylib + 4524724) [0x106464ab4] 1000 ObjectMonitor::EnterI(Thread*) + 532 (libjvm.dylib + 4521584) [0x106463e70] 1000 os::PlatformEvent::park(long) + 404 (libjvm.dylib + 4561328) [0x10646d9b0] 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] Thread 0x68292c Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x106470d2a] 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10654f748] 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10654e091] 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x1063326d2] 1000 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 (libjvm.dylib + 3017936) [0x1062f4cd0] 1000 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356 (libjvm.dylib + 3017508) [0x1062f4b24] 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] [SNIP] 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x11305642a] 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] - Scenario B Java stacks "AWT-EventQueue-0" #15 prio=6 os_prio=31 tid=0x00007fba611d2000 nid=0x1260f runnable [0x0000700005365000] java.lang.Thread.State: RUNNABLE at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) at net.miginfocom.layout.UnitValue.getPixelsExact(UnitValue.java:305) at net.miginfocom.layout.UnitValue.getPixels(UnitValue.java:281) [SNIP] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fba59869800 nid=0x307 waiting on condition [0x00007fff52ac2000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000006c053b688> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) at sun.java2d.pipe.RenderQueue.lock(RenderQueue.java:112) at sun.java2d.opengl.CGLLayer.drawInCGLContext(CGLLayer.java:139) Native stacks Thread 0x6764ca DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) 1000 start + 52 (Charles + 5156) [0x10d139424] 1000 main + 153 (Charles + 5321) [0x10d1394c9] 1000 launch + 10872 (Charles + 16520) [0x10d13c088] 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x10d1b9624] 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x10d1bd8fd] 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x12abc3dff] 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x12ac3c14d] [SNIP] 1000 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 108 (QuartzCore + 69522) [0x7fff9d393f92] 1000 CA::Transaction::commit() + 475 (QuartzCore + 67121) [0x7fff9d393631] 1000 CA::Context::commit_transaction(CA::Transaction*) + 280 (QuartzCore + 1153144) [0x7fff9d49c878] 1000 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 (QuartzCore + 1196185) [0x7fff9d4a7099] 1000 CA::Layer::display_if_needed(CA::Transaction*) + 572 (QuartzCore + 1195886) [0x7fff9d4a6f6e] 1000 -[CAOpenGLLayer _display] + 351 (QuartzCore + 1117583) [0x7fff9d493d8f] 1000 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 873 (QuartzCore + 1118737) [0x7fff9d494211] 1000 -[CGLLayer drawInCGLContext:pixelFormat:forLayerTime:displayTime:] + 287 (libawt_lwawt.dylib + 109022) [0x12ab989de] 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x12a84f5af] 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x10edb8539] 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10edc5c03] 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x10edab396] 1000 ??? [0x10ffa0854] 1000 ??? [0x11027642a] 1000 Unsafe_Park + 126 (libjvm.dylib + 5571927) [0x10f01b557] 1000 Parker::park(bool, long) + 495 (libjvm.dylib + 4560765) [0x10ef2477d] 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] Thread 0x67652b Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x10ef27d2a] 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10f006748] 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10f005091] 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x10ede96d2] [SNIP] 1000 ??? [0x10f7a0734] 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x12ab9842a] 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] INTERPRETATION The deadlock is a race condition when macOS changes between the discrete and integrated GPU. When the GPU changes, the result of CGraphicsEnvironment.getMainDisplayID() changes immediately (There is a comment in CGraphicsEnvironment.m that notes that the display ID changes in this case, and I have verified this) to return the new displayID, while the devices map is only built once initDevices() is called. CGLGraphicsConfig.getCGLConfigInfo (which is called as a consequence of initDevices, as per stack traces) calls out and waits on the AppKit main thread. I think this is always dangerous due to the locks that the code calling it holds. I think we should avoid getCGLConfigInfo being called on anything but the AppKit main thread. I believe this was the intention of 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 ). CGraphicsEnvironment.getDefaultScreenDevice() is called from AWT layout code (as per the stacks) and it calls CGraphicsEnvironment.getMainDisplayID() each time. If CGraphicsEnvironment.getDefaultScreenDevice() is called _after_ the GPU change, but _before_ CGraphicsEnvironment._displayReconfiguration() has been called, the CGraphicsDevice for the new display ID cannot be found in the devices Map, so initDevices() is called from CGraphicsEnvironment.getDefaultScreenDevice() on the AWT-EventQueue thread. There is a note in getDefaultScreenDevice() for this case: we do not expect that this may happen, the only response is to re-initialize the list of devices Calling initDevices() here results in a call to CGLGraphicsConfig.getCGLConfigInfo, which then calls [GraphicsConfigUtil _getCGLConfigInfo:] on the AppKit main thread and waits for the result. As the current thread (AWT Event queue) is holding the AWT lock, and is synchronized on CGraphicsEnvironment, the two deadlock conditions described above can occur. REPRODUCABILITY This happens quite regularly on my machine, and for my users. To reproduce it I have launched my app while the integrated GPU is active, then launched and quit an app that requires the discrete GPU. One to five repetitions are required to create the hanging condition. I believe the issue is triggered by my use of MigLayout, which results in the call to CGraphicsEnvironment as per this excerpt from the stack traces above: at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) PATCH I believe the solution is to remember the main display ID along with the devices Map, and to change the main display ID when initDevices is called. This appears to work in my setup. There is however _sometimes_ a flash of half-size rendering, presumably while the rendering is working on the old device before the reconfiguration / initDevices occurs. Below is a simple patch to demonstrate that approach. Generally I don?t think initDevices() should ever be called on the AWT-EventQueue, but in my tests (as per the comment) that no longer happens with this patch. diff -r 5dd7e4bae5c2 src/macosx/classes/sun/awt/CGraphicsEnvironment.java --- a/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Thu Sep 22 13:17:42 2016 -0700 +++ b/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Sat Jan 07 20:49:39 2017 +1300 @@ -95,6 +95,7 @@ /** Available CoreGraphics displays. */ private final Map devices = new HashMap<>(5); + private int inittedMainDisplayID; /** Reference to the display reconfiguration callback context. */ private final long displayReconfigContext; @@ -153,6 +154,7 @@ devices.clear(); int mainID = getMainDisplayID(); + inittedMainDisplayID = mainID; // initialization of the graphics device may change // list of displays on hybrid systems via an activation @@ -173,14 +175,13 @@ @Override public synchronized GraphicsDevice getDefaultScreenDevice() throws HeadlessException { - final int mainDisplayID = getMainDisplayID(); - CGraphicsDevice d = devices.get(mainDisplayID); + CGraphicsDevice d = devices.get(inittedMainDisplayID); if (d == null) { // we do not expect that this may happen, the only response // is to re-initialize the list of devices initDevices(); - d = devices.get(mainDisplayID); + d = devices.get(inittedMainDisplayID); if (d == null) { throw new AWTError("no screen devices"); } From rob.mckenna at oracle.com Tue Jan 10 22:03:20 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 10 Jan 2017 22:03:20 +0000 Subject: [PATCH] Deadlock in CGLGraphicsConfig.getCGLConfigInfo In-Reply-To: References: Message-ID: <20170110220320.GA4813@tecra> Hi Karl, thanks for the submission. I'm sending this to awt-dev and bcc'ing jdk8u-dev as thats a more appropriate venue for this discussion. -Rob On 11/01/17 08:44, Karl von Randow wrote: > I have encountered a deadlock in Java 1.8.0_112 when changing between discrete and integrated GPU on a retina MacBook Pro. The deadlock is between: > > CGLGraphicsConfig.getCGLConfigInfo, running on AWT.EventQueue, trying to call [GraphicsConfigUtil _getCGLConfigInfo:] on > the main thread (AppKit thread) while it holds the AWT lock and is synchronized on CGraphicsEnvironment. > > and > > A) the AppKit main thread trying to call CGraphicsEnvironment._displayReconfiguration (via displaycb_handle in CGraphicsEnv.m) > and synchronizing on CGraphicsEnvironment?deadlock. > > or > > B) the AppKit main thread trying to render, and trying to acquire the OGLRenderQueue lock (which is the the AWT lock) > > > SUPPORTING STACK DUMPS > > - SCENARIO A > > CGraphicsEnvironment._displayReconfiguration is called on the main thread since > 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 ) which appears as changeset 11227. > In the native thread dump below you can see the frame for displaycb_handle which is the block dispatched to the main thread to call > CGraphicsEnvironment._displayReconfiguration. > > Java stacks > > "AWT-EventQueue-0" #16 prio=6 os_prio=31 tid=0x00007fbc72a0a800 nid=0x1251f runnable [0x000070000e443000] > java.lang.Thread.State: RUNNABLE > at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) > at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) > at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) > at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > [SNIP] > at java.awt.Container.layout(Container.java:1510) > at java.awt.Container.doLayout(Container.java:1499) > at java.awt.Container.validateTree(Container.java:1695) > [SNIP] > at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1750) > [SNIP] > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fbc75046800 nid=0x307 waiting for monitor entry [0x00007fff5b579000] > java.lang.Thread.State: BLOCKED (on object monitor) > at sun.awt.CGraphicsEnvironment._displayReconfiguration(CGraphicsEnvironment.java:129) > - waiting to lock <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > > Native stacks > > Thread 0x6828c3 DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) cpu time <0.001 > 1000 start + 52 (Charles + 5156) [0x104682424] > 1000 main + 153 (Charles + 5321) [0x1046824c9] > 1000 launch + 10872 (Charles + 16520) [0x104685088] > 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x104702624] > 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x1047068fd] > 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] > 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] > 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] > 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] > 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] > 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x113081dff] > 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x1130fa14d] > [SNIP] > 1000 +[JNFRunLoop _performCopiedBlock:] + 17 (JavaNativeFoundation + 28474) [0x112d0df3a] > 1000 __displaycb_handle_block_invoke_1 + 172 (libawt_lwawt.dylib + 119659) [0x11305936b] > 1000 JNFPerformEnvBlock + 87 (JavaNativeFoundation + 27229) [0x112d0da5d] > 1000 __displaycb_handle_block_invoke_2 + 80 (libawt_lwawt.dylib + 119988) [0x1130594b4] > 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x112d0a5af] > 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x106301539] > 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10630ec03] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] > 1000 ??? [0x113db94e7] > 1000 ??? [0x113dde021] > 1000 InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) + 165 (libjvm.dylib + 2995347) [0x1062ef493] > 1000 ObjectMonitor::enter(Thread*) + 472 (libjvm.dylib + 4524724) [0x106464ab4] > 1000 ObjectMonitor::EnterI(Thread*) + 532 (libjvm.dylib + 4521584) [0x106463e70] > 1000 os::PlatformEvent::park(long) + 404 (libjvm.dylib + 4561328) [0x10646d9b0] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > Thread 0x68292c Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) > 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] > 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] > 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] > 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x106470d2a] > 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10654f748] > 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10654e091] > 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x1063326d2] > 1000 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 (libjvm.dylib + 3017936) [0x1062f4cd0] > 1000 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356 (libjvm.dylib + 3017508) [0x1062f4b24] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] > [SNIP] > 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x11305642a] > 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] > 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] > 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > > > > > > - Scenario B > > Java stacks > > "AWT-EventQueue-0" #15 prio=6 os_prio=31 tid=0x00007fba611d2000 nid=0x1260f runnable [0x0000700005365000] > java.lang.Thread.State: RUNNABLE > at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) > at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) > at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) > at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) > - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > at net.miginfocom.layout.UnitValue.getPixelsExact(UnitValue.java:305) > at net.miginfocom.layout.UnitValue.getPixels(UnitValue.java:281) > [SNIP] > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fba59869800 nid=0x307 waiting on condition [0x00007fff52ac2000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000006c053b688> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) > at sun.java2d.pipe.RenderQueue.lock(RenderQueue.java:112) > at sun.java2d.opengl.CGLLayer.drawInCGLContext(CGLLayer.java:139) > > Native stacks > > Thread 0x6764ca DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) > 1000 start + 52 (Charles + 5156) [0x10d139424] > 1000 main + 153 (Charles + 5321) [0x10d1394c9] > 1000 launch + 10872 (Charles + 16520) [0x10d13c088] > 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x10d1b9624] > 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x10d1bd8fd] > 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] > 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] > 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] > 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] > 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] > 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x12abc3dff] > 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x12ac3c14d] > [SNIP] > 1000 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 108 (QuartzCore + 69522) [0x7fff9d393f92] > 1000 CA::Transaction::commit() + 475 (QuartzCore + 67121) [0x7fff9d393631] > 1000 CA::Context::commit_transaction(CA::Transaction*) + 280 (QuartzCore + 1153144) [0x7fff9d49c878] > 1000 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 (QuartzCore + 1196185) [0x7fff9d4a7099] > 1000 CA::Layer::display_if_needed(CA::Transaction*) + 572 (QuartzCore + 1195886) [0x7fff9d4a6f6e] > 1000 -[CAOpenGLLayer _display] + 351 (QuartzCore + 1117583) [0x7fff9d493d8f] > 1000 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 873 (QuartzCore + 1118737) [0x7fff9d494211] > 1000 -[CGLLayer drawInCGLContext:pixelFormat:forLayerTime:displayTime:] + 287 (libawt_lwawt.dylib + 109022) [0x12ab989de] > 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x12a84f5af] > 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x10edb8539] > 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10edc5c03] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x10edab396] > 1000 ??? [0x10ffa0854] > 1000 ??? [0x11027642a] > 1000 Unsafe_Park + 126 (libjvm.dylib + 5571927) [0x10f01b557] > 1000 Parker::park(bool, long) + 495 (libjvm.dylib + 4560765) [0x10ef2477d] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > Thread 0x67652b Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) > 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] > 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] > 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] > 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x10ef27d2a] > 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10f006748] > 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10f005091] > 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x10ede96d2] > [SNIP] > 1000 ??? [0x10f7a0734] > 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x12ab9842a] > 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] > 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] > 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > > INTERPRETATION > > The deadlock is a race condition when macOS changes between the discrete and integrated GPU. > > When the GPU changes, the result of CGraphicsEnvironment.getMainDisplayID() changes immediately (There is a comment in CGraphicsEnvironment.m > that notes that the display ID changes in this case, and I have verified this) to return the new displayID, while the devices map is only built once initDevices() is called. > > CGLGraphicsConfig.getCGLConfigInfo (which is called as a consequence of initDevices, as per stack traces) calls out and waits on the AppKit main thread. I think this is > always dangerous due to the locks that the code calling it holds. I think we should avoid getCGLConfigInfo being called on anything but the AppKit main thread. I believe > this was the intention of 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 ). > > CGraphicsEnvironment.getDefaultScreenDevice() is called from AWT layout code (as per the stacks) and it calls CGraphicsEnvironment.getMainDisplayID() each time. > If CGraphicsEnvironment.getDefaultScreenDevice() is called _after_ the GPU change, but _before_ CGraphicsEnvironment._displayReconfiguration() has been called, > the CGraphicsDevice for the new display ID cannot be found in the devices Map, so initDevices() is called from CGraphicsEnvironment.getDefaultScreenDevice() > on the AWT-EventQueue thread. > > There is a note in getDefaultScreenDevice() for this case: > we do not expect that this may happen, the only response is to re-initialize the list of devices > > Calling initDevices() here results in a call to CGLGraphicsConfig.getCGLConfigInfo, which then calls > [GraphicsConfigUtil _getCGLConfigInfo:] on the AppKit main thread and waits for the result. > > As the current thread (AWT Event queue) is holding the AWT lock, and is synchronized on CGraphicsEnvironment, the two deadlock > conditions described above can occur. > > > REPRODUCABILITY > > This happens quite regularly on my machine, and for my users. To reproduce it I have launched my app while the integrated GPU is active, then launched and quit an app that requires the discrete GPU. One to five repetitions are required to create the hanging condition. > > I believe the issue is triggered by my use of MigLayout, which results in the call to CGraphicsEnvironment as per this excerpt from the stack traces above: > > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > > > PATCH > > I believe the solution is to remember the main display ID along with the devices Map, and to change the main display ID when initDevices is called. > This appears to work in my setup. There is however _sometimes_ a flash of half-size rendering, presumably while the rendering is working on the old device > before the reconfiguration / initDevices occurs. > > Below is a simple patch to demonstrate that approach. Generally I don?t think initDevices() should ever be called on the AWT-EventQueue, but in my tests (as per the comment) > that no longer happens with this patch. > > diff -r 5dd7e4bae5c2 src/macosx/classes/sun/awt/CGraphicsEnvironment.java > --- a/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Thu Sep 22 13:17:42 2016 -0700 > +++ b/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Sat Jan 07 20:49:39 2017 +1300 > @@ -95,6 +95,7 @@ > > /** Available CoreGraphics displays. */ > private final Map devices = new HashMap<>(5); > + private int inittedMainDisplayID; > > /** Reference to the display reconfiguration callback context. */ > private final long displayReconfigContext; > @@ -153,6 +154,7 @@ > devices.clear(); > > int mainID = getMainDisplayID(); > + inittedMainDisplayID = mainID; > > // initialization of the graphics device may change > // list of displays on hybrid systems via an activation > @@ -173,14 +175,13 @@ > > @Override > public synchronized GraphicsDevice getDefaultScreenDevice() throws HeadlessException { > - final int mainDisplayID = getMainDisplayID(); > - CGraphicsDevice d = devices.get(mainDisplayID); > + CGraphicsDevice d = devices.get(inittedMainDisplayID); > if (d == null) { > // we do not expect that this may happen, the only response > // is to re-initialize the list of devices > initDevices(); > > - d = devices.get(mainDisplayID); > + d = devices.get(inittedMainDisplayID); > if (d == null) { > throw new AWTError("no screen devices"); > } > > > > From jamsheed.c.m at oracle.com Wed Jan 11 02:52:26 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 11 Jan 2017 08:22:26 +0530 Subject: RFR[8u]: 8164293: HotSpot leaking memory in long-running requests In-Reply-To: References: <850634c4-12f8-f1b0-52c3-3e28d091af54@oracle.com> <58340183.50508@oracle.com> <63eb1cab-fb3c-86d7-d446-87445d06cb99@oracle.com> <58356BD2.80605@oracle.com> <053df620-54c3-8dde-e6aa-56a1f10139c7@oracle.com> Message-ID: Thank you for the review, Vladimir. Best Regards, Jamsheed On 1/10/2017 10:39 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 1/6/17 4:11 AM, Jamsheed C m wrote: >> Thank you for the review, Tobias. >> >> could i get a second review please. also, request for approval from >> 8u-dev. >> >> Best Regards, >> >> Jamsheed >> >> >> On 11/23/2016 3:43 PM, Tobias Hartmann wrote: >>> Hi Jamsheed, >>> >>> On 22.11.2016 17:41, Jamsheed C m wrote: >>>> Hi, >>>> >>>> On 11/22/2016 6:09 PM, Jamsheed C m wrote: >>>>> Hi Tobias, >>>>> >>>>> On 11/22/2016 1:57 PM, Tobias Hartmann wrote: >>>>>> Hi Jamsheed, >>>>>> >>>>>> On 22.11.2016 08:37, Jamsheed C m wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Request for review. >>>>>>> >>>>>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8164293 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8164293/webrev.00/ >>>>>> I think the resource marks in the sweeper could be "moved up" in >>>>>> the scope but looking at the JDK 9 code, we have them at the places >>>>>> you suggested so I think it's fine for consistency reasons. The JDK >>>>>> 9 code is not affected because it was fixed with JDK-8046809, right? >>>>> Yes, Done. >>>>>> Please add this as a comment to the bug. >>>>>> >>>>>> Why do we need a RM in nmethod::clear_ic_stubs()? It's also missing >>>>>> in JDK 9 code. >>>>> This one was causing the leak in sweeper task(product build >>>>> without logging option). RM added in >>>>> NMethodSweeper::sweep_code_cache should be enough as it is sole user >>>>> of the function. I added RM in clear_ic_stubs too to make sure that >>>>> there is no misses in future. It is good to have change in JDK9, as >>>>> said in (https://bugs.openjdk.java.net/browse/JDK-8059675) >>>>> >>>>>>> Desc: There were a few memory leaks in thread arena due to >>>>>>> sweeper task. >>>>>>> >>>>>>> Fix: Applied ResourceMark wherever applicable. >>>>>>> >>>>>>> The slow growth of mtClass malloc(the one reported in bug) is not >>>>>>> memory leak. It is application behavior in low codecache size >>>>>>> setting( frequent sweeps), more InstanceKlass requires OopMapCache >>>>>>> initialized here. >>>>>> Could you please elaborate on this? Why do we create more >>>>>> InstanceKlasses? And why is this behavior not stabilizing? >>>>> It doesn't create more InstanceKlasses. No of InstanceKlasses is >>>>> 5649 is kind of stable. OopMapCache for an InstanceKlass get >>>>> initialized on first request (Interpreter frame walk during gc). >>>>> Stabilizing thing is yet to be checked as i did all my analysis in >>>>> debug mode(with gdb attached). It is confirmed that the rate of >>>>> memory growth in steadily decreasing, and all OopMapCache allocation >>>>> happen for unique InstanceKlass. >>>> i meant "each OopMapCache allocation happen for unique >>>> InstanceKlass", sorry for the typo. >>> Okay, as we discussed offline, please file a new bug to keep track of >>> the OopMapCache issue. >>> >>> I'm fine with the current sweeper fix (not an 8u reviewer). >>> >>> Thanks, >>> Tobias >>> >>>> Best Regards, >>>> Jamsheed >>>>> i have a product instance with fixes running now for a day. i can >>>>> wait a few more days to confirm that i don't miss anything. >>>>> >>>>> Best Regards, >>>>> Jamsheed >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Jamsheed >>>>>>> >> From david.buck at oracle.com Wed Jan 11 08:20:49 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 11 Jan 2017 17:20:49 +0900 Subject: RFR[8u]: 8164293: HotSpot leaking memory in long-running requests In-Reply-To: References: <850634c4-12f8-f1b0-52c3-3e28d091af54@oracle.com> <58340183.50508@oracle.com> <63eb1cab-fb3c-86d7-d446-87445d06cb99@oracle.com> <58356BD2.80605@oracle.com> <053df620-54c3-8dde-e6aa-56a1f10139c7@oracle.com> Message-ID: approved for push to 8u-dev Cheers, -Buck > On Jan 11, 2017, at 11:52, Jamsheed C m wrote: > > Thank you for the review, Vladimir. > > Best Regards, > > Jamsheed > > > On 1/10/2017 10:39 PM, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On 1/6/17 4:11 AM, Jamsheed C m wrote: >>> Thank you for the review, Tobias. >>> >>> could i get a second review please. also, request for approval from >>> 8u-dev. >>> >>> Best Regards, >>> >>> Jamsheed >>> >>> >>> On 11/23/2016 3:43 PM, Tobias Hartmann wrote: >>>> Hi Jamsheed, >>>> >>>> On 22.11.2016 17:41, Jamsheed C m wrote: >>>>> Hi, >>>>> >>>>> On 11/22/2016 6:09 PM, Jamsheed C m wrote: >>>>>> Hi Tobias, >>>>>> >>>>>> On 11/22/2016 1:57 PM, Tobias Hartmann wrote: >>>>>>> Hi Jamsheed, >>>>>>> >>>>>>> On 22.11.2016 08:37, Jamsheed C m wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Request for review. >>>>>>>> >>>>>>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8164293 >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8164293/webrev.00/ >>>>>>> I think the resource marks in the sweeper could be "moved up" in >>>>>>> the scope but looking at the JDK 9 code, we have them at the places >>>>>>> you suggested so I think it's fine for consistency reasons. The JDK >>>>>>> 9 code is not affected because it was fixed with JDK-8046809, right? >>>>>> Yes, Done. >>>>>>> Please add this as a comment to the bug. >>>>>>> >>>>>>> Why do we need a RM in nmethod::clear_ic_stubs()? It's also missing >>>>>>> in JDK 9 code. >>>>>> This one was causing the leak in sweeper task(product build >>>>>> without logging option). RM added in >>>>>> NMethodSweeper::sweep_code_cache should be enough as it is sole user >>>>>> of the function. I added RM in clear_ic_stubs too to make sure that >>>>>> there is no misses in future. It is good to have change in JDK9, as >>>>>> said in (https://bugs.openjdk.java.net/browse/JDK-8059675) >>>>>> >>>>>>>> Desc: There were a few memory leaks in thread arena due to >>>>>>>> sweeper task. >>>>>>>> >>>>>>>> Fix: Applied ResourceMark wherever applicable. >>>>>>>> >>>>>>>> The slow growth of mtClass malloc(the one reported in bug) is not >>>>>>>> memory leak. It is application behavior in low codecache size >>>>>>>> setting( frequent sweeps), more InstanceKlass requires OopMapCache >>>>>>>> initialized here. >>>>>>> Could you please elaborate on this? Why do we create more >>>>>>> InstanceKlasses? And why is this behavior not stabilizing? >>>>>> It doesn't create more InstanceKlasses. No of InstanceKlasses is >>>>>> 5649 is kind of stable. OopMapCache for an InstanceKlass get >>>>>> initialized on first request (Interpreter frame walk during gc). >>>>>> Stabilizing thing is yet to be checked as i did all my analysis in >>>>>> debug mode(with gdb attached). It is confirmed that the rate of >>>>>> memory growth in steadily decreasing, and all OopMapCache allocation >>>>>> happen for unique InstanceKlass. >>>>> i meant "each OopMapCache allocation happen for unique >>>>> InstanceKlass", sorry for the typo. >>>> Okay, as we discussed offline, please file a new bug to keep track of >>>> the OopMapCache issue. >>>> >>>> I'm fine with the current sweeper fix (not an 8u reviewer). >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> Best Regards, >>>>> Jamsheed >>>>>> i have a product instance with fixes running now for a day. i can >>>>>> wait a few more days to confirm that i don't miss anything. >>>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> >>> > From sean.coffey at oracle.com Wed Jan 11 08:57:36 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 11 Jan 2017 08:57:36 +0000 Subject: [PATCH] Deadlock in CGLGraphicsConfig.getCGLConfigInfo In-Reply-To: References: Message-ID: <43b827ed-d88d-8da0-77f2-041d63a4c93f@oracle.com> Karl, Thanks for the report. Technical issues of a specific nature should be discussed on the relevant OpenJDK mailing list. For this issue, I suggest you reach out to the awt-dev mailing list [1]. You may also want to consider reporting this via the bug database if you haven't done so already [2]. regards, Sean. [1] http://mail.openjdk.java.net/mailman/listinfo/awt-dev [2] http://bugs.java.com/ On 10/01/2017 19:44, Karl von Randow wrote: > I have encountered a deadlock in Java 1.8.0_112 when changing between discrete and integrated GPU on a retina MacBook Pro. The deadlock is between: > > CGLGraphicsConfig.getCGLConfigInfo, running on AWT.EventQueue, trying to call [GraphicsConfigUtil _getCGLConfigInfo:] on > the main thread (AppKit thread) while it holds the AWT lock and is synchronized on CGraphicsEnvironment. > > and > > A) the AppKit main thread trying to call CGraphicsEnvironment._displayReconfiguration (via displaycb_handle in CGraphicsEnv.m) > and synchronizing on CGraphicsEnvironment?deadlock. > > or > > B) the AppKit main thread trying to render, and trying to acquire the OGLRenderQueue lock (which is the the AWT lock) > > > SUPPORTING STACK DUMPS > > - SCENARIO A > > CGraphicsEnvironment._displayReconfiguration is called on the main thread since > 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 ) which appears as changeset 11227. > In the native thread dump below you can see the frame for displaycb_handle which is the block dispatched to the main thread to call > CGraphicsEnvironment._displayReconfiguration. > > Java stacks > > "AWT-EventQueue-0" #16 prio=6 os_prio=31 tid=0x00007fbc72a0a800 nid=0x1251f runnable [0x000070000e443000] > java.lang.Thread.State: RUNNABLE > at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) > at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) > at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) > at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > [SNIP] > at java.awt.Container.layout(Container.java:1510) > at java.awt.Container.doLayout(Container.java:1499) > at java.awt.Container.validateTree(Container.java:1695) > [SNIP] > at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1750) > [SNIP] > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fbc75046800 nid=0x307 waiting for monitor entry [0x00007fff5b579000] > java.lang.Thread.State: BLOCKED (on object monitor) > at sun.awt.CGraphicsEnvironment._displayReconfiguration(CGraphicsEnvironment.java:129) > - waiting to lock <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > > Native stacks > > Thread 0x6828c3 DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) cpu time <0.001 > 1000 start + 52 (Charles + 5156) [0x104682424] > 1000 main + 153 (Charles + 5321) [0x1046824c9] > 1000 launch + 10872 (Charles + 16520) [0x104685088] > 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x104702624] > 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x1047068fd] > 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] > 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] > 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] > 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] > 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] > 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x113081dff] > 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x1130fa14d] > [SNIP] > 1000 +[JNFRunLoop _performCopiedBlock:] + 17 (JavaNativeFoundation + 28474) [0x112d0df3a] > 1000 __displaycb_handle_block_invoke_1 + 172 (libawt_lwawt.dylib + 119659) [0x11305936b] > 1000 JNFPerformEnvBlock + 87 (JavaNativeFoundation + 27229) [0x112d0da5d] > 1000 __displaycb_handle_block_invoke_2 + 80 (libawt_lwawt.dylib + 119988) [0x1130594b4] > 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x112d0a5af] > 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x106301539] > 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10630ec03] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] > 1000 ??? [0x113db94e7] > 1000 ??? [0x113dde021] > 1000 InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) + 165 (libjvm.dylib + 2995347) [0x1062ef493] > 1000 ObjectMonitor::enter(Thread*) + 472 (libjvm.dylib + 4524724) [0x106464ab4] > 1000 ObjectMonitor::EnterI(Thread*) + 532 (libjvm.dylib + 4521584) [0x106463e70] > 1000 os::PlatformEvent::park(long) + 404 (libjvm.dylib + 4561328) [0x10646d9b0] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > Thread 0x68292c Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) > 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] > 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] > 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] > 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x106470d2a] > 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10654f748] > 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10654e091] > 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x1063326d2] > 1000 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74 (libjvm.dylib + 3017936) [0x1062f4cd0] > 1000 JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 356 (libjvm.dylib + 3017508) [0x1062f4b24] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x1062f4396] > [SNIP] > 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x11305642a] > 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] > 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] > 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > > > > > > - Scenario B > > Java stacks > > "AWT-EventQueue-0" #15 prio=6 os_prio=31 tid=0x00007fba611d2000 nid=0x1260f runnable [0x0000700005365000] > java.lang.Thread.State: RUNNABLE > at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(Native Method) > at sun.java2d.opengl.CGLGraphicsConfig.getConfig(CGLGraphicsConfig.java:147) > at sun.awt.CGraphicsDevice.(CGraphicsDevice.java:64) > at sun.awt.CGraphicsEnvironment.initDevices(CGraphicsEnvironment.java:163) > - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0df8c18> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > at net.miginfocom.layout.UnitValue.getPixelsExact(UnitValue.java:305) > at net.miginfocom.layout.UnitValue.getPixels(UnitValue.java:281) > [SNIP] > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > "AppKit Thread" #11 daemon prio=5 os_prio=31 tid=0x00007fba59869800 nid=0x307 waiting on condition [0x00007fff52ac2000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000006c053b688> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at sun.awt.SunToolkit.awtLock(SunToolkit.java:253) > at sun.java2d.pipe.RenderQueue.lock(RenderQueue.java:112) > at sun.java2d.opengl.CGLLayer.drawInCGLContext(CGLLayer.java:139) > > Native stacks > > Thread 0x6764ca DispatchQueue 1 Thread name "AppKit Thread" 1000 samples (1-1000) priority 46 (base 46) > 1000 start + 52 (Charles + 5156) [0x10d139424] > 1000 main + 153 (Charles + 5321) [0x10d1394c9] > 1000 launch + 10872 (Charles + 16520) [0x10d13c088] > 1000 JLI_Launch + 1952 (libjli.dylib + 5668) [0x10d1b9624] > 1000 CreateExecutionEnvironment + 871 (libjli.dylib + 22781) [0x10d1bd8fd] > 1000 CFRunLoopRunSpecific + 420 (CoreFoundation + 555380) [0x7fff97665974] > 1000 __CFRunLoopRun + 934 (CoreFoundation + 556918) [0x7fff97665f76] > 1000 __CFRunLoopDoSources0 + 557 (CoreFoundation + 559741) [0x7fff97666a7d] > 1000 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 686465) [0x7fff97685981] > 1000 __NSThreadPerformPerform + 326 (Foundation + 465034) [0x7fff990c988a] > 1000 -[AWTStarter starter:] + 905 (libawt_lwawt.dylib + 286207) [0x12abc3dff] > 1000 +[NSApplicationAWT runAWTLoopWithApp:] + 156 (libosxapp.dylib + 8525) [0x12ac3c14d] > [SNIP] > 1000 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 108 (QuartzCore + 69522) [0x7fff9d393f92] > 1000 CA::Transaction::commit() + 475 (QuartzCore + 67121) [0x7fff9d393631] > 1000 CA::Context::commit_transaction(CA::Transaction*) + 280 (QuartzCore + 1153144) [0x7fff9d49c878] > 1000 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35 (QuartzCore + 1196185) [0x7fff9d4a7099] > 1000 CA::Layer::display_if_needed(CA::Transaction*) + 572 (QuartzCore + 1195886) [0x7fff9d4a6f6e] > 1000 -[CAOpenGLLayer _display] + 351 (QuartzCore + 1117583) [0x7fff9d493d8f] > 1000 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 873 (QuartzCore + 1118737) [0x7fff9d494211] > 1000 -[CGLLayer drawInCGLContext:pixelFormat:forLayerTime:displayTime:] + 287 (libawt_lwawt.dylib + 109022) [0x12ab989de] > 1000 JNFCallVoidMethod + 187 (JavaNativeFoundation + 13743) [0x12a84f5af] > 1000 jni_CallVoidMethodV + 248 (libjvm.dylib + 3069241) [0x10edb8539] > 1000 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 748 (libjvm.dylib + 3124227) [0x10edc5c03] > 1000 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 1710 (libjvm.dylib + 3015574) [0x10edab396] > 1000 ??? [0x10ffa0854] > 1000 ??? [0x11027642a] > 1000 Unsafe_Park + 126 (libjvm.dylib + 5571927) [0x10f01b557] > 1000 Parker::park(bool, long) + 495 (libjvm.dylib + 4560765) [0x10ef2477d] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > Thread 0x67652b Thread name "Java: AWT-EventQueue-0" 1000 samples (1-1000) priority 31 (base 31) > 1000 thread_start + 13 (libsystem_pthread.dylib + 12797) [0x7fffacdd51fd] > 1000 _pthread_start + 286 (libsystem_pthread.dylib + 14839) [0x7fffacdd59f7] > 1000 _pthread_body + 180 (libsystem_pthread.dylib + 15019) [0x7fffacdd5aab] > 1000 java_start(Thread*) + 246 (libjvm.dylib + 4574506) [0x10ef27d2a] > 1000 JavaThread::run() + 448 (libjvm.dylib + 5486408) [0x10f006748] > 1000 JavaThread::thread_main_inner() + 155 (libjvm.dylib + 5480593) [0x10f005091] > 1000 thread_entry(JavaThread*, Thread*) + 124 (libjvm.dylib + 3270354) [0x10ede96d2] > [SNIP] > 1000 ??? [0x10f7a0734] > 1000 Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo + 279 (libawt_lwawt.dylib + 107562) [0x12ab9842a] > 1000 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 131 (Foundation + 203394) [0x7fff99089a82] > 1000 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 904 (Foundation + 204424) [0x7fff99089e88] > 1000 -[NSCondition wait] + 240 (Foundation + 208331) [0x7fff9908adcb] > 1000 __psynch_cvwait + 10 (libsystem_kernel.dylib + 105606) [0x7fffaccecc86] > *1000 psynch_cvcontinue + 0 (pthread + 39138) [0xffffff7f80f978e2] > > > INTERPRETATION > > The deadlock is a race condition when macOS changes between the discrete and integrated GPU. > > When the GPU changes, the result of CGraphicsEnvironment.getMainDisplayID() changes immediately (There is a comment in CGraphicsEnvironment.m > that notes that the display ID changes in this case, and I have verified this) to return the new displayID, while the devices map is only built once initDevices() is called. > > CGLGraphicsConfig.getCGLConfigInfo (which is called as a consequence of initDevices, as per stack traces) calls out and waits on the AppKit main thread. I think this is > always dangerous due to the locks that the code calling it holds. I think we should avoid getCGLConfigInfo being called on anything but the AppKit main thread. I believe > this was the intention of 8041900: [macosx] Java forces the use of discrete GPU (https://bugs.openjdk.java.net/browse/JDK-8041900 ). > > CGraphicsEnvironment.getDefaultScreenDevice() is called from AWT layout code (as per the stacks) and it calls CGraphicsEnvironment.getMainDisplayID() each time. > If CGraphicsEnvironment.getDefaultScreenDevice() is called _after_ the GPU change, but _before_ CGraphicsEnvironment._displayReconfiguration() has been called, > the CGraphicsDevice for the new display ID cannot be found in the devices Map, so initDevices() is called from CGraphicsEnvironment.getDefaultScreenDevice() > on the AWT-EventQueue thread. > > There is a note in getDefaultScreenDevice() for this case: > we do not expect that this may happen, the only response is to re-initialize the list of devices > > Calling initDevices() here results in a call to CGLGraphicsConfig.getCGLConfigInfo, which then calls > [GraphicsConfigUtil _getCGLConfigInfo:] on the AppKit main thread and waits for the result. > > As the current thread (AWT Event queue) is holding the AWT lock, and is synchronized on CGraphicsEnvironment, the two deadlock > conditions described above can occur. > > > REPRODUCABILITY > > This happens quite regularly on my machine, and for my users. To reproduce it I have launched my app while the integrated GPU is active, then launched and quit an app that requires the discrete GPU. One to five repetitions are required to create the hanging condition. > > I believe the issue is triggered by my use of MigLayout, which results in the call to CGraphicsEnvironment as per this excerpt from the stack traces above: > > at sun.awt.CGraphicsEnvironment.getDefaultScreenDevice(CGraphicsEnvironment.java:181) > - locked <0x00000006c0721bb0> (a sun.awt.CGraphicsEnvironment) > at sun.lwawt.macosx.LWCToolkit.getScreenResolution(LWCToolkit.java:415) > at net.miginfocom.swing.SwingComponentWrapper.getHorizontalScreenDPI(SwingComponentWrapper.java:260) > at net.miginfocom.swing.SwingComponentWrapper.getPixelUnitFactor(SwingComponentWrapper.java:119) > > > PATCH > > I believe the solution is to remember the main display ID along with the devices Map, and to change the main display ID when initDevices is called. > This appears to work in my setup. There is however _sometimes_ a flash of half-size rendering, presumably while the rendering is working on the old device > before the reconfiguration / initDevices occurs. > > Below is a simple patch to demonstrate that approach. Generally I don?t think initDevices() should ever be called on the AWT-EventQueue, but in my tests (as per the comment) > that no longer happens with this patch. > > diff -r 5dd7e4bae5c2 src/macosx/classes/sun/awt/CGraphicsEnvironment.java > --- a/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Thu Sep 22 13:17:42 2016 -0700 > +++ b/src/macosx/classes/sun/awt/CGraphicsEnvironment.java Sat Jan 07 20:49:39 2017 +1300 > @@ -95,6 +95,7 @@ > > /** Available CoreGraphics displays. */ > private final Map devices = new HashMap<>(5); > + private int inittedMainDisplayID; > > /** Reference to the display reconfiguration callback context. */ > private final long displayReconfigContext; > @@ -153,6 +154,7 @@ > devices.clear(); > > int mainID = getMainDisplayID(); > + inittedMainDisplayID = mainID; > > // initialization of the graphics device may change > // list of displays on hybrid systems via an activation > @@ -173,14 +175,13 @@ > > @Override > public synchronized GraphicsDevice getDefaultScreenDevice() throws HeadlessException { > - final int mainDisplayID = getMainDisplayID(); > - CGraphicsDevice d = devices.get(mainDisplayID); > + CGraphicsDevice d = devices.get(inittedMainDisplayID); > if (d == null) { > // we do not expect that this may happen, the only response > // is to re-initialize the list of devices > initDevices(); > > - d = devices.get(mainDisplayID); > + d = devices.get(inittedMainDisplayID); > if (d == null) { > throw new AWTError("no screen devices"); > } > > > > From jamsheed.c.m at oracle.com Wed Jan 11 09:48:08 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Wed, 11 Jan 2017 15:18:08 +0530 Subject: RFR[8u]: 8164293: HotSpot leaking memory in long-running requests In-Reply-To: References: <850634c4-12f8-f1b0-52c3-3e28d091af54@oracle.com> <58340183.50508@oracle.com> <63eb1cab-fb3c-86d7-d446-87445d06cb99@oracle.com> <58356BD2.80605@oracle.com> <053df620-54c3-8dde-e6aa-56a1f10139c7@oracle.com> Message-ID: <2bfce2be-7c12-dc0d-cb84-82cddbba5db8@oracle.com> Thank you, David. Best Regards, Jamsheed On 1/11/2017 1:50 PM, David Buck wrote: > approved for push to 8u-dev > > Cheers, > -Buck > >> On Jan 11, 2017, at 11:52, Jamsheed C m wrote: >> >> Thank you for the review, Vladimir. >> >> Best Regards, >> >> Jamsheed >> >> >> On 1/10/2017 10:39 PM, Vladimir Kozlov wrote: >>> Good. >>> >>> Thanks, >>> Vladimir >>> >>> On 1/6/17 4:11 AM, Jamsheed C m wrote: >>>> Thank you for the review, Tobias. >>>> >>>> could i get a second review please. also, request for approval from >>>> 8u-dev. >>>> >>>> Best Regards, >>>> >>>> Jamsheed >>>> >>>> >>>> On 11/23/2016 3:43 PM, Tobias Hartmann wrote: >>>>> Hi Jamsheed, >>>>> >>>>> On 22.11.2016 17:41, Jamsheed C m wrote: >>>>>> Hi, >>>>>> >>>>>> On 11/22/2016 6:09 PM, Jamsheed C m wrote: >>>>>>> Hi Tobias, >>>>>>> >>>>>>> On 11/22/2016 1:57 PM, Tobias Hartmann wrote: >>>>>>>> Hi Jamsheed, >>>>>>>> >>>>>>>> On 22.11.2016 08:37, Jamsheed C m wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Request for review. >>>>>>>>> >>>>>>>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8164293 >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~jcm/8164293/webrev.00/ >>>>>>>> I think the resource marks in the sweeper could be "moved up" in >>>>>>>> the scope but looking at the JDK 9 code, we have them at the places >>>>>>>> you suggested so I think it's fine for consistency reasons. The JDK >>>>>>>> 9 code is not affected because it was fixed with JDK-8046809, right? >>>>>>> Yes, Done. >>>>>>>> Please add this as a comment to the bug. >>>>>>>> >>>>>>>> Why do we need a RM in nmethod::clear_ic_stubs()? It's also missing >>>>>>>> in JDK 9 code. >>>>>>> This one was causing the leak in sweeper task(product build >>>>>>> without logging option). RM added in >>>>>>> NMethodSweeper::sweep_code_cache should be enough as it is sole user >>>>>>> of the function. I added RM in clear_ic_stubs too to make sure that >>>>>>> there is no misses in future. It is good to have change in JDK9, as >>>>>>> said in (https://bugs.openjdk.java.net/browse/JDK-8059675) >>>>>>> >>>>>>>>> Desc: There were a few memory leaks in thread arena due to >>>>>>>>> sweeper task. >>>>>>>>> >>>>>>>>> Fix: Applied ResourceMark wherever applicable. >>>>>>>>> >>>>>>>>> The slow growth of mtClass malloc(the one reported in bug) is not >>>>>>>>> memory leak. It is application behavior in low codecache size >>>>>>>>> setting( frequent sweeps), more InstanceKlass requires OopMapCache >>>>>>>>> initialized here. >>>>>>>> Could you please elaborate on this? Why do we create more >>>>>>>> InstanceKlasses? And why is this behavior not stabilizing? >>>>>>> It doesn't create more InstanceKlasses. No of InstanceKlasses is >>>>>>> 5649 is kind of stable. OopMapCache for an InstanceKlass get >>>>>>> initialized on first request (Interpreter frame walk during gc). >>>>>>> Stabilizing thing is yet to be checked as i did all my analysis in >>>>>>> debug mode(with gdb attached). It is confirmed that the rate of >>>>>>> memory growth in steadily decreasing, and all OopMapCache allocation >>>>>>> happen for unique InstanceKlass. >>>>>> i meant "each OopMapCache allocation happen for unique >>>>>> InstanceKlass", sorry for the typo. >>>>> Okay, as we discussed offline, please file a new bug to keep track of >>>>> the OopMapCache issue. >>>>> >>>>> I'm fine with the current sweeper fix (not an 8u reviewer). >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> Best Regards, >>>>>> Jamsheed >>>>>>> i have a product instance with fixes running now for a day. i can >>>>>>> wait a few more days to confirm that i don't miss anything. >>>>>>> >>>>>>> Best Regards, >>>>>>> Jamsheed >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> From aleksej.efimov at oracle.com Wed Jan 11 13:01:47 2017 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 11 Jan 2017 16:01:47 +0300 Subject: [8u-dev] Request for Approval: 8159058: SAXParseException when sending soap message Message-ID: Hello, Please, approve a backport of JDK-8159058 to JDK8u-dev. This is almost straight-forward backport except one difference: com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java is not part of JDK8 JAXWS version and therefore this changes wasn't backported/not needed. Regression test and other source changes were applied cleanly after reshuffling. Testing shows no related failures: JDK regression tests (with backported one), JCK runtime jaxws/b related test. With Best Regards, Aleksej JBS: https://bugs.openjdk.java.net/browse/JDK-8159058 JDK8 webrev: http://cr.openjdk.java.net/~aefimov/8159058/8/00/ JDK9 changesets: http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/a98174edd246 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/766677da17b5 JDK9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045785.html From christoph.langer at sap.com Wed Jan 11 13:28:17 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Jan 2017 13:28:17 +0000 Subject: [8u-dev]: Request for Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set Message-ID: Hi, please approve this downport. Thanks, Chris, for the Review. Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Mittwoch, 11. Januar 2017 11:47 > To: Langer, Christoph > Cc: net-dev at openjdk.java.net > Subject: Re: [8u-dev]: Request for Review and Approval: 8075484: > SocketInputStream.socketRead0 can hang even with soTimeout set > > Hi Christoph, > > > On 9 Jan 2017, at 05:56, Langer, Christoph > wrote: > > > > Ping: Please review this backport to JDK8. > > > > From: Langer, Christoph > > Sent: Donnerstag, 29. Dezember 2016 10:37 > > To: net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > > Subject: [8u-dev]: Request for Review and Approval: 8075484: > SocketInputStream.socketRead0 can hang even with soTimeout set > > > > Hi, > > > > please review (and eventually approve) the change for downporting 8075484. > > > > Webrev for 8u-dev: > http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ > > The changes look ok to me. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 > > JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd > > JDK9 Review Thread(s): > > http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html > > http://mail.openjdk.java.net/pipermail/net-dev/2016- > September/010201.html > > > > We had customer reports who ran into that issue with Java 8. So this should > be downported. > > > > The problem is, that the fix does not apply to Solaris as Solaris needs some > calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still > supported (though deprecated). But I think it is still worthwile to bring this > down for the other platforms which I?m proposing with my changeset. So I > extracted the new code manually from the JDK9 changeset and made it fit into > JDK8 coding. > > Ok, I see the complication. On Solaris these calls still go through > the VM to support Interruptible IO ( through the JVM_XXX interface). > Thankfully, this is no longer the case in 9. > > -Chris. From david.buck at oracle.com Wed Jan 11 13:50:37 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 11 Jan 2017 22:50:37 +0900 Subject: [8u-dev]: Request for Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set In-Reply-To: References: Message-ID: <5876382D.4060701@oracle.com> approved for push to 8u-dev once appropriate noreg label has been added to the bug report [ noreg bug labels ] http://openjdk.java.net/guide/changePlanning.html#noreg Cheers, -Buck On 2017/01/11 22:28, Langer, Christoph wrote: > Hi, > > please approve this downport. > > Thanks, Chris, for the Review. > > Best regards > Christoph > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Mittwoch, 11. Januar 2017 11:47 >> To: Langer, Christoph >> Cc: net-dev at openjdk.java.net >> Subject: Re: [8u-dev]: Request for Review and Approval: 8075484: >> SocketInputStream.socketRead0 can hang even with soTimeout set >> >> Hi Christoph, >> >>> On 9 Jan 2017, at 05:56, Langer, Christoph >> wrote: >>> >>> Ping: Please review this backport to JDK8. >>> >>> From: Langer, Christoph >>> Sent: Donnerstag, 29. Dezember 2016 10:37 >>> To: net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >>> Subject: [8u-dev]: Request for Review and Approval: 8075484: >> SocketInputStream.socketRead0 can hang even with soTimeout set >>> >>> Hi, >>> >>> please review (and eventually approve) the change for downporting 8075484. >>> >>> Webrev for 8u-dev: >> http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ >> >> The changes look ok to me. >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 >>> JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd >>> JDK9 Review Thread(s): >>> http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html >>> http://mail.openjdk.java.net/pipermail/net-dev/2016- >> September/010201.html >>> >>> We had customer reports who ran into that issue with Java 8. So this should >> be downported. >>> >>> The problem is, that the fix does not apply to Solaris as Solaris needs some >> calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still >> supported (though deprecated). But I think it is still worthwile to bring this >> down for the other platforms which I?m proposing with my changeset. So I >> extracted the new code manually from the JDK9 changeset and made it fit into >> JDK8 coding. >> >> Ok, I see the complication. On Solaris these calls still go through >> the VM to support Interruptible IO ( through the JVM_XXX interface). >> Thankfully, this is no longer the case in 9. >> >> -Chris. > From david.buck at oracle.com Wed Jan 11 13:56:58 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 11 Jan 2017 22:56:58 +0900 Subject: [8u-dev] Request for Approval: 8159058: SAXParseException when sending soap message In-Reply-To: References: Message-ID: <587639AA.7090906@oracle.com> approved for push to 8u-dev (contingent on successful code review) I have added the core libraries alias for what will hopefully be a trivial code review process. Cheers, -Buck On 2017/01/11 22:01, Aleks Efimov wrote: > Hello, > > Please, approve a backport of JDK-8159058 to JDK8u-dev. This is almost > straight-forward backport except one difference: > com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java is not > part of JDK8 JAXWS version and therefore this changes wasn't > backported/not needed. > Regression test and other source changes were applied cleanly after > reshuffling. > Testing shows no related failures: JDK regression tests (with backported > one), JCK runtime jaxws/b related test. > > With Best Regards, > Aleksej > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8159058 > > JDK8 webrev: > http://cr.openjdk.java.net/~aefimov/8159058/8/00/ > > JDK9 changesets: > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/a98174edd246 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/766677da17b5 > > JDK9 review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045785.html > > > > From christoph.langer at sap.com Wed Jan 11 14:34:39 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Jan 2017 14:34:39 +0000 Subject: [8u-dev]: Request for Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set In-Reply-To: <5876382D.4060701@oracle.com> References: <5876382D.4060701@oracle.com> Message-ID: <29a409b6164e423e91de06596b7734cc@DEWDFE13DE03.global.corp.sap> Thanks Buck. I added the label and pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c43400eba8a3 I also added #include to net_util_md.c which I forgot in my webrev. Best regards Christoph > -----Original Message----- > From: David Buck [mailto:david.buck at oracle.com] > Sent: Mittwoch, 11. Januar 2017 14:51 > To: Langer, Christoph ; jdk8u- > dev at openjdk.java.net > Cc: net-dev at openjdk.java.net > Subject: Re: [8u-dev]: Request for Approval: 8075484: > SocketInputStream.socketRead0 can hang even with soTimeout set > > approved for push to 8u-dev once appropriate noreg label has been added > to the bug report > > [ noreg bug labels ] > http://openjdk.java.net/guide/changePlanning.html#noreg > > Cheers, > -Buck > > On 2017/01/11 22:28, Langer, Christoph wrote: > > Hi, > > > > please approve this downport. > > > > Thanks, Chris, for the Review. > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Mittwoch, 11. Januar 2017 11:47 > >> To: Langer, Christoph > >> Cc: net-dev at openjdk.java.net > >> Subject: Re: [8u-dev]: Request for Review and Approval: 8075484: > >> SocketInputStream.socketRead0 can hang even with soTimeout set > >> > >> Hi Christoph, > >> > >>> On 9 Jan 2017, at 05:56, Langer, Christoph > >> wrote: > >>> > >>> Ping: Please review this backport to JDK8. > >>> > >>> From: Langer, Christoph > >>> Sent: Donnerstag, 29. Dezember 2016 10:37 > >>> To: net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > >>> Subject: [8u-dev]: Request for Review and Approval: 8075484: > >> SocketInputStream.socketRead0 can hang even with soTimeout set > >>> > >>> Hi, > >>> > >>> please review (and eventually approve) the change for downporting > 8075484. > >>> > >>> Webrev for 8u-dev: > >> http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ > >> > >> The changes look ok to me. > >> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 > >>> JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd > >>> JDK9 Review Thread(s): > >>> http://mail.openjdk.java.net/pipermail/net-dev/2016- > August/010171.html > >>> http://mail.openjdk.java.net/pipermail/net-dev/2016- > >> September/010201.html > >>> > >>> We had customer reports who ran into that issue with Java 8. So this should > >> be downported. > >>> > >>> The problem is, that the fix does not apply to Solaris as Solaris needs some > >> calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still > >> supported (though deprecated). But I think it is still worthwile to bring this > >> down for the other platforms which I?m proposing with my changeset. So I > >> extracted the new code manually from the JDK9 changeset and made it fit > into > >> JDK8 coding. > >> > >> Ok, I see the complication. On Solaris these calls still go through > >> the VM to support Interruptible IO ( through the JVM_XXX interface). > >> Thankfully, this is no longer the case in 9. > >> > >> -Chris. > > From sean.coffey at oracle.com Wed Jan 11 15:22:30 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 11 Jan 2017 15:22:30 +0000 Subject: [8u-dev] Request for Approval: 8159058: SAXParseException when sending soap message In-Reply-To: <587639AA.7090906@oracle.com> References: <587639AA.7090906@oracle.com> Message-ID: <58764DB6.9030509@oracle.com> Backported changes look fine. Regards, Sean. On 11/01/17 13:56, David Buck wrote: > approved for push to 8u-dev (contingent on successful code review) > > I have added the core libraries alias for what will hopefully be a > trivial code review process. > > Cheers, > -Buck > > > > On 2017/01/11 22:01, Aleks Efimov wrote: >> Hello, >> >> Please, approve a backport of JDK-8159058 to JDK8u-dev. This is almost >> straight-forward backport except one difference: >> com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java is not >> part of JDK8 JAXWS version and therefore this changes wasn't >> backported/not needed. >> Regression test and other source changes were applied cleanly after >> reshuffling. >> Testing shows no related failures: JDK regression tests (with backported >> one), JCK runtime jaxws/b related test. >> >> With Best Regards, >> Aleksej >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8159058 >> >> JDK8 webrev: >> http://cr.openjdk.java.net/~aefimov/8159058/8/00/ >> >> JDK9 changesets: >> http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/a98174edd246 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/766677da17b5 >> >> JDK9 review thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045785.html >> >> >> >> >> From rob.mckenna at oracle.com Wed Jan 11 15:58:53 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 11 Jan 2017 15:58:53 +0000 Subject: [8u-dev] Request for Approval: 8159058: SAXParseException when sending soap message In-Reply-To: References: Message-ID: <20170111155853.GA3721@tecra> Approved -Rob On 11/01/17 04:01, Aleks Efimov wrote: > Hello, > > Please, approve a backport of JDK-8159058 to JDK8u-dev. This is almost > straight-forward backport except one difference: > com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java is not > part of JDK8 JAXWS version and therefore this changes wasn't backported/not > needed. > Regression test and other source changes were applied cleanly after > reshuffling. > Testing shows no related failures: JDK regression tests (with backported > one), JCK runtime jaxws/b related test. > > With Best Regards, > Aleksej > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8159058 > > JDK8 webrev: > http://cr.openjdk.java.net/~aefimov/8159058/8/00/ > > JDK9 changesets: > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/a98174edd246 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/766677da17b5 > > JDK9 review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045785.html > > > From hannes.wallnoefer at oracle.com Wed Jan 11 16:39:47 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 11 Jan 2017 17:39:47 +0100 Subject: [8u-dev] Request for Approval: 8171219: Missing checks in sparse array shift() implementation Message-ID: <21A13103-D9CC-4908-A53D-A8495DFF6821@oracle.com> Please approve backport to 8u-dev: Bug: https://bugs.openjdk.java.net/browse/JDK-8171219 JDK9 Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev/ JDK8u Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev-8u/ Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006737.html The patch applied cleanly to 8u except for SparseArrayData.java, where explicit boxing/unboxing of long values has been removed in JDK9. I preserved the boxing/unboxing in the backport to keep it consistent. Thanks, Hannes From james.laskey at oracle.com Wed Jan 11 16:45:28 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 11 Jan 2017 12:45:28 -0400 Subject: [8u-dev] Request for Approval: 8171219: Missing checks in sparse array shift() implementation In-Reply-To: <21A13103-D9CC-4908-A53D-A8495DFF6821@oracle.com> References: <21A13103-D9CC-4908-A53D-A8495DFF6821@oracle.com> Message-ID: <4E71ECBF-D59E-4D6A-B308-98AD31E43B06@oracle.com> +1 > On Jan 11, 2017, at 12:39 PM, Hannes Walln?fer wrote: > > Please approve backport to 8u-dev: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171219 > JDK9 Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev/ > JDK8u Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev-8u/ > Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006737.html > > The patch applied cleanly to 8u except for SparseArrayData.java, where explicit boxing/unboxing of long values has been removed in JDK9. I preserved the boxing/unboxing in the backport to keep it consistent. > > Thanks, > Hannes From gnu.andrew at redhat.com Wed Jan 11 16:47:30 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 11 Jan 2017 11:47:30 -0500 (EST) Subject: [8u communication] Changes to JDK 8u122 plans In-Reply-To: References: Message-ID: <996798545.1484754.1484153250749.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Oracle no longer plans to create a separate JDK 8u122 PSU release. As > such, the proposed schedule for JDK 8u122 in this Project is no longer > accurate. > > Given the very small amount of changes that were destined specifically > for 8u122 (and not for 8u121 as well), the process to propose critical > fixes for inclusion in JDK 8u CPU releases [0] should be used instead, > where applicable. > > This holds for future changes to be integrated into jdk8u-dev forest, as > well as for already integrated changes that were destined for JDK 8u122. > > If you have questions or concerns, please share them on the jdk8u-dev > mailing list. > > cheers, > dalibor topic > > [0] http://openjdk.java.net/projects/jdk8u/criticalcpufixes.html > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > So what will be the base for 8u131? 8u121? Where will the few changes for 8u122 end up? 8u121 or 8u132? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rob.mckenna at oracle.com Wed Jan 11 16:47:54 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 11 Jan 2017 16:47:54 +0000 Subject: [8u-dev] Request for Approval: 8171219: Missing checks in sparse array shift() implementation In-Reply-To: <4E71ECBF-D59E-4D6A-B308-98AD31E43B06@oracle.com> References: <21A13103-D9CC-4908-A53D-A8495DFF6821@oracle.com> <4E71ECBF-D59E-4D6A-B308-98AD31E43B06@oracle.com> Message-ID: <20170111164754.GB3721@tecra> Approved -Rob On 11/01/17 12:45, Jim Laskey (Oracle) wrote: > +1 > > > On Jan 11, 2017, at 12:39 PM, Hannes Walln?fer wrote: > > > > Please approve backport to 8u-dev: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171219 > > JDK9 Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev/ > > JDK8u Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev-8u/ > > Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006737.html > > > > The patch applied cleanly to 8u except for SparseArrayData.java, where explicit boxing/unboxing of long values has been removed in JDK9. I preserved the boxing/unboxing in the backport to keep it consistent. > > > > Thanks, > > Hannes > From lance.andersen at oracle.com Wed Jan 11 17:03:46 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 11 Jan 2017 12:03:46 -0500 Subject: [8u-dev] Request for Approval: 8159058: SAXParseException when sending soap message In-Reply-To: <587639AA.7090906@oracle.com> References: <587639AA.7090906@oracle.com> Message-ID: <36D47A48-6507-4F2F-8AF0-090979B5F1BF@oracle.com> The change looks good. Best Lance > On Jan 11, 2017, at 8:56 AM, David Buck wrote: > > approved for push to 8u-dev (contingent on successful code review) > > I have added the core libraries alias for what will hopefully be a trivial code review process. > > Cheers, > -Buck > > > > On 2017/01/11 22:01, Aleks Efimov wrote: >> Hello, >> >> Please, approve a backport of JDK-8159058 to JDK8u-dev. This is almost >> straight-forward backport except one difference: >> com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java is not >> part of JDK8 JAXWS version and therefore this changes wasn't >> backported/not needed. >> Regression test and other source changes were applied cleanly after >> reshuffling. >> Testing shows no related failures: JDK regression tests (with backported >> one), JCK runtime jaxws/b related test. >> >> With Best Regards, >> Aleksej >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8159058 >> >> JDK8 webrev: >> http://cr.openjdk.java.net/~aefimov/8159058/8/00/ >> >> JDK9 changesets: >> http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/a98174edd246 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/766677da17b5 >> >> JDK9 review thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045785.html >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From hannes.wallnoefer at oracle.com Wed Jan 11 17:13:08 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 11 Jan 2017 18:13:08 +0100 Subject: [8u-dev] Request for Approval: 8170977: SparseArrayData should not grow its underlying dense array data Message-ID: Please approve backport to 8u-dev: Bug: https://bugs.openjdk.java.net/browse/JDK-8170977 Webrev: http://cr.openjdk.java.net/~hannesw/8170977/webrev/nashorn.patch Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006752.html The patch applies cleanly to 8u-dev after path reshuffling. Thanks, Hannes From james.laskey at oracle.com Wed Jan 11 17:15:52 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 11 Jan 2017 13:15:52 -0400 Subject: [8u-dev] Request for Approval: 8170977: SparseArrayData should not grow its underlying dense array data In-Reply-To: References: Message-ID: +1 > On Jan 11, 2017, at 1:13 PM, Hannes Walln?fer wrote: > > Please approve backport to 8u-dev: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170977 > Webrev: http://cr.openjdk.java.net/~hannesw/8170977/webrev/nashorn.patch > Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006752.html > > The patch applies cleanly to 8u-dev after path reshuffling. > > Thanks, > Hannes From rob.mckenna at oracle.com Wed Jan 11 19:11:29 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 11 Jan 2017 19:11:29 +0000 Subject: [8u-dev] Request for Approval: 8170977: SparseArrayData should not grow its underlying dense array data In-Reply-To: References: Message-ID: <20170111191129.GC3721@tecra> Approved -Rob On 11/01/17 01:15, Jim Laskey (Oracle) wrote: > +1 > > > On Jan 11, 2017, at 1:13 PM, Hannes Walln?fer wrote: > > > > Please approve backport to 8u-dev: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170977 > > Webrev: http://cr.openjdk.java.net/~hannesw/8170977/webrev/nashorn.patch > > Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-December/006752.html > > > > The patch applies cleanly to 8u-dev after path reshuffling. > > > > Thanks, > > Hannes > From dmitry.markov at oracle.com Thu Jan 12 20:01:07 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Thu, 12 Jan 2017 23:01:07 +0300 Subject: [8u-dev] Request for approval 8171909: [PIT] on Windows, failure of java/awt/Dialog/DialogAboveFrame/DialogAboveFrameTest.java Message-ID: <5877E083.4000404@oracle.com> Hello, Can I get an approval to port the fix for 8171909 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8171909 Webrev: http://cr.openjdk.java.net/~dmarkov/8171909/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-January/012521.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/f611d6336fb0 Thanks, Dmitry From david.buck at oracle.com Fri Jan 13 01:37:34 2017 From: david.buck at oracle.com (David Buck) Date: Fri, 13 Jan 2017 10:37:34 +0900 Subject: [8u-dev] Request for approval 8171909: [PIT] on Windows, failure of java/awt/Dialog/DialogAboveFrame/DialogAboveFrameTest.java In-Reply-To: <5877E083.4000404@oracle.com> References: <5877E083.4000404@oracle.com> Message-ID: <58782F5E.1060503@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/01/13 5:01, dmitry markov wrote: > Hello, > > Can I get an approval to port the fix for 8171909 to jdk8u-dev, please? > The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8171909 > Webrev: http://cr.openjdk.java.net/~dmarkov/8171909/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/awt-dev/2017-January/012521.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/f611d6336fb0 > > Thanks, > Dmitry > From serguei.spitsyn at oracle.com Fri Jan 13 20:36:23 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Jan 2017 12:36:23 -0800 Subject: [8u-dev] Request for approval 8034249: need more workarounds for suspend equivalent condition issue Message-ID: Hello, Can I get an approval to backport the fix for to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8034249 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1/ Review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012565.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/402677ca28ed Thanks, Serguei [1]https://plumbr.eu/how-plumbr-works From rob.mckenna at oracle.com Sat Jan 14 00:42:04 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Sat, 14 Jan 2017 00:42:04 +0000 Subject: [8u-dev] Request for approval 8034249: need more workarounds for suspend equivalent condition issue In-Reply-To: References: Message-ID: <20170114004204.GA2474@tecra> Approved. Please add an appropriate noreg label. -Rob On 13/01/17 12:36, serguei.spitsyn at oracle.com wrote: > Hello, > > Can I get an approval to backport the fix for to jdk8u-dev, please? > The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8034249 > Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1/ > Review thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012565.html > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/402677ca28ed > > > Thanks, > Serguei > > [1]https://plumbr.eu/how-plumbr-works > > From serguei.spitsyn at oracle.com Sat Jan 14 00:43:12 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 13 Jan 2017 16:43:12 -0800 Subject: [8u-dev] Request for approval 8034249: need more workarounds for suspend equivalent condition issue In-Reply-To: <20170114004204.GA2474@tecra> References: <20170114004204.GA2474@tecra> Message-ID: <025e78c3-6a64-260e-2f86-d7683500e2bf@oracle.com> Thanks, Rob! Serguei On 1/13/17 16:42, Rob McKenna wrote: > Approved. Please add an appropriate noreg label. > > -Rob > > On 13/01/17 12:36, serguei.spitsyn at oracle.com wrote: >> Hello, >> >> Can I get an approval to backport the fix for to jdk8u-dev, please? >> The jdk9 patch applies cleanly. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8034249 >> Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1/ >> Review thread: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012565.html >> jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/402677ca28ed >> >> >> Thanks, >> Serguei >> >> [1]https://plumbr.eu/how-plumbr-works >> >> From abhi.saha at oracle.com Tue Jan 17 21:34:27 2017 From: abhi.saha at oracle.com (Abhijit Saha) Date: Tue, 17 Jan 2017 13:34:27 -0800 Subject: [8u] Request for approval for bulk changes from Jan 2017 CPU 8u121 fixes into 8u Message-ID: <354a52c5-dd5f-3d5a-44a4-fd9a345af3d1@oracle.com> 8u121 has been released earlier today [1]. Requesting approval to sync up the 8u121 changes into the jdk8u forest. webrev : http://cr.openjdk.java.net/~asaha/openJDK.8u121-8u152.sync/webrev Thanks Abhijit [1] http://www.oracle.com/technetwork/java/javase/downloads/index.html -- Java Platform Group Oracle Corporation. (408)276-7564 From dalibor.topic at oracle.com Tue Jan 17 23:15:18 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 18 Jan 2017 00:15:18 +0100 Subject: [8u] Request for approval for bulk changes from Jan 2017 CPU 8u121 fixes into 8u In-Reply-To: <354a52c5-dd5f-3d5a-44a4-fd9a345af3d1@oracle.com> References: <354a52c5-dd5f-3d5a-44a4-fd9a345af3d1@oracle.com> Message-ID: Thanks, Abhijit - Approved. cheers, dalibor topic On 17.01.2017 22:34, Abhijit Saha wrote: > 8u121 has been released earlier today [1]. Requesting approval to sync > up the 8u121 changes into the jdk8u forest. > > webrev : http://cr.openjdk.java.net/~asaha/openJDK.8u121-8u152.sync/webrev > > > Thanks > Abhijit > > > [1] http://www.oracle.com/technetwork/java/javase/downloads/index.html > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From nikita.j.jain at oracle.com Wed Jan 18 13:47:13 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Wed, 18 Jan 2017 05:47:13 -0800 (PST) Subject: RFR: JDK-8171151 - JDK8u ProblemList.txt Updation Message-ID: <2f0a6aec-71b8-42cd-88d6-94f12c31acd4@default> Hi All, Please review this fix for JDK-8171151 - JDK8u ProblemList.txt Updation Bug: https://bugs.openjdk.java.net/browse/JDK-8171151 JDK8u Webrev: http://cr.openjdk.java.net/~rpatil/8171151/webrev.00/ Testing: Passes JPRT. -------------- Summary Test cases inserted -> New test failures for JDK8u-dev have been added in the list with their associated bug id. -> 8171208, The bug has been closed because of the Infra issue. However, its reference is used here just to track the INFRA bug id. java/net/CookieHandler/CookieManagerTest.java java/net/HttpURLConnection/UnmodifiableMaps.java sun/net/www/protocol/http/B6299712.java Test cases updated/deleted -> Removing the test as per the bug id 8027973 [bug is fixed] javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java ? -> Removing the test as per the bug id 7052625 [change is backported] com/sun/net/httpserver/bugs/6725892/Test.java -> Removing the test as per the bug id 7148829 [No more failure seen, reopen if seen again] sun/net/InetAddress/nameservice/simple/CacheTest.java sun/net/InetAddress/nameservice/simple/DefaultCaching.java -> The test was seen as failure in solaris_x64 and solaris_sparcv9 also. Platform, Bug id has also been added for the same. java/net/MulticastSocket/SetLoopbackMode.java ? -> The test was seen as failure in solaris_x64. Platform, Bug id has also been added for the same. java/net/MulticastSocket/Test.java -> Updating bug id from (JDK-7157786 to JDK-8026976), as '7157786' is closed as duplicate sun/security/pkcs11/ec/TestKeyFactory.java -> Removing the test as per the bug id 6988842 [bug is fixed but entry is not removed from the ProblemList.txt] sun/security/pkcs11/Secmod/AddPrivateKey.java sun/security/pkcs11/ec/ReadCertificates.java sun/security/pkcs11/ec/ReadPKCS12.java -> According to this bug id: 6988842, test is not falling on solaris-all. The test was seen as failure on linux_i586 and linux_x64. Hence, the bug id and affected platform has been updated. sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java -> Removing these tests as per the comment in Bug 7143279. [No failure reported since 2013/06. Reopen if seen again] tools/pack200/CommandLineTests.java ?? ????????????? ???????????????????????????? tools/pack200/Pack200Test.java -> The test was seen as failure in windows _all. Platform, Bug id has also been added for the same. tools/launcher/FXLauncherTest.java Thanks, Nikita Jain From martinrb at google.com Thu Jan 19 03:33:32 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 18 Jan 2017 19:33:32 -0800 Subject: [8u Communication] JDK 8u122 timeline In-Reply-To: <20160811141114.GA4805@vimes> References: <20160811141114.GA4805@vimes> Message-ID: 8u121 was released, but not 8u122. But http://openjdk.java.net/projects/jdk8u/releases/8u122.html still exists, and it says, Best efforts are made to keep this page updated with most recent information. And there is no corresponding web page for http://openjdk.java.net/projects/jdk8u/releases/8u121.html On Thu, Aug 11, 2016 at 7:11 AM, Rob McKenna wrote: > Hi folks, > > I've published a proposal for the key milestone dates relating to the > 8u122 release: > > http://openjdk.java.net/projects/jdk8u/releases/8u122.html > > July 2016 8u-dev forest begins collecting 8u122 fixes (completed) > October 2016 RampDown 2 > Jan 2017 GA > > Note that these timelines are preliminary only and are subject to change. > Please refer to the JDK 8 milestones definition page [1] for a summary of > what each milestone consists of. Please submit feedback by Wednesday the > 17th of August 2016. > > Thanks, > > -Rob > From prasanta.sadhukhan at oracle.com Thu Jan 19 05:28:37 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 19 Jan 2017 10:58:37 +0530 Subject: [8u-dev] Request for approval to backport JDK-8040635 : [macosx] Printing a shape filled with a texture doesn't work under Mac OS X Message-ID: Hi All, Can I please get an approval to port the fix for JDK-8040635 to jdk8u-dev? jdk9 patch applies cleanly and works fine in 8udev. JBS: https://bugs.openjdk.java.net/browse/JDK-8040635 webrev: http://cr.openjdk.java.net/~psadhukhan/8040635/8udev/webrev/ Review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2016-November/007886.html JDK9 changset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/33cc5c2a270d Regards Prasanta From prasanta.sadhukhan at oracle.com Thu Jan 19 05:28:52 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 19 Jan 2017 10:58:52 +0530 Subject: [8u-dev] Request for approval to backport JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. Message-ID: Hi All, Can I please get an approval to port the fix for JDK-8162796 to jdk8u-dev? jdk9 patch applies cleanly and works fine in 8udev. JBS: https://bugs.openjdk.java.net/browse/JDK-8162796 webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/8udev/webrev/ Review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007870.html jdk9 changset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b82c04707671 Regards Prasanta From dalibor.topic at oracle.com Thu Jan 19 14:47:43 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 19 Jan 2017 15:47:43 +0100 Subject: [8u communication] Changes to JDK 8u122 plans In-Reply-To: <996798545.1484754.1484153250749.JavaMail.zimbra@redhat.com> References: <996798545.1484754.1484153250749.JavaMail.zimbra@redhat.com> Message-ID: <9118dbef-4d06-5e4f-7f6a-0a3dfe50cd21@oracle.com> On 11.01.2017 17:47, Andrew Hughes wrote: > ----- Original Message ----- >> Oracle no longer plans to create a separate JDK 8u122 PSU release. As >> such, the proposed schedule for JDK 8u122 in this Project is no longer >> accurate. >> >> Given the very small amount of changes that were destined specifically >> for 8u122 (and not for 8u121 as well), the process to propose critical >> fixes for inclusion in JDK 8u CPU releases [0] should be used instead, >> where applicable. >> >> This holds for future changes to be integrated into jdk8u-dev forest, as >> well as for already integrated changes that were destined for JDK 8u122. >> > So what will be the base for 8u131? 8u121? 8u121. > Where will the few changes for 8u122 end up? 8u121 or 8u132? Oracle JDK 8u121 has been released on Tuesday, January 17th, and the corresponding applicable changes have already made their way into the jdk8u master forest. If a change is applicable for inclusion in a future CPU release as a critical fix, then after its proposed for inclusion per the process mentioned above, and in case it has been approved, it would appear in a future CPU release - not sooner than in the next scheduled one. The CPU schedule can be found here: http://www.oracle.com/technetwork/topics/security/alerts-086861.html cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Jan 19 15:01:40 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 19 Jan 2017 16:01:40 +0100 Subject: [8u Communication] JDK 8u122 timeline In-Reply-To: References: <20160811141114.GA4805@vimes> Message-ID: <22b39b8c-84df-6736-a145-2584cb73b7a5@oracle.com> On 19.01.2017 04:33, Martin Buchholz wrote: > 8u121 was released, but not 8u122. That's correct. Please see http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-December/006245.html for the background. > But http://openjdk.java.net/projects/jdk8u/releases/8u122.html still > exists, and it says, > Best efforts are made to keep this page updated with most recent > information. Indeed, it should be updated with a link to the e-mail above. > And there is no corresponding web page for > http://openjdk.java.net/projects/jdk8u/releases/8u121.html 8u121 was a CPU release. The OpenJDK JDK 8 Updates Project doesn't develop the CPU releases itself. Applicable changes from a CPU release are bulk integrated to the public master forest as part of the general synchronized publication of the fixes to affected JDK release trains. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From rob.mckenna at oracle.com Thu Jan 19 15:46:48 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 19 Jan 2017 15:46:48 +0000 Subject: [8u-dev] Request for approval to backport JDK-8162796: [macosx] LinearGradientPaint and RadialGradientPaint are not printed on OS X. In-Reply-To: References: Message-ID: <20170119154648.GB3827@tecra> Approved -Rob On 19/01/17 10:58, Prasanta Sadhukhan wrote: > Hi All, > > Can I please get an approval to port the fix for JDK-8162796 to jdk8u-dev? > jdk9 patch applies cleanly and works fine in 8udev. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8162796 > webrev: http://cr.openjdk.java.net/~psadhukhan/8162796/8udev/webrev/ > Review thread: > http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007870.html > jdk9 changset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b82c04707671 > > Regards > Prasanta From rob.mckenna at oracle.com Thu Jan 19 15:47:01 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 19 Jan 2017 15:47:01 +0000 Subject: [8u-dev] Request for approval to backport JDK-8040635 : [macosx] Printing a shape filled with a texture doesn't work under Mac OS X In-Reply-To: References: Message-ID: <20170119154701.GC3827@tecra> Approved -Rob On 19/01/17 10:58, Prasanta Sadhukhan wrote: > Hi All, > > Can I please get an approval to port the fix for JDK-8040635 to jdk8u-dev? > jdk9 patch applies cleanly and works fine in 8udev. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8040635 > webrev: http://cr.openjdk.java.net/~psadhukhan/8040635/8udev/webrev/ > Review thread: > http://mail.openjdk.java.net/pipermail/2d-dev/2016-November/007886.html > JDK9 changset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/33cc5c2a270d > > Regards > Prasanta > > From ivan.gerasimov at oracle.com Sat Jan 21 22:12:42 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 22 Jan 2017 01:12:42 +0300 Subject: RFR: JDK-8171151 - JDK8u ProblemList.txt Updation In-Reply-To: <2f0a6aec-71b8-42cd-88d6-94f12c31acd4@default> References: <2f0a6aec-71b8-42cd-88d6-94f12c31acd4@default> Message-ID: <3441b67c-6a36-41d7-628c-f076ea4fa92e@oracle.com> Hi Nikita! Thanks for working on this! Reducing the noise from failing tests should greatly help to focus on the important failures. Your patch looks good in general. A couple of comments: 1) 223 # 8158274 224 java/nio/file/Files/probeContentType/Basic.java solaris-x64 The bug JDK-8158274 was about Solaris Sparc and is now closed with "Won't fix" resolution. If the test is going to be fixed, then a new bug should be filed. 2) 283 # 8043951 284 sun/security/pkcs11/MessageDigest/TestCloning.java solaris-x64 The bug JDK-8043951 was closed as "Won't fix". If we're going to fix the test, either the bug should be reopened, or a new bug should be filed. Please not that I'm not a Reviewer, so you'll need to get an approval from one. With kind regards, Ivan On 18.01.2017 16:47, Nikita Jain wrote: > Hi All, > > Please review this fix for JDK-8171151 - JDK8u ProblemList.txt Updation > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171151 > JDK8u Webrev: http://cr.openjdk.java.net/~rpatil/8171151/webrev.00/ > > Testing: Passes JPRT. > > -------------- > Summary > Test cases inserted > -> New test failures for JDK8u-dev have been added in the list with their associated bug id. > > -> 8171208, The bug has been closed because of the Infra issue. However, its reference is used here just to track the INFRA bug id. > java/net/CookieHandler/CookieManagerTest.java > java/net/HttpURLConnection/UnmodifiableMaps.java > sun/net/www/protocol/http/B6299712.java > > > Test cases updated/deleted > -> Removing the test as per the bug id 8027973 [bug is fixed] > javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java > > -> Removing the test as per the bug id 7052625 [change is backported] > com/sun/net/httpserver/bugs/6725892/Test.java > > -> Removing the test as per the bug id 7148829 [No more failure seen, reopen if seen again] > sun/net/InetAddress/nameservice/simple/CacheTest.java > sun/net/InetAddress/nameservice/simple/DefaultCaching.java > > -> The test was seen as failure in solaris_x64 and solaris_sparcv9 also. Platform, Bug id has also been added for the same. > java/net/MulticastSocket/SetLoopbackMode.java > > -> The test was seen as failure in solaris_x64. Platform, Bug id has also been added for the same. > java/net/MulticastSocket/Test.java > > -> Updating bug id from (JDK-7157786 to JDK-8026976), as '7157786' is closed as duplicate > sun/security/pkcs11/ec/TestKeyFactory.java > > -> Removing the test as per the bug id 6988842 [bug is fixed but entry is not removed from the ProblemList.txt] > sun/security/pkcs11/Secmod/AddPrivateKey.java > sun/security/pkcs11/ec/ReadCertificates.java > sun/security/pkcs11/ec/ReadPKCS12.java > > -> According to this bug id: 6988842, test is not falling on solaris-all. The test was seen as failure on linux_i586 and linux_x64. Hence, the bug id and affected platform has been updated. > sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java > > -> Removing these tests as per the comment in Bug 7143279. [No failure reported since 2013/06. Reopen if seen again] > tools/pack200/CommandLineTests.java > tools/pack200/Pack200Test.java > > -> The test was seen as failure in windows _all. Platform, Bug id has also been added for the same. > tools/launcher/FXLauncherTest.java > > > > > Thanks, > Nikita Jain > From nikita.j.jain at oracle.com Mon Jan 23 08:19:04 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Mon, 23 Jan 2017 00:19:04 -0800 (PST) Subject: RFR: JDK-8171151 - JDK8u ProblemList.txt Updation In-Reply-To: <3441b67c-6a36-41d7-628c-f076ea4fa92e@oracle.com> References: <2f0a6aec-71b8-42cd-88d6-94f12c31acd4@default> <3441b67c-6a36-41d7-628c-f076ea4fa92e@oracle.com> Message-ID: <4843f035-46dc-4fbc-8e54-15e3e817afed@default> Hi All, Updated the webrev. May I have a reviewer to review this: http://cr.openjdk.java.net/~rpatil/8171151/webrev.01/ Thank you Ivan for looking into this, created new bugs for the same. Thanks, Nikita Jain From: Ivan Gerasimov Sent: Sunday, January 22, 2017 3:43 AM To: Nikita Jain ; jdk8u-dev at openjdk.java.net Subject: Re: RFR: JDK-8171151 - JDK8u ProblemList.txt Updation Hi Nikita! Thanks for working on this! Reducing the noise from failing tests should greatly help to focus on the important failures. Your patch looks good in general. A couple of comments: 1) 223 # 8158274 224 java/nio/file/Files/probeContentType/Basic.java solaris-x64 The bug JDK-8158274 was about Solaris Sparc and is now closed with "Won't fix" resolution. If the test is going to be fixed, then a new bug should be filed. 2) 283 # 8043951 284 sun/security/pkcs11/MessageDigest/TestCloning.java solaris-x64 The bug JDK-8043951 was closed as "Won't fix". If we're going to fix the test, either the bug should be reopened, or a new bug should be filed. Please not that I'm not a Reviewer, so you'll need to get an approval from one. With kind regards, Ivan On 18.01.2017 16:47, Nikita Jain wrote: Hi All, Please review this fix for JDK-8171151 - JDK8u ProblemList.txt Updation Bug: https://bugs.openjdk.java.net/browse/JDK-8171151 JDK8u Webrev: http://cr.openjdk.java.net/~rpatil/8171151/webrev.00/ Testing: Passes JPRT. -------------- Summary Test cases inserted -> New test failures for JDK8u-dev have been added in the list with their associated bug id. -> 8171208, The bug has been closed because of the Infra issue. However, its reference is used here just to track the INFRA bug id. java/net/CookieHandler/CookieManagerTest.java java/net/HttpURLConnection/UnmodifiableMaps.java sun/net/www/protocol/http/B6299712.java Test cases updated/deleted -> Removing the test as per the bug id 8027973 [bug is fixed] javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java -> Removing the test as per the bug id 7052625 [change is backported] com/sun/net/httpserver/bugs/6725892/Test.java -> Removing the test as per the bug id 7148829 [No more failure seen, reopen if seen again] sun/net/InetAddress/nameservice/simple/CacheTest.java sun/net/InetAddress/nameservice/simple/DefaultCaching.java -> The test was seen as failure in solaris_x64 and solaris_sparcv9 also. Platform, Bug id has also been added for the same. java/net/MulticastSocket/SetLoopbackMode.java -> The test was seen as failure in solaris_x64. Platform, Bug id has also been added for the same. java/net/MulticastSocket/Test.java -> Updating bug id from (JDK-7157786 to JDK-8026976), as '7157786' is closed as duplicate sun/security/pkcs11/ec/TestKeyFactory.java -> Removing the test as per the bug id 6988842 [bug is fixed but entry is not removed from the ProblemList.txt] sun/security/pkcs11/Secmod/AddPrivateKey.java sun/security/pkcs11/ec/ReadCertificates.java sun/security/pkcs11/ec/ReadPKCS12.java -> According to this bug id: 6988842, test is not falling on solaris-all. The test was seen as failure on linux_i586 and linux_x64. Hence, the bug id and affected platform has been updated. sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java -> Removing these tests as per the comment in Bug 7143279. [No failure reported since 2013/06. Reopen if seen again] tools/pack200/CommandLineTests.java tools/pack200/Pack200Test.java -> The test was seen as failure in windows _all. Platform, Bug id has also been added for the same. tools/launcher/FXLauncherTest.java Thanks, Nikita Jain From ivan.gerasimov at oracle.com Mon Jan 23 10:44:04 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 23 Jan 2017 13:44:04 +0300 Subject: RFR: JDK-8171151 - JDK8u ProblemList.txt Updation In-Reply-To: <4843f035-46dc-4fbc-8e54-15e3e817afed@default> References: <2f0a6aec-71b8-42cd-88d6-94f12c31acd4@default> <3441b67c-6a36-41d7-628c-f076ea4fa92e@oracle.com> <4843f035-46dc-4fbc-8e54-15e3e817afed@default> Message-ID: Thanks Nikita! The fix now looks good to me. Please get another review from a jdk8u-dev Reviewer before pushing it. With kind regards, Ivan On 23.01.2017 11:19, Nikita Jain wrote: > > Hi All, > > Updated the webrev. May I have a reviewer to review this: > > http://cr.openjdk.java.net/~rpatil/8171151/webrev.01/ > > > Thank you Ivan for looking into this, created new bugs for the same. > > > Thanks, > > Nikita Jain > > *From:*Ivan Gerasimov > *Sent:* Sunday, January 22, 2017 3:43 AM > *To:* Nikita Jain ; jdk8u-dev at openjdk.java.net > *Subject:* Re: RFR: JDK-8171151 - JDK8u ProblemList.txt Updation > > Hi Nikita! > > Thanks for working on this! > Reducing the noise from failing tests should greatly help to focus on > the important failures. > > Your patch looks good in general. > > A couple of comments: > 1) > 223 # 8158274 > 224 java/nio/file/Files/probeContentType/Basic.java solaris-x64 > > The bug JDK-8158274 was about Solaris Sparc and is now closed with > "Won't fix" resolution. > If the test is going to be fixed, then a new bug should be filed. > > 2) > 283 # 8043951 > 284 sun/security/pkcs11/MessageDigest/TestCloning.java solaris-x64 > > The bug JDK-8043951 was closed as "Won't fix". > If we're going to fix the test, either the bug should be reopened, or > a new bug should be filed. > > > Please not that I'm not a Reviewer, so you'll need to get an approval > from one. > > With kind regards, > Ivan > > On 18.01.2017 16:47, Nikita Jain wrote: > > Hi All, > > Please review this fix for JDK-8171151 - JDK8u ProblemList.txt Updation > > Bug:https://bugs.openjdk.java.net/browse/JDK-8171151 > > JDK8u Webrev:http://cr.openjdk.java.net/~rpatil/8171151/webrev.00/ > > > Testing: Passes JPRT. > > > > -------------- > > Summary > > Test cases inserted > > -> New test failures for JDK8u-dev have been added in the list with their associated bug id. > > -> 8171208, The bug has been closed because of the Infra issue. However, its reference is used here just to track the INFRA bug id. > > java/net/CookieHandler/CookieManagerTest.java > > java/net/HttpURLConnection/UnmodifiableMaps.java > > sun/net/www/protocol/http/B6299712.java > > Test cases updated/deleted > > -> Removing the test as per the bug id 8027973 [bug is fixed] > > javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java > > > > -> Removing the test as per the bug id 7052625 [change is backported] > > com/sun/net/httpserver/bugs/6725892/Test.java > > -> Removing the test as per the bug id 7148829 [No more failure seen, reopen if seen again] > > sun/net/InetAddress/nameservice/simple/CacheTest.java > > sun/net/InetAddress/nameservice/simple/DefaultCaching.java > > -> The test was seen as failure in solaris_x64 and solaris_sparcv9 also. Platform, Bug id has also been added for the same. > > java/net/MulticastSocket/SetLoopbackMode.java > > > > -> The test was seen as failure in solaris_x64. Platform, Bug id has also been added for the same. > > java/net/MulticastSocket/Test.java > > -> Updating bug id from (JDK-7157786 to JDK-8026976), as '7157786' is closed as duplicate > > sun/security/pkcs11/ec/TestKeyFactory.java > > -> Removing the test as per the bug id 6988842 [bug is fixed but entry is not removed from the ProblemList.txt] > > sun/security/pkcs11/Secmod/AddPrivateKey.java > > sun/security/pkcs11/ec/ReadCertificates.java > > sun/security/pkcs11/ec/ReadPKCS12.java > > -> According to this bug id: 6988842, test is not falling on solaris-all. The test was seen as failure on linux_i586 and linux_x64. Hence, the bug id and affected platform has been updated. > > sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java > > -> Removing these tests as per the comment in Bug 7143279. [No failure reported since 2013/06. Reopen if seen again] > > tools/pack200/CommandLineTests.java > > tools/pack200/Pack200Test.java > > -> The test was seen as failure in windows _all. Platform, Bug id has also been added for the same. > > tools/launcher/FXLauncherTest.java > > Thanks, > > Nikita Jain > From sean.coffey at oracle.com Mon Jan 23 17:16:45 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 23 Jan 2017 17:16:45 +0000 Subject: RFR: JDK-8171151 - JDK8u ProblemList.txt Updation In-Reply-To: References: <2f0a6aec-71b8-42cd-88d6-94f12c31acd4@default> <3441b67c-6a36-41d7-628c-f076ea4fa92e@oracle.com> <4843f035-46dc-4fbc-8e54-15e3e817afed@default> Message-ID: <58863A7D.9050008@oracle.com> Nikita, a few comments. The Pack200Test.java test was probably stabilized via the JDK-8166248 test fix. It stipulates that the test run on a with max memory > 4g - That might be useful for JDK 8u also. > + # 8129560 > + sun/security/pkcs11/rsa/TestKeyPairGenerator.java solaris-sparcv9 This seems applicable to solaris x64 also, Should the arch be solaris-all ? Would it be better to port the 1 line fix rather than add this to the exclude list ? > + # 8168374, 8130041 > + sun/security/tools/jarsigner/TsacertOptionTest.java linux-x64, > macosx-x64 8168374 is a JDK 9 (only) modules issue. Please remove the id reference. 813004 [1] is a simple enough backport. I'd recommend porting that to 8u-dev. For new tests & bug IDs being added to the problem list, do you plan to open a backport reference for test fixes that should be ported ? [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/78fcb2e094db Regards, Sean. On 23/01/17 10:44, Ivan Gerasimov wrote: > Thanks Nikita! > > The fix now looks good to me. > Please get another review from a jdk8u-dev Reviewer before pushing it. > > With kind regards, > Ivan > > On 23.01.2017 11:19, Nikita Jain wrote: >> >> Hi All, >> >> Updated the webrev. May I have a reviewer to review this: >> >> http://cr.openjdk.java.net/~rpatil/8171151/webrev.01/ >> >> >> Thank you Ivan for looking into this, created new bugs for the same. >> >> >> Thanks, >> >> Nikita Jain >> >> *From:*Ivan Gerasimov >> *Sent:* Sunday, January 22, 2017 3:43 AM >> *To:* Nikita Jain ; jdk8u-dev at openjdk.java.net >> *Subject:* Re: RFR: JDK-8171151 - JDK8u ProblemList.txt Updation >> >> Hi Nikita! >> >> Thanks for working on this! >> Reducing the noise from failing tests should greatly help to focus on >> the important failures. >> >> Your patch looks good in general. >> >> A couple of comments: >> 1) >> 223 # 8158274 >> 224 java/nio/file/Files/probeContentType/Basic.java solaris-x64 >> >> The bug JDK-8158274 was about Solaris Sparc and is now closed with >> "Won't fix" resolution. >> If the test is going to be fixed, then a new bug should be filed. >> >> 2) >> 283 # 8043951 >> 284 sun/security/pkcs11/MessageDigest/TestCloning.java solaris-x64 >> >> The bug JDK-8043951 was closed as "Won't fix". >> If we're going to fix the test, either the bug should be reopened, or >> a new bug should be filed. >> >> >> Please not that I'm not a Reviewer, so you'll need to get an approval >> from one. >> >> With kind regards, >> Ivan >> >> On 18.01.2017 16:47, Nikita Jain wrote: >> >> Hi All, >> >> Please review this fix for JDK-8171151 - JDK8u ProblemList.txt >> Updation >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8171151 >> >> JDK8u Webrev:http://cr.openjdk.java.net/~rpatil/8171151/webrev.00/ >> >> >> Testing: Passes JPRT. >> >> >> -------------- >> >> Summary >> >> Test cases inserted >> >> -> New test failures for JDK8u-dev have been added in the list >> with their associated bug id. >> >> -> 8171208, The bug has been closed because of the Infra issue. >> However, its reference is used here just to track the INFRA bug id. >> >> java/net/CookieHandler/CookieManagerTest.java >> >> java/net/HttpURLConnection/UnmodifiableMaps.java >> >> sun/net/www/protocol/http/B6299712.java >> >> Test cases updated/deleted >> >> -> Removing the test as per the bug id 8027973 [bug is fixed] >> >> javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java >> >> >> -> Removing the test as per the bug id 7052625 [change is >> backported] >> >> com/sun/net/httpserver/bugs/6725892/Test.java >> >> -> Removing the test as per the bug id 7148829 [No more failure >> seen, reopen if seen again] >> >> sun/net/InetAddress/nameservice/simple/CacheTest.java >> >> sun/net/InetAddress/nameservice/simple/DefaultCaching.java >> >> -> The test was seen as failure in solaris_x64 and >> solaris_sparcv9 also. Platform, Bug id has also been added for the same. >> >> java/net/MulticastSocket/SetLoopbackMode.java >> >> >> -> The test was seen as failure in solaris_x64. Platform, Bug id >> has also been added for the same. >> >> java/net/MulticastSocket/Test.java >> >> -> Updating bug id from (JDK-7157786 to JDK-8026976), as >> '7157786' is closed as duplicate >> >> sun/security/pkcs11/ec/TestKeyFactory.java >> >> -> Removing the test as per the bug id 6988842 [bug is fixed but >> entry is not removed from the ProblemList.txt] >> >> sun/security/pkcs11/Secmod/AddPrivateKey.java >> >> sun/security/pkcs11/ec/ReadCertificates.java >> >> sun/security/pkcs11/ec/ReadPKCS12.java >> >> -> According to this bug id: 6988842, test is not falling on >> solaris-all. The test was seen as failure on linux_i586 and >> linux_x64. Hence, the bug id and affected platform has been updated. >> >> sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java >> >> -> Removing these tests as per the comment in Bug 7143279. [No >> failure reported since 2013/06. Reopen if seen again] >> >> tools/pack200/CommandLineTests.java >> >> tools/pack200/Pack200Test.java >> >> -> The test was seen as failure in windows _all. Platform, Bug id >> has also been added for the same. >> >> tools/launcher/FXLauncherTest.java >> >> Thanks, >> >> Nikita Jain >> > From nikita.j.jain at oracle.com Tue Jan 24 11:48:46 2017 From: nikita.j.jain at oracle.com (Nikita Jain) Date: Tue, 24 Jan 2017 03:48:46 -0800 (PST) Subject: [8u] RFA for backport of JDK-8130041: TsacertOptionTest.java intermittently fails on Mac Message-ID: Hi All, I'd like to backport this fix to Jdk8u-dev. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8130041 Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/78fcb2e094db Public review: http://mail.openjdk.java.net/pipermail/security-dev/2015-July/012542.html Tested with JPRT. Would you please help with approval of the backport? Thanks, Nikita Jain From david.buck at oracle.com Tue Jan 24 11:51:25 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 24 Jan 2017 20:51:25 +0900 Subject: [8u] RFA for backport of JDK-8130041: TsacertOptionTest.java intermittently fails on Mac In-Reply-To: References: Message-ID: <58873FBD.6080608@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/01/24 20:48, Nikita Jain wrote: > Hi All, > > I'd like to backport this fix to Jdk8u-dev. The fix applies cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130041 > Original patch pushed to 9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/78fcb2e094db > Public review: http://mail.openjdk.java.net/pipermail/security-dev/2015-July/012542.html > > Tested with JPRT. Would you please help with approval of the backport? > > Thanks, > Nikita Jain > From anton.litvinov at oracle.com Tue Jan 24 12:19:56 2017 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Tue, 24 Jan 2017 15:19:56 +0300 Subject: [8u-dev] Request for approval for CR 8168751: Two "Direct Clip" threads are created to play the same "AudioClip" object, what makes clip sound corrupted Message-ID: <982233b1-9318-0d2f-bac3-e0022354b62f@oracle.com> Hello, I would like to request for approval to push a straight backport of the fix from JDK 9 to JDK 8. The patch from JDK 9 applies to JDK 8 after correction of a file path. Bug: https://bugs.openjdk.java.net/browse/JDK-8168751 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/0b8c68007690 JDK 9 review thread: Approval 1 - http://mail.openjdk.java.net/pipermail/sound-dev/2017-January/000509.html Approval 2 - http://mail.openjdk.java.net/pipermail/sound-dev/2017-January/000510.html Reviewers: serb, amenkov Thank you, Anton From david.buck at oracle.com Tue Jan 24 12:23:53 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 24 Jan 2017 21:23:53 +0900 Subject: [8u-dev] Request for approval for CR 8168751: Two "Direct Clip" threads are created to play the same "AudioClip" object, what makes clip sound corrupted In-Reply-To: <982233b1-9318-0d2f-bac3-e0022354b62f@oracle.com> References: <982233b1-9318-0d2f-bac3-e0022354b62f@oracle.com> Message-ID: <58874759.6000902@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/01/24 21:19, Anton Litvinov wrote: > Hello, > > I would like to request for approval to push a straight backport of the > fix from JDK 9 to JDK 8. The patch from JDK 9 applies to JDK 8 after > correction of a file path. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168751 > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/0b8c68007690 > JDK 9 review thread: > Approval 1 - > http://mail.openjdk.java.net/pipermail/sound-dev/2017-January/000509.html > Approval 2 - > http://mail.openjdk.java.net/pipermail/sound-dev/2017-January/000510.html > Reviewers: serb, amenkov > > Thank you, > Anton From kevin.walls at oracle.com Fri Jan 27 10:25:34 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 27 Jan 2017 10:25:34 +0000 Subject: [8u-dev] Request for approval: backport 8152271: MemberNameTable doesn't purge stale entries Message-ID: <6de7a7dc-99eb-02d5-3aed-9f19ffbbfe22@oracle.com> Hi, I'd like to backport the following to 8u-dev. 8152271: MemberNameTable doesn't purge stale entries https://bugs.openjdk.java.net/browse/JDK-8152271 An hg import from the 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/13b2c7ac95a5 ...works and tests well in jprt and with a manual testcase that showed a gc slowdown before the fix. Thanks Kevin From david.holmes at oracle.com Fri Jan 27 11:04:54 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Jan 2017 21:04:54 +1000 Subject: [8u-dev] Request for approval: backport 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: <6de7a7dc-99eb-02d5-3aed-9f19ffbbfe22@oracle.com> References: <6de7a7dc-99eb-02d5-3aed-9f19ffbbfe22@oracle.com> Message-ID: <1bcab952-3036-118e-55cf-cbb62916b8e9@oracle.com> Hi Kevin, On 27/01/2017 8:25 PM, Kevin Walls wrote: > Hi, > > I'd like to backport the following to 8u-dev. > > 8152271: MemberNameTable doesn't purge stale entries > > https://bugs.openjdk.java.net/browse/JDK-8152271 That change was backed out again: https://bugs.openjdk.java.net/browse/JDK-8161445 David ----- > An hg import from the 9 changeset: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/13b2c7ac95a5 > > ...works and tests well in jprt and with a manual testcase that showed a > gc slowdown before the fix. > > > Thanks > Kevin > > From kevin.walls at oracle.com Fri Jan 27 12:48:40 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 27 Jan 2017 12:48:40 +0000 Subject: [8u-dev] Request for approval: backport 8152271: MemberNameTable doesn't purge stale entries In-Reply-To: <1bcab952-3036-118e-55cf-cbb62916b8e9@oracle.com> References: <6de7a7dc-99eb-02d5-3aed-9f19ffbbfe22@oracle.com> <1bcab952-3036-118e-55cf-cbb62916b8e9@oracle.com> Message-ID: <861ae548-a6a2-7700-9176-445d20f4b10b@oracle.com> Oh, thanks David. There was me getting excited it solved all my problems... Thanks Kevin On 27/01/2017 11:04, David Holmes wrote: > Hi Kevin, > > On 27/01/2017 8:25 PM, Kevin Walls wrote: >> Hi, >> >> I'd like to backport the following to 8u-dev. >> >> 8152271: MemberNameTable doesn't purge stale entries >> >> https://bugs.openjdk.java.net/browse/JDK-8152271 > > That change was backed out again: > > https://bugs.openjdk.java.net/browse/JDK-8161445 > > David > ----- > >> An hg import from the 9 changeset: >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/13b2c7ac95a5 >> >> ...works and tests well in jprt and with a manual testcase that showed a >> gc slowdown before the fix. >> >> >> Thanks >> Kevin >> >> From sean.coffey at oracle.com Fri Jan 27 16:16:24 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 27 Jan 2017 16:16:24 +0000 Subject: [8u communication] Changes to JDK 8u122 plans In-Reply-To: <368fb6dc-7927-d894-38dd-1ac51094f68f@oracle.com> References: <368fb6dc-7927-d894-38dd-1ac51094f68f@oracle.com> Message-ID: <588B7258.4050202@oracle.com> David, Please label the original (master) record only with such a label. For clarity, I suggest that we change the label to be '8u-CPU-critical-request'. I'll update the documentation [1] to reflect this minor change. [1] http://openjdk.java.net/projects/jdk8u/criticalcpufixes.html Regards, Sean. On 15/12/16 04:23, David Holmes wrote: > Hi Dalibor, > > On 14/12/2016 2:37 AM, dalibor topic wrote: >> Oracle no longer plans to create a separate JDK 8u122 PSU release. As >> such, the proposed schedule for JDK 8u122 in this Project is no longer >> accurate. >> >> Given the very small amount of changes that were destined specifically >> for 8u122 (and not for 8u121 as well), the process to propose critical >> fixes for inclusion in JDK 8u CPU releases [0] should be used instead, >> where applicable. > > Do we label the original JBS issue, or the 8u backport issue? > > Thanks, > David > ----- > >> This holds for future changes to be integrated into jdk8u-dev forest, as >> well as for already integrated changes that were destined for JDK 8u122. >> >> If you have questions or concerns, please share them on the jdk8u-dev >> mailing list. >> >> cheers, >> dalibor topic >> >> [0] http://openjdk.java.net/projects/jdk8u/criticalcpufixes.html From dmitry.markov at oracle.com Tue Jan 31 05:55:58 2017 From: dmitry.markov at oracle.com (dmitry markov) Date: Tue, 31 Jan 2017 08:55:58 +0300 Subject: [8u-dev] Request for approval 8163889: [macosx] Can't print from browser on Mac OS X Message-ID: <589026EE.4010000@oracle.com> Hello, Can I get an approval to port the fix for 8163889 to jdk8u-dev, please? The jdk9 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8163889 Webrev: http://cr.openjdk.java.net/~dmarkov/8163889/jdk8u/webrev.00/ Review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2017-January/008102.html jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b873867cc8b8 Thanks, Dmitry From david.buck at oracle.com Tue Jan 31 06:59:38 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 31 Jan 2017 15:59:38 +0900 Subject: [8u-dev] Request for approval 8163889: [macosx] Can't print from browser on Mac OS X In-Reply-To: <589026EE.4010000@oracle.com> References: <589026EE.4010000@oracle.com> Message-ID: <589035DA.2020909@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/01/31 14:55, dmitry markov wrote: > Hello, > > Can I get an approval to port the fix for 8163889 to jdk8u-dev, please? > The jdk9 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8163889 > Webrev: http://cr.openjdk.java.net/~dmarkov/8163889/jdk8u/webrev.00/ > Review thread: > http://mail.openjdk.java.net/pipermail/2d-dev/2017-January/008102.html > jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b873867cc8b8 > > Thanks, > Dmitry