From fujie at loongson.cn Wed Jan 2 07:01:09 2019 From: fujie at loongson.cn (Fu Jie) Date: Wed, 2 Jan 2019 15:01:09 +0800 Subject: [PATCH] test/jdk/java/beans/PropertyEditor/Test6397609.java failed in JITed code Message-ID: <7c4588a4-698f-ab18-cd5d-61118be5b2ac@loongson.cn> Hi all, test/jdk/java/beans/PropertyEditor/Test6397609.java failed in JITed code of Test6397609::main. The failure was caused by the lost of the OopMap item for the object loader which was optimized out by the JIT with the liveness analysis optimization. For more details, see [1]. It seems that Test6397609.java is only suitable for testing interpreters which is not adapted to JITs at all. Different behaviors performed by the interpreter and JITs with the same test case really confused people a lot. And I think it's worth making the test also suitable for JITs. A tiny change can fix this issue --------------------------------- diff -r b99b41325d89 test/jdk/java/beans/PropertyEditor/Test6397609.java --- a/test/jdk/java/beans/PropertyEditor/Test6397609.java Tue Jan 01 20:09:02 2019 -0500 +++ b/test/jdk/java/beans/PropertyEditor/Test6397609.java Wed Jan 02 12:01:21 2019 +0800 @@ -44,6 +44,7 @@ ???????? if (!isEditorExist(Object.class)) { ???????????? throw new Error("the editor is lost"); ???????? } +??????? loader.hashCode(); // prevent being optimized out by JIT ???????? loader = null; // clean the reference ???????? if (isEditorExist(Object.class)) { ???????????? throw new Error("unexpected editor is found"); --------------------------------- Would you please review it and tell me if it's OK to file on JBS and post a webrev. Thanks. [1] https://github.com/DamonFool/MyBlog/blob/master/JVM/editor-lost-in-jit.md Best Regards, Jie From Alan.Bateman at oracle.com Wed Jan 2 08:50:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 00:50:33 -0800 (PST) Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> Message-ID: <3b6ebd28-c27c-823a-b3ab-85c55be1db76@oracle.com> On 28/12/2018 06:34, Fu Jie wrote: > Hi, > > Please review this patch for a build failure with NetBeans: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 > Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ > > Summary > The build failure is caused by an incorrect setting of preBuildCommand > in make/nb_native/nbproject/configurations.xml. > And all invalid source code items in configurations.xml have been > removed. I don't know the complete history as to why these project files are checked into the repo but doesn't it mean configuration.xml needs to be updated every time that a .c, .h, .cpp, or .hpp file is added, moved, or removed? I assume it will need to an update every week to keep it current so I wonder if you've looked at checking in a script that generates the project to avoid this ongoing maintenance. -Alan From Alan.Bateman at oracle.com Wed Jan 2 10:46:24 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 10:46:24 +0000 Subject: [PATCH] test/jdk/java/beans/PropertyEditor/Test6397609.java failed in JITed code In-Reply-To: <7c4588a4-698f-ab18-cd5d-61118be5b2ac@loongson.cn> References: <7c4588a4-698f-ab18-cd5d-61118be5b2ac@loongson.cn> Message-ID: On 02/01/2019 07:01, Fu Jie wrote: > Hi all, > > test/jdk/java/beans/PropertyEditor/Test6397609.java failed in JITed > code of Test6397609::main. > > The failure was caused by the lost of the OopMap item for the object > loader which was optimized out by the JIT with the liveness analysis > optimization. > For more details, see [1]. > > It seems that Test6397609.java is only suitable for testing > interpreters which is not adapted to JITs at all. > Different behaviors performed by the interpreter and JITs with the > same test case really confused people a lot. > And I think it's worth making the test also suitable for JITs. > > A tiny change can fix this issue > --------------------------------- > diff -r b99b41325d89 test/jdk/java/beans/PropertyEditor/Test6397609.java > --- a/test/jdk/java/beans/PropertyEditor/Test6397609.java Tue Jan 01 > 20:09:02 2019 -0500 > +++ b/test/jdk/java/beans/PropertyEditor/Test6397609.java Wed Jan 02 > 12:01:21 2019 +0800 > @@ -44,6 +44,7 @@ > ???????? if (!isEditorExist(Object.class)) { > ???????????? throw new Error("the editor is lost"); > ???????? } > +??????? loader.hashCode(); // prevent being optimized out by JIT > ???????? loader = null; // clean the reference > ???????? if (isEditorExist(Object.class)) { > ???????????? throw new Error("unexpected editor is found"); The beans-dev list is probably the right place to discuss this change. Also you might want to consider using Reference.reachabilityFence to keep loader from being GC'ed. -Alan From li.jiang at oracle.com Wed Jan 2 14:31:22 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Wed, 2 Jan 2019 22:31:22 +0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 Message-ID: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> Hi, Please review this l10n resource file update for msg drop 10 of JDK 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8215994 Webrev: http://cr.openjdk.java.net/~ljiang/8215994/webrev/read/open/ As I can tell, some messages were added and got translations, as well as some translations got update. We kicked off the msg drop on Dec 20 on jdk/jdk12 forest. If you found any l10n message related to your work missed here, pls let me know and provide the list of file path of resource files involved. Thanks, Leo From goetz.lindenmaier at sap.com Wed Jan 2 14:50:53 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Jan 2019 14:50:53 +0000 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> Message-ID: <394dffb694bb4b18b902d6364557df08@sap.com> Hi Leo, I found some I10n changes that never made it to the main lines: jdk10u: 8198746: http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/4fe8424f43e1 8202588: http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/062bd29ddf59 jdk11u: 8208661: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/211a9137bbde these all seem to be different changes, and they differ to 8207948: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/5b05b3b35687 I think these all need to be brought to 12, too. Also, the jdk10u changes need to be brought to 11u. Or are all these changes covered by 8215994? Also, it would be nice if the bugs could be opened to the public. I don't think they should contain anything confidential. Before, I also talked to Kevin Brown about this. Best regards, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of > li.jiang at oracle.com > Sent: Mittwoch, 2. Januar 2019 15:31 > To: jdk-dev > Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 > > Hi, > > Please review this l10n resource file update for msg drop 10 of JDK 12. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215994 > Webrev: http://cr.openjdk.java.net/~ljiang/8215994/webrev/read/open/ > > As I can tell, some messages were added and got translations, as well as > some translations got update. > > We kicked off the msg drop on Dec 20 on jdk/jdk12 forest. If you found > any l10n message related to your work missed here, pls let me know and > provide the list of file path of resource files involved. > > Thanks, > Leo From Alan.Bateman at oracle.com Wed Jan 2 15:53:05 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 15:53:05 +0000 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <394dffb694bb4b18b902d6364557df08@sap.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <394dffb694bb4b18b902d6364557df08@sap.com> Message-ID: <17538f33-dba6-b75e-5fda-4939586494e0@oracle.com> On 02/01/2019 14:50, Lindenmaier, Goetz wrote: > Hi Leo, > > I found some I10n changes that never made it to the main lines: > jdk10u: > 8198746: http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/4fe8424f43e1 > 8202588: http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/062bd29ddf59 > jdk11u: > 8208661: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/211a9137bbde > these all seem to be different changes, and they differ to > 8207948: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/5b05b3b35687 > > I think these all need to be brought to 12, too. Also, the jdk10u changes need > to be brought to 11u. Or are all these changes covered by 8215994? Leo may be off-line now but I think the description in JDK-8215994 needs to be updated to make it clear that the translation refresh is only the translations that Oracle funds (I think Japanese, Simplified Chinese and Traditional Chinese from JDK 11). AFAIK, this means that changes to those translations pushed to jdk-update/jdku don't need to be forward ported as they will be superseded by the translation drops like this one. There are resource files for several other locales in the repo that may be showing early signs of bit rot so it's an area where others can contribute and/or fund. So it might be that a subset of translation changes pushed to JDK 10 updates may be useful to bring into jdk/jdk12. -Alan From goetz.lindenmaier at sap.com Wed Jan 2 16:05:23 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Jan 2019 16:05:23 +0000 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <17538f33-dba6-b75e-5fda-4939586494e0@oracle.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <394dffb694bb4b18b902d6364557df08@sap.com> <17538f33-dba6-b75e-5fda-4939586494e0@oracle.com> Message-ID: > > I found some I10n changes that never made it to the main lines: > > jdk10u: ... > those translations pushed to jdk-update/jdku don't need to be forward > ported as they will be superseded by the translation drops like this one. No, the changes I mention did not make it to 11 or 12. They were made by Oracle in the hidden jdk>u branches and then released to the public. For the jdk10u changes I checked that they can be applied cleanly to jdk11.0.1, so those translations are missing there. ... > There are resource files for several other locales in the repo that may > be showing early signs of bit rot so it's an area where others can > contribute and/or fund. Last Spring a change of mine was rejected claiming that these files are handled by Oracle. So did this policy change now? Best regards, Goetz. From li.jiang at oracle.com Wed Jan 2 16:20:31 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Thu, 3 Jan 2019 00:20:31 +0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <17538f33-dba6-b75e-5fda-4939586494e0@oracle.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <394dffb694bb4b18b902d6364557df08@sap.com> <17538f33-dba6-b75e-5fda-4939586494e0@oracle.com> Message-ID: <93b69c71-1acb-2808-4ea1-9d1d2b638f02@oracle.com> Correct one thing: Only Simplified Chinese and Japanese got support since JDK 11. As the English message might be different between JDK 10+ releases, we should be very careful to forward port the update to jdk12. And obviously it's almost impossible to backport a changeset because generally a msg drop changeset would involve lots of files and kinds of updates. Thanks, Leo On 1/2/19 11:53 PM, Alan Bateman wrote: > On 02/01/2019 14:50, Lindenmaier, Goetz wrote: >> Hi Leo, >> >> I found some I10n changes that never made it to the main lines: >> jdk10u: >> ?? 8198746: >> http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/4fe8424f43e1 >> ?? 8202588: >> http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/062bd29ddf59 >> jdk11u: >> ?? 8208661: >> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/211a9137bbde >> these all seem to be different changes, and they differ to >> ?? 8207948: >> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/5b05b3b35687 >> >> I think these all need to be brought to 12, too.? Also, the jdk10u >> changes need >> to be brought to 11u.? Or are all these changes covered by 8215994? > Leo may be off-line now but I think the description in JDK-8215994 needs > to be updated to make it clear that the translation refresh is only the > translations that Oracle funds (I think Japanese, Simplified Chinese and > Traditional Chinese from JDK 11). AFAIK, this means that changes to > those translations pushed to jdk-update/jdku don't need to be forward > ported as they will be superseded by the translation drops like this one. > > There are resource files for several other locales in the repo that may > be showing early signs of bit rot so it's an area where others can > contribute and/or fund. So it might be that a subset of translation > changes pushed to JDK 10 updates may be useful to bring into jdk/jdk12. > > -Alan From li.jiang at oracle.com Wed Jan 2 16:29:09 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Thu, 3 Jan 2019 00:29:09 +0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <394dffb694bb4b18b902d6364557df08@sap.com> <17538f33-dba6-b75e-5fda-4939586494e0@oracle.com> Message-ID: <8ac31960-f047-ee8d-2328-b8df4f474fe2@oracle.com> On 1/3/19 12:05 AM, Lindenmaier, Goetz wrote: > >>> I found some I10n changes that never made it to the main lines: >>> jdk10u: > ... >> those translations pushed to jdk-update/jdku don't need to be forward >> ported as they will be superseded by the translation drops like this one. > No, the changes I mention did not make it to 11 or 12. They were made > by Oracle in the hidden jdk>u branches and then released to the public. > For the jdk10u changes I checked that they can be applied cleanly to > jdk11.0.1, so those translations are missing there. Even you can apply cleanly the patch, but pls don't. Normally it means you would override the correct translation. As I had explained to Kevin, the translation got refreshed in every msg drop. The msg drop will fix the translation automatically. > > ... >> There are resource files for several other locales in the repo that may >> be showing early signs of bit rot so it's an area where others can >> contribute and/or fund. > Last Spring a change of mine was rejected claiming that these files are > handled by Oracle. So did this policy change now? Currently Oracle provide the effort to support Simplified Chinese and Japanese. > > Best regards, > Goetz. > > > From mailtoarlo at gmail.com Wed Jan 2 07:50:08 2019 From: mailtoarlo at gmail.com (Arlo O'Keeffe) Date: Wed, 2 Jan 2019 08:50:08 +0100 Subject: JDK-8203526 fix not in OpenJDK 11.0.1 Message-ID: Hello everyone, my name is Arlo and I am currently experiencing a problem that was apparently already fixed: https://bugs.openjdk.java.net/browse/JDK-8202113 and https://bugs.openjdk.java.net/browse/JDK-8203526 I am using OpenJDK 11.0.1 and the fix is somehow not included. Am I missing something? When I check the jdk-11+28 tag (76072a077ee1) on http://hg.openjdk.java.net/jdk/jdk/tags I can't seem to find the fixed code. The newInstanceCallerCache is still included: http://hg.openjdk.java.net/jdk/jdk/file/76072a077ee1/src/java.base/share/classes/java/lang/Class.java#l573 The jdk12+23 tag (eef755718cb2) contains the fix: http://hg.openjdk.java.net/jdk/jdk/file/eef755718cb2/src/java.base/share/classes/java/lang/Class.java#l579 Please let me know if I have missed something. Thanks in advance! From Alan.Bateman at oracle.com Wed Jan 2 16:57:06 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 2 Jan 2019 16:57:06 +0000 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <8ac31960-f047-ee8d-2328-b8df4f474fe2@oracle.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <394dffb694bb4b18b902d6364557df08@sap.com> <17538f33-dba6-b75e-5fda-4939586494e0@oracle.com> <8ac31960-f047-ee8d-2328-b8df4f474fe2@oracle.com> Message-ID: On 02/01/2019 16:29, li.jiang at oracle.com wrote: > > > On 1/3/19 12:05 AM, Lindenmaier, Goetz wrote: >> >>>> I found some I10n changes that never made it to the main lines: >>>> jdk10u: >> ... >>> those translations pushed to jdk-update/jdku don't need to be >>> forward >>> ported as they will be superseded by the translation drops like this >>> one. >> No, the changes I mention did not make it to 11 or 12.? They were made >> by Oracle in the hidden jdk>u branches and then released to the >> public. >> For the jdk10u changes I checked that they can be applied cleanly to >> jdk11.0.1, so those translations are missing there. > > Even you can apply cleanly the patch, but pls don't. Normally it means > you would override the correct translation. As I had explained to > Kevin, the translation got refreshed in every msg drop. The msg drop > will fix the translation automatically. I think you mean the translations for Japanese and Simplified Chinese here. I assume it's not an issue if Goetz brings forward changes to other translations, assuming they are still accurate, as they will not conflict with your message drops. -Alan From sean.coffey at oracle.com Wed Jan 2 17:15:20 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 2 Jan 2019 17:15:20 +0000 Subject: JDK-8203526 fix not in OpenJDK 11.0.1 In-Reply-To: References: Message-ID: I think you're getting your bug numbers mixed up. newInstanceCallerCache code was removed via https://bugs.openjdk.java.net/browse/JDK-8206240 which is not fixed in an 11.0.x release yet. regards, Sean. On 02/01/2019 07:50, Arlo O'Keeffe wrote: > Hello everyone, > > my name is Arlo and I am currently experiencing a problem that was > apparently already fixed: > > https://bugs.openjdk.java.net/browse/JDK-8202113 and > https://bugs.openjdk.java.net/browse/JDK-8203526 > > I am using OpenJDK 11.0.1 and the fix is somehow not included. Am I > missing something? > > When I check the jdk-11+28 tag (76072a077ee1) on > http://hg.openjdk.java.net/jdk/jdk/tags I can't seem to find the fixed > code. > > The newInstanceCallerCache is still included: > > http://hg.openjdk.java.net/jdk/jdk/file/76072a077ee1/src/java.base/share/classes/java/lang/Class.java#l573 > > The jdk12+23 tag (eef755718cb2) contains the fix: > > http://hg.openjdk.java.net/jdk/jdk/file/eef755718cb2/src/java.base/share/classes/java/lang/Class.java#l579 > > Please let me know if I have missed something. > > Thanks in advance! From li.jiang at oracle.com Thu Jan 3 00:14:50 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Thu, 3 Jan 2019 08:14:50 +0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <394dffb694bb4b18b902d6364557df08@sap.com> <17538f33-dba6-b75e-5fda-4939586494e0@oracle.com> <8ac31960-f047-ee8d-2328-b8df4f474fe2@oracle.com> Message-ID: <40d93f4b-bbfc-f8c8-80a6-0407aa5735a9@oracle.com> On 1/3/19 12:57 AM, Alan Bateman wrote: > On 02/01/2019 16:29, li.jiang at oracle.com wrote: >> >> >> On 1/3/19 12:05 AM, Lindenmaier, Goetz wrote: >>> >>>>> I found some I10n changes that never made it to the main lines: >>>>> jdk10u: >>> ... >>>> those translations pushed to jdk-update/jdku don't need to be >>>> forward >>>> ported as they will be superseded by the translation drops like this >>>> one. >>> No, the changes I mention did not make it to 11 or 12.? They were made >>> by Oracle in the hidden jdk>u branches and then released to the >>> public. >>> For the jdk10u changes I checked that they can be applied cleanly to >>> jdk11.0.1, so those translations are missing there. >> >> Even you can apply cleanly the patch, but pls don't. Normally it means >> you would override the correct translation. As I had explained to >> Kevin, the translation got refreshed in every msg drop. The msg drop >> will fix the translation automatically. Yes, if no conflict. But still not necessary. Every time message drop run, each line of messages in all of resource files are got refreshed according to accurate translation in translation memory. So actually a msg drop changeset is a patch to all of resource files. > I think you mean the translations for Japanese and Simplified Chinese > here. I assume it's not an issue if Goetz brings forward changes to > other translations, assuming they are still accurate, as they will not > conflict with your message drops. > > -Alan From adam.farley at uk.ibm.com Thu Jan 3 15:09:00 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 3 Jan 2019 15:09:00 +0000 Subject: RFR: JDK-8197541: Test run requested Message-ID: Hi All, Can a committer please run ToolBasicTest.java on Windows on the OpenJDK testing infra? I'm unable to reproduce the defect locally, and I want to verify if it still happens. If it does still occur, I would appreciate any insight into why it doesn't occur on my local windows 10 box. I.e. Does it only happen on Windows 7, is the reproduction rate 1 in 100, etc. Bug link: https://bugs.openjdk.java.net/browse/JDK-8197541 Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From mailtoarlo at gmail.com Fri Jan 4 13:36:00 2019 From: mailtoarlo at gmail.com (Arlo O'Keeffe) Date: Fri, 4 Jan 2019 14:36:00 +0100 Subject: JDK-8203526 fix not in OpenJDK 11.0.1 In-Reply-To: References: Message-ID: Thanks, Sean. I missed that bug. Glad that it was found and fixed. I will wait for a 11.0.x release then. On 1/2/19, Se?n Coffey wrote: > I think you're getting your bug numbers mixed up. > > newInstanceCallerCache code was removed via > https://bugs.openjdk.java.net/browse/JDK-8206240 which is not fixed in > an 11.0.x release yet. > > regards, > Sean. > > On 02/01/2019 07:50, Arlo O'Keeffe wrote: >> Hello everyone, >> >> my name is Arlo and I am currently experiencing a problem that was >> apparently already fixed: >> >> https://bugs.openjdk.java.net/browse/JDK-8202113 and >> https://bugs.openjdk.java.net/browse/JDK-8203526 >> >> I am using OpenJDK 11.0.1 and the fix is somehow not included. Am I >> missing something? >> >> When I check the jdk-11+28 tag (76072a077ee1) on >> http://hg.openjdk.java.net/jdk/jdk/tags I can't seem to find the fixed >> code. >> >> The newInstanceCallerCache is still included: >> >> http://hg.openjdk.java.net/jdk/jdk/file/76072a077ee1/src/java.base/share/classes/java/lang/Class.java#l573 >> >> The jdk12+23 tag (eef755718cb2) contains the fix: >> >> http://hg.openjdk.java.net/jdk/jdk/file/eef755718cb2/src/java.base/share/classes/java/lang/Class.java#l579 >> >> Please let me know if I have missed something. >> >> Thanks in advance! > -- Arlo O'Keeffe From jbvernee at xs4all.nl Sat Jan 5 19:56:24 2019 From: jbvernee at xs4all.nl (Jorn Vernee) Date: Sat, 05 Jan 2019 20:56:24 +0100 Subject: Resolution/translation of VarHandle.compareAndSet seems to conflict with JVMS/javadoc. Message-ID: Hi, I'm bringing this up based on a question asked on Stack Overflow [1]. For the following code: public class Main { public int publicTestVariable = 10; public static void main(String[] args) throws Throwable { Main e = new Main(); e.update(); } public void update() throws Throwable { VarHandle publicIntHandle = MethodHandles.lookup() .findVarHandle(Main.class, "publicTestVariable", int.class); publicIntHandle.compareAndSet(this, 10, 100); } } javac derives the descriptor for the call to `compareAndSet` [2] as `(Lmain/Main;II)Z`, but eclipsec derives the descriptor as `(Lmain/Main;II)V`. Note that `compareAndSet` is signature polymorphic. Each compiler generates a different return type. The one generated by eclipsec seems to be correct since the call site has no indication that the call should return a boolean. According to the javadoc for Signature polymorphism [3] "The unusual part is that the symbolic type descriptor is derived from the actual argument and return types, not from the method declaration.", and the code generated by javac definitely seems to depend on the method declaration, and not just the call site. When running the eclipsec generated code on jdk/jdk tip this throws a NSME: Exception in thread "main" java.lang.NoSuchMethodError: VarHandle.compareAndSet(Main,int,int)void at java.base/java.lang.invoke.MethodHandleNatives.newNoSuchMethodErrorOnVarHandle(MethodHandleNatives.java:576) at java.base/java.lang.invoke.MethodHandleNatives.varHandleOperationLinkerMethod(MethodHandleNatives.java:529) at java.base/java.lang.invoke.MethodHandleNatives.linkMethodImpl(MethodHandleNatives.java:462) at java.base/java.lang.invoke.MethodHandleNatives.linkMethod(MethodHandleNatives.java:450) at main.Main.update(Main.java:18) at main.Main.main(Main.java:12) While the code generated by javac runs without an error. Regardless of the question whether discarding the returned value is a good idea or not, the exception being thrown seems to conflict with JVMS-5.4.3.3 [4] which states: "If C declares exactly one method with the name specified by the method reference, and the declaration is a signature polymorphic method (?2.9.3), then method lookup succeeds. All the class names mentioned in the descriptor are resolved (?5.4.3.1). The resolved method is the signature polymorphic method declaration. It is not necessary for C to declare a method with the descriptor specified by the method reference." The javadoc [3] also says that: "When the JVM processes bytecode containing signature polymorphic calls, it will successfully link any such call, regardless of its symbolic type descriptor". So the VM should not be throwing an NSME here AFAICT. But, it looks like this case is being checked explicitly and an error is being thrown [5]: if (ak.at.isMonomorphicInReturnType) { if (ak.at.returnType != mtype.returnType()) { // The caller contains a different return type than that // defined by the method throw newNoSuchMethodErrorOnVarHandle(name, mtype); } // Adjust the return type of the signature method type guardReturnType = ak.at.returnType; } I guess this is being done because the return type of compareAndSet is monomorphic, but imho the call should still succeed with `void` as a return type (discarding the value). For other types, it would be more consistent with the spec/doc if the return type was dynamically cast to that of the descriptor, with possible CCE, but linking still succeeded. Any thoughts on this? Cheers, Jorn [1] : https://stackoverflow.com/q/52962939 [2] : https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/VarHandle.html#compareAndSet(java.lang.Object...) [3] : https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandle.html#sigpoly [4] : https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-5.html#jvms-5.4.3.3 [5] : http://hg.openjdk.java.net/jdk/jdk/file/22baf8054a40/src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java#l526 From li.jiang at oracle.com Mon Jan 7 02:01:49 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Mon, 7 Jan 2019 10:01:49 +0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> Message-ID: <5e8ab666-7adc-cc67-5fdf-079966587277@oracle.com> Ping! I need reviewer to help this. Very appreciated! Thanks, Leo On 1/2/19 10:31 PM, li.jiang at oracle.com wrote: > Hi, > > Please review this l10n resource file update for msg drop 10 of JDK 12. > > Bug:? https://bugs.openjdk.java.net/browse/JDK-8215994 > Webrev: http://cr.openjdk.java.net/~ljiang/8215994/webrev/read/open/ > > As I can tell, some messages were added and got translations, as well as > some translations got update. > > We kicked off the msg drop on Dec 20 on jdk/jdk12 forest. If you found > any l10n message related to your work missed here, pls let me know and > provide the list of file path of resource files involved. > > Thanks, > Leo From naoto.sato at oracle.com Mon Jan 7 23:26:38 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 7 Jan 2019 15:26:38 -0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <5e8ab666-7adc-cc67-5fdf-079966587277@oracle.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <5e8ab666-7adc-cc67-5fdf-079966587277@oracle.com> Message-ID: <6bb8cf60-b62c-ae09-2db6-5c407ec42388@oracle.com> Hi Leo, Just skimmed and looks good except, Do you expect another round of L10n drop? I see a translation for raw string literals related (compiler_*.properties) which no longer exist. Naoto On 1/6/19 6:01 PM, li.jiang at oracle.com wrote: > Ping! > > I need reviewer to help this. Very appreciated! > > Thanks, > Leo > > On 1/2/19 10:31 PM, li.jiang at oracle.com wrote: >> Hi, >> >> Please review this l10n resource file update for msg drop 10 of JDK 12. >> >> Bug:? https://bugs.openjdk.java.net/browse/JDK-8215994 >> Webrev: http://cr.openjdk.java.net/~ljiang/8215994/webrev/read/open/ >> >> As I can tell, some messages were added and got translations, as well >> as some translations got update. >> >> We kicked off the msg drop on Dec 20 on jdk/jdk12 forest. If you found >> any l10n message related to your work missed here, pls let me know and >> provide the list of file path of resource files involved. >> >> Thanks, >> Leo From markus.gronlund at oracle.com Tue Jan 8 11:46:31 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 8 Jan 2019 03:46:31 -0800 (PST) Subject: Result: New JDK Reviewer: Erik Gahlin Message-ID: <183b9b8c-32d9-4855-9f3a-fd9ba522956c@default> Voting for Erik Gahlin (egahlin) [1] is now closed. Yes: 28 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Markus [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002436.html From li.jiang at oracle.com Tue Jan 8 13:54:09 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Tue, 8 Jan 2019 21:54:09 +0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <6bb8cf60-b62c-ae09-2db6-5c407ec42388@oracle.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <5e8ab666-7adc-cc67-5fdf-079966587277@oracle.com> <6bb8cf60-b62c-ae09-2db6-5c407ec42388@oracle.com> Message-ID: Thank you Naoto! We will run the 2nd msg drop for JDK 12 on Jan 24th and another msg drop only if needed. Would you point out which message in compiler.properties is not exist or any message missing in compiler_*.properties in this webrev? I checked the hg history, looks like the msg drop have caught the latest change on compiler.properties: 8212982: Rule cases in switch expression accepted even if complete normally If you're talking about the task, Remove compiler support for Raw String Literals from JDK 12, I think once it's done before the msg drop deadline, the related messages will be removed. Thanks, Leo On 1/8/19 7:26 AM, Naoto Sato wrote: > Hi Leo, > > Just skimmed and looks good except, > > Do you expect another round of L10n drop? I see a translation for raw > string literals related (compiler_*.properties) which no longer exist. > > Naoto > > On 1/6/19 6:01 PM, li.jiang at oracle.com wrote: >> Ping! >> >> I need reviewer to help this. Very appreciated! >> >> Thanks, >> Leo >> >> On 1/2/19 10:31 PM, li.jiang at oracle.com wrote: >>> Hi, >>> >>> Please review this l10n resource file update for msg drop 10 of JDK 12. >>> >>> Bug:? https://bugs.openjdk.java.net/browse/JDK-8215994 >>> Webrev: http://cr.openjdk.java.net/~ljiang/8215994/webrev/read/open/ >>> >>> As I can tell, some messages were added and got translations, as well >>> as some translations got update. >>> >>> We kicked off the msg drop on Dec 20 on jdk/jdk12 forest. If you >>> found any l10n message related to your work missed here, pls let me >>> know and provide the list of file path of resource files involved. >>> >>> Thanks, >>> Leo From naoto.sato at oracle.com Tue Jan 8 15:02:15 2019 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 8 Jan 2019 07:02:15 -0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <5e8ab666-7adc-cc67-5fdf-079966587277@oracle.com> <6bb8cf60-b62c-ae09-2db6-5c407ec42388@oracle.com> Message-ID: <8837ea12-5363-3161-d636-494cf80e877c@oracle.com> Never mind. I was referring to the translation for "compiler.misc.feature.raw.string.literals" in compiler_*.properties, but it's still in the English resource file. Naoto On 1/8/19 5:54 AM, li.jiang at oracle.com wrote: > Thank you Naoto! > > We will run the 2nd msg drop for JDK 12 on Jan 24th and another msg drop > only if needed. > > Would you point out which message in compiler.properties is not exist or > any message missing in compiler_*.properties in this webrev? > > I checked the hg history, looks like the msg drop have caught the latest > change on compiler.properties: > 8212982: Rule cases in switch expression accepted even if complete normally > > If you're talking about the task, Remove compiler support for Raw String > Literals from JDK 12, I think once it's done before the msg drop > deadline, the related messages will be removed. > > Thanks, > Leo > > On 1/8/19 7:26 AM, Naoto Sato wrote: >> Hi Leo, >> >> Just skimmed and looks good except, >> >> Do you expect another round of L10n drop? I see a translation for raw >> string literals related (compiler_*.properties) which no longer exist. >> >> Naoto >> >> On 1/6/19 6:01 PM, li.jiang at oracle.com wrote: >>> Ping! >>> >>> I need reviewer to help this. Very appreciated! >>> >>> Thanks, >>> Leo >>> >>> On 1/2/19 10:31 PM, li.jiang at oracle.com wrote: >>>> Hi, >>>> >>>> Please review this l10n resource file update for msg drop 10 of JDK 12. >>>> >>>> Bug:? https://bugs.openjdk.java.net/browse/JDK-8215994 >>>> Webrev: http://cr.openjdk.java.net/~ljiang/8215994/webrev/read/open/ >>>> >>>> As I can tell, some messages were added and got translations, as >>>> well as some translations got update. >>>> >>>> We kicked off the msg drop on Dec 20 on jdk/jdk12 forest. If you >>>> found any l10n message related to your work missed here, pls let me >>>> know and provide the list of file path of resource files involved. >>>> >>>> Thanks, >>>> Leo From Michael.Kebe at hkm.de Tue Jan 8 14:27:41 2019 From: Michael.Kebe at hkm.de (Michael Kebe) Date: Tue, 8 Jan 2019 14:27:41 +0000 Subject: Error placementdelmatch when compiling OpenJDK 11 with Oracle Developer Studio Message-ID: <20190108-152754.13hbpbdro-2lai@mailcc08> Hi, I am trying to compile OpenJDK 11 from the hg source (http://hg.openjdk.java.net/jdk-updates/jdk11u), but I get this error: "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 60: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 67: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 97: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. I found this issue https://bugs.openjdk.java.net/browse/JDK-8164651. It says in a comment, that is fixed, but I used the bleeding edge from the mercurial repository. Is the support for Solaris dropped? Additional info from the configure script: A new configuration has been successfully created in /..../jdk11u/build/solaris-sparcv9-normal-server-release using configure arguments '--with-boot-jdk=../jdk-11.0.1'. Configuration summary: * Debug level: release * HS debug level: product * JVM variants: server * JVM features: server: 'cds cmsgc compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management nmt parallelgc serialgc services vm-structs' * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 * Version string: 11.0.1-internal+0-adhoc.sysa.jdk11u (11.0.1-internal) Tools summary: * Boot JDK: java version "11.0.1" 2018-10-16 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode) (at /..../jdk-11.0.1) * Toolchain: solstudio (Oracle Solaris Studio) * C Compiler: Version 5.14 (at /opt/developerstudio12.5/bin/cc) * C++ Compiler: Version 5.14 (at /opt/developerstudio12.5/bin/CC) Build performance summary: * Cores to use: 16 * Memory limit: 20480 MB Michael H?ttenwerke Krupp Mannesmann GmbH, Ehinger Str. 200, D-47259 Duisburg Gesch?ftsf?hrung: Dr. Herbert Eichelkraut, Dr. Gerhard Erdmann, Carsten Laakmann Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. Heinz J?rg Fuhrmann Sitz der Gesellschaft: Duisburg Eintragung im Handelsregister: Amtsgericht Duisburg HRB 4716 http://www.hkm.de From david.holmes at oracle.com Tue Jan 8 23:11:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Jan 2019 09:11:42 +1000 Subject: Error placementdelmatch when compiling OpenJDK 11 with Oracle Developer Studio In-Reply-To: <20190108-152754.13hbpbdro-2lai@mailcc08> References: <20190108-152754.13hbpbdro-2lai@mailcc08> Message-ID: <6bed0312-efa1-1fff-dc47-fa7994089304@oracle.com> Hi Michael, I've bcc'd jdk-dev and am moving this to hotspot-dev. The official Solaris compiler for OpenJDK is still SS12u4 so we aren't seeing this issue exposed by SS12u5. I think JDK-8164651 may have been closed in error thinking it was the same issue as JDK-8196880, but I think they are different. David ----- On 9/01/2019 12:27 am, Michael Kebe wrote: > Hi, > > I am trying to compile OpenJDK 11 from the hg source (http://hg.openjdk.java.net/jdk-updates/jdk11u), but I get this error: > > "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 60: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. > "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 67: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. > "..../jdk11u/src/hotspot/share/adlc/arena.cpp", line 97: Error, placementdelmatch: Placement operator new refers to non-placement operator delete. > > I found this issue https://bugs.openjdk.java.net/browse/JDK-8164651. > It says in a comment, that is fixed, but I used the bleeding edge from the mercurial repository. > > Is the support for Solaris dropped? > > Additional info from the configure script: > > A new configuration has been successfully created in > /..../jdk11u/build/solaris-sparcv9-normal-server-release > using configure arguments '--with-boot-jdk=../jdk-11.0.1'. > > Configuration summary: > * Debug level: release > * HS debug level: product > * JVM variants: server > * JVM features: server: 'cds cmsgc compiler1 compiler2 dtrace epsilongc g1gc jfr jni-check jvmci jvmti management nmt parallelgc serialgc services vm-structs' > * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 > * Version string: 11.0.1-internal+0-adhoc.sysa.jdk11u (11.0.1-internal) > > Tools summary: > * Boot JDK: java version "11.0.1" 2018-10-16 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode) (at /..../jdk-11.0.1) > * Toolchain: solstudio (Oracle Solaris Studio) > * C Compiler: Version 5.14 (at /opt/developerstudio12.5/bin/cc) > * C++ Compiler: Version 5.14 (at /opt/developerstudio12.5/bin/CC) > > Build performance summary: > * Cores to use: 16 > * Memory limit: 20480 MB > > > Michael > > > > H?ttenwerke Krupp Mannesmann GmbH, Ehinger Str. 200, D-47259 Duisburg > Gesch?ftsf?hrung: Dr. Herbert Eichelkraut, Dr. Gerhard Erdmann, Carsten Laakmann > Vorsitzender des Aufsichtsrats: Prof. Dr.-Ing. Heinz J?rg Fuhrmann > Sitz der Gesellschaft: Duisburg > Eintragung im Handelsregister: Amtsgericht Duisburg HRB 4716 > http://www.hkm.de > From li.jiang at oracle.com Wed Jan 9 08:27:25 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Wed, 9 Jan 2019 16:27:25 +0800 Subject: RFR 8215994 : JDK 12 l10n resource file update - msg drop 10 In-Reply-To: <8837ea12-5363-3161-d636-494cf80e877c@oracle.com> References: <4173fbaf-99c5-3e5d-d146-6345d097c329@oracle.com> <5e8ab666-7adc-cc67-5fdf-079966587277@oracle.com> <6bb8cf60-b62c-ae09-2db6-5c407ec42388@oracle.com> <8837ea12-5363-3161-d636-494cf80e877c@oracle.com> Message-ID: Thank you, pushed! -Leo On 1/8/19 11:02 PM, Naoto Sato wrote: > Never mind. I was referring to the translation for > "compiler.misc.feature.raw.string.literals" in compiler_*.properties, > but it's still in the English resource file. > > Naoto > > On 1/8/19 5:54 AM, li.jiang at oracle.com wrote: >> Thank you Naoto! >> >> We will run the 2nd msg drop for JDK 12 on Jan 24th and another msg >> drop only if needed. >> >> Would you point out which message in compiler.properties is not exist >> or any message missing in compiler_*.properties in this webrev? >> >> I checked the hg history, looks like the msg drop have caught the >> latest change on compiler.properties: >> 8212982: Rule cases in switch expression accepted even if complete >> normally >> >> If you're talking about the task, Remove compiler support for Raw >> String Literals from JDK 12, I think once it's done before the msg >> drop deadline, the related messages will be removed. >> >> Thanks, >> Leo >> >> On 1/8/19 7:26 AM, Naoto Sato wrote: >>> Hi Leo, >>> >>> Just skimmed and looks good except, >>> >>> Do you expect another round of L10n drop? I see a translation for raw >>> string literals related (compiler_*.properties) which no longer exist. >>> >>> Naoto >>> >>> On 1/6/19 6:01 PM, li.jiang at oracle.com wrote: >>>> Ping! >>>> >>>> I need reviewer to help this. Very appreciated! >>>> >>>> Thanks, >>>> Leo >>>> >>>> On 1/2/19 10:31 PM, li.jiang at oracle.com wrote: >>>>> Hi, >>>>> >>>>> Please review this l10n resource file update for msg drop 10 of JDK >>>>> 12. >>>>> >>>>> Bug:? https://bugs.openjdk.java.net/browse/JDK-8215994 >>>>> Webrev: http://cr.openjdk.java.net/~ljiang/8215994/webrev/read/open/ >>>>> >>>>> As I can tell, some messages were added and got translations, as >>>>> well as some translations got update. >>>>> >>>>> We kicked off the msg drop on Dec 20 on jdk/jdk12 forest. If you >>>>> found any l10n message related to your work missed here, pls let me >>>>> know and provide the list of file path of resource files involved. >>>>> >>>>> Thanks, >>>>> Leo From shade at redhat.com Wed Jan 9 14:29:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 9 Jan 2019 15:29:29 +0100 Subject: Submit repo task IDs Message-ID: <828c0281-174d-d2e9-7d69-0b099ed56428@redhat.com> Hi, Current submit repo job IDs are rather confusing. For example, for a given branch, I have got five IDs: [Mach5] mach5-one-shade-JDK-8215724-20190108-1643-17048: PASSED [Mach5] mach5-one-shade-JDK-8215724-20190108-2239-17125: PASSED [Mach5] mach5-one-shade-JDK-8215724-20190109-0216-17166: PASSED [Mach5] mach5-one-shade-JDK-8215724-20190109-0913-17241: PASSED [Mach5] mach5-one-shade-JDK-8215724-20190109-1210-17278: PASSED Yet, none of this tells me what exactly was being tested. Were they the restarts on the existing state of the branches? Were they my own pushes to the branch? The dates are not very conclusive either: they are the times submit picked up my change, not when I have pushed? There is a simple (I think) solution here: add the Mercurial changeset id to the jdk-submit task ID. Then I can cross-reference with current state of jdk-submit and see what was tested. For example: [Mach5] mach5-one-shade-JDK-8215724-a0fe11b61b94-17278 Also, I don't think it is useful to have timestamp in there, and it only adds the noise? Whatever the value is at the end (17278, is this internal job ID?) might be enough to disambiguate different jobs. Thanks, -Aleksey From sgehwolf at redhat.com Wed Jan 9 15:32:57 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 Jan 2019 16:32:57 +0100 Subject: Submit repo task IDs In-Reply-To: <828c0281-174d-d2e9-7d69-0b099ed56428@redhat.com> References: <828c0281-174d-d2e9-7d69-0b099ed56428@redhat.com> Message-ID: <4ec1f9b1db850065a4076704cd7ebc0e5813c0a8.camel@redhat.com> On Wed, 2019-01-09 at 15:29 +0100, Aleksey Shipilev wrote: > Hi, > > Current submit repo job IDs are rather confusing. For example, for a > given branch, I have got five IDs: > > [Mach5] mach5-one-shade-JDK-8215724-20190108-1643-17048: PASSED > [Mach5] mach5-one-shade-JDK-8215724-20190108-2239-17125: PASSED > [Mach5] mach5-one-shade-JDK-8215724-20190109-0216-17166: PASSED > [Mach5] mach5-one-shade-JDK-8215724-20190109-0913-17241: PASSED > [Mach5] mach5-one-shade-JDK-8215724-20190109-1210-17278: PASSED Not sure if that's related, but I've been getting nofications of branches/bugs which no longer exist post-submit-repo-reset. The way to stop them was closing the branch, but that's no longer possible after the reset :-/ Thanks, Severin From daniel.smith at oracle.com Thu Jan 10 20:36:12 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 10 Jan 2019 13:36:12 -0700 Subject: Resolution/translation of VarHandle.compareAndSet seems to conflict with JVMS/javadoc. In-Reply-To: References: Message-ID: Thanks for this report. The research you've already put into it is quite helpful. > On Jan 5, 2019, at 12:56 PM, Jorn Vernee wrote: > > For the following code: > > public class Main { > public int publicTestVariable = 10; > > public static void main(String[] args) throws Throwable { > Main e = new Main(); > e.update(); > } > > public void update() throws Throwable { > VarHandle publicIntHandle = MethodHandles.lookup() > .findVarHandle(Main.class, "publicTestVariable", int.class); > publicIntHandle.compareAndSet(this, 10, 100); > } > } > > javac derives the descriptor for the call to `compareAndSet` [2] as `(Lmain/Main;II)Z`, but eclipsec derives the descriptor as `(Lmain/Main;II)V`. Note that `compareAndSet` is signature polymorphic. > > Each compiler generates a different return type. The one generated by eclipsec seems to be correct since the call site has no indication that the call should return a boolean. According to the javadoc for Signature polymorphism [3] "The unusual part is that the symbolic type descriptor is derived from the actual argument and return types, not from the method declaration.", and the code generated by javac definitely seems to depend on the method declaration, and not just the call site. javac is correct here. See https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.12.3-400-B "If the signature polymorphic method is either void or has a return type other than Object, the compile-time result is the result of the invocation type of the compile-time declaration" The informal description in javadoc that you reference is incomplete, and I've filed a bug to fix that: https://bugs.openjdk.java.net/browse/JDK-8216511 > Regardless of the question whether discarding the returned value is a good idea or not, the exception being thrown seems to conflict with JVMS-5.4.3.3 [4] which states: > > "If C declares exactly one method with the name specified by the method reference, and the declaration is a signature polymorphic method (?2.9.3), then method lookup succeeds. All the class names mentioned in the descriptor are resolved (?5.4.3.1). The resolved method is the signature polymorphic method declaration. It is not necessary for C to declare a method with the descriptor specified by the method reference." > > The javadoc [3] also says that: "When the JVM processes bytecode containing signature polymorphic calls, it will successfully link any such call, regardless of its symbolic type descriptor". > > So the VM should not be throwing an NSME here AFAICT. But, it looks like this case is being checked explicitly and an error is being thrown [5]: > > if (ak.at.isMonomorphicInReturnType) { > if (ak.at.returnType != mtype.returnType()) { > // The caller contains a different return type than that > // defined by the method > throw newNoSuchMethodErrorOnVarHandle(name, mtype); > } > // Adjust the return type of the signature method type > guardReturnType = ak.at.returnType; > } You are correct. A link-time NoSuchMethodError is not specified here. Rather, per the VarHandle javadoc, we should see a run-time WrongMethodTypeException. Bug report: https://bugs.openjdk.java.net/browse/JDK-8216520 This case probably hasn't gotten much attention because javac will never produce it. > imho the call should still succeed with `void` as a return type (discarding the value). For other types, it would be more consistent with the spec/doc if the return type was dynamically cast to that of the descriptor, with possible CCE, but linking still succeeded. Linking should succeed, but the run-time model these calls follow is 'invokeExact', not 'invoke': by design, they should fail immediately if there's a mismatch between expected and actual types, even if there's an easy adaptation (like dropping the result) from one to the other. ?Dan From john.r.rose at oracle.com Thu Jan 10 22:36:36 2019 From: john.r.rose at oracle.com (John Rose) Date: Thu, 10 Jan 2019 14:36:36 -0800 Subject: Resolution/translation of VarHandle.compareAndSet seems to conflict with JVMS/javadoc. In-Reply-To: References: Message-ID: <9E74C6D2-7564-481F-B731-D6DD60E02EE4@oracle.com> On Jan 10, 2019, at 12:36 PM, Dan Smith wrote: > > Bug report: > https://bugs.openjdk.java.net/browse/JDK-8216520 > > This case probably hasn't gotten much attention because javac will never produce it. > >> imho the call should still succeed with `void` as a return type (discarding the value). For other types, it would be more consistent with the spec/doc if the return type was dynamically cast to that of the descriptor, with possible CCE, but linking still succeeded. > > Linking should succeed, but the run-time model these calls follow is 'invokeExact', not 'invoke': by design, they should fail immediately if there's a mismatch between expected and actual types, even if there's an easy adaptation (like dropping the result) from one to the other. The JVMS mentions `invoke` as the immediate step taken by the JVM. This confused me greatly when I read it, since it seems to promise the sort of flexibility that is lacking here. The problem boils down to stacked MH invokers, one of which are exact, which makes the whole stack inflexible. I think the JVMS should be overhauled at this point. I made some notes to that effect on JDK-8216520. ? John From shade at redhat.com Mon Jan 14 10:33:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 14 Jan 2019 11:33:49 +0100 Subject: Submit repo task IDs In-Reply-To: <4ec1f9b1db850065a4076704cd7ebc0e5813c0a8.camel@redhat.com> References: <828c0281-174d-d2e9-7d69-0b099ed56428@redhat.com> <4ec1f9b1db850065a4076704cd7ebc0e5813c0a8.camel@redhat.com> Message-ID: On 1/9/19 4:32 PM, Severin Gehwolf wrote: > On Wed, 2019-01-09 at 15:29 +0100, Aleksey Shipilev wrote: >> Hi, >> >> Current submit repo job IDs are rather confusing. For example, for a >> given branch, I have got five IDs: >> >> [Mach5] mach5-one-shade-JDK-8215724-20190108-1643-17048: PASSED >> [Mach5] mach5-one-shade-JDK-8215724-20190108-2239-17125: PASSED >> [Mach5] mach5-one-shade-JDK-8215724-20190109-0216-17166: PASSED >> [Mach5] mach5-one-shade-JDK-8215724-20190109-0913-17241: PASSED >> [Mach5] mach5-one-shade-JDK-8215724-20190109-1210-17278: PASSED > > Not sure if that's related, but I've been getting nofications of > branches/bugs which no longer exist post-submit-repo-reset. The way to > stop them was closing the branch, but that's no longer possible after > the reset :-/ Not sure. Another relevant complaint: over the weekend, I have got 33 (!) PASSED notifications for the jobs that were submitted and completed last week. This really drops the signal-to-noise ratio from jdk-submit. At least put the mercurial ID into them, or even better provide the cause for the triggering! -Aleksey From magnus.ihse.bursie at oracle.com Mon Jan 14 13:52:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 Jan 2019 14:52:26 +0100 Subject: =?UTF-8?Q?Re=3a_Build_failure_=22/mnt/data/home/software/openjdk/sr?= =?UTF-8?Q?c/hotspot/share/gc/parallel/objectStartArray=2ecpp=3a106=3a56=3a_?= =?UTF-8?B?ZXJyb3I6IOKAmHZvaWQqIG1lbXNldCh2b2lkKiwgaW50LCBzaXplX3Qp4oCZIHdy?= =?UTF-8?Q?iting_to_an_object_of_type_=e2=80=98class_HeapWord=e2=80=99_with_?= =?UTF-8?B?4oCYcHJpdmF0ZeKAmSBtZW1iZXIg4oCYSGVhcFdvcmQ6OmnigJkgWy1XZXJyb3I9?= =?UTF-8?Q?class-memacc?= In-Reply-To: References: Message-ID: On 2018-12-31 23:15, Karl-Philipp Richter wrote: > Hi Andrew, > Thanks for your quick reply. > > Am 31.12.18 um 21:08 schrieb Andrew Luo: >> Can you run gcc --version and tell us the version of GCC that you are using? > My version is gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0. > >> I'm guessing this was added in a newer version of GCC (class-memaccess was added in GCC 8), and can probably be worked around using -Wno-error=class-memaccess. That's not saying I don't think we should fix this, just suggesting a workaround for now if you want to compile on GCC 8 before this is fixed. Although I believe that per the C++ standard you are allowed to memcpy/memset trivial classes (clang only warns on non-trivial classes: https://reviews.llvm.org/D45310) so GCC's warning seems to be a bit too broad. > `env MAKEFLAGS= bash ./configure > --with-extra-cflags=-Wno-error=class-memaccess > --with-extra-cxxflags=-Wno-error=class-memaccess && make` avoid the > build failure, however the build now fails because of > > ``` > /mnt/data/home/software/openjdk/src/java.base/unix/native/libjli/java_md_solinux.c: > In function ?ContinueInNewThread0?: > /mnt/data/home/software/openjdk/src/java.base/unix/native/libjli/java_md_solinux.c:747:37: > error: cast between incompatible function types from ?int (*)(void *)? > to ?void * (*)(void *)? [-Werror=cast-function-type] > if (pthread_create(&tid, &attr, (void *(*)(void*))continuation, > (void*)args) == 0) { > ^ > cc1: all warnings being treated as errors > make[3]: *** [CoreLibraries.gmk:212: > /mnt/data/home/software/openjdk/build/linux-x86_64-server-release/support/native/java.base/libjli/java_md_solinux.o] > Fehler 1 > make[3]: *** Auf noch nicht beendete Prozesse wird gewartet ? > make[2]: *** [make/Main.gmk:215: java.base-libs] Fehler 2 > > ERROR: Build failed for target 'default (exploded-image)' in > configuration 'linux-x86_64-server-release' (exit code 2) > ``` > > I agree that the issue should be fixed. > > Since Ubuntu is not among the least popular Linux distributions, I > recommend a review of your continuous integration system which might > need to include more systems. The setup on GitLab is an example to > perform these tests easily, but you probably already have already a CI > set up which you can extend. > > Since I don't need to build OpenJDK urgently, I'd rather see these build > issues detected and fixed by CI coverage of the build process than > stumbling from one to another - it's probably only these two, but afaik > that's a lot of a widely use operating system. The default behavior of the build system is to compile with warnings as errors. When your build fails, the very last message printed by the build system is: "Hint: See doc/building.html#troubleshooting for assistance." If you follow the instructions, you will find this paragraph: [1] "By default, the JDK has a strict approach where warnings from the compiler is considered errors which fail the build. For very new or very old compiler versions, this can trigger new classes of warnings, which thus fails the build. Run configure with --disable-warnings-as-errors to turn of this behavior. (The warnings will still show, but not make the build fail.)" Trying to build a system as complex as OpenJDK without reading the documentation is a very optimistic approach. /Magnus [1] http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html#troubleshooting > >> Are you interested in contributing a fix to this as well - if not I can work on this later this week as well. > I have not enough knowledge to provide a good fix. > >> (By the way, your link https://gitlab.com/krichter/openjdk/-/jobs/140219987 requires signing in). > My bad, fixed. > > -Kalle > From sean.coffey at oracle.com Tue Jan 15 18:57:00 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 15 Jan 2019 18:57:00 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: Note that the JDK 8u201/8u202 sources were pushed today and included the new jdk8uxxx-ga style mercurial tags for the first time. (Thanks Aleksei). This should be useful for frameworks in the future to help detect GA availability etc. regards, Sean. On 11/10/2018 18:54, Se?n Coffey wrote: > Thanks for the feedback to date. Given the support expressed for this > change, and the lack of objections, I'll propose the necessary jcheck > changes to the Code Tools Project. Once approved, I'll ask the Leads > of the relevant JDK Projects to begin using the new tag format each > time a JDK release achieves the GA milestone. > > regards, > Sean. > > On 03/10/2018 15:54, Se?n Coffey wrote: >> I'd like to propose an enhancement to the JDK build-tagging >> convention to help users more easily identify JDK GA releases >> via Mercurial tag names. >> >> The concept is quite simple and lets people identify snapshots >> of GA releases in Mercurial history without having to know the >> build number of the GA release. >> >> For example, to obtain JDK 10.0.2 GA sources today, one issues the >> `hg update -r jdk-10.0.2+13` command. With the proposed >> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >> It's proposed that the new ga tag would be in addition to the regular >> GA build number tag. It would be added to the relevant repository >> once the GA milestone has been reached. >> >> This new convention would be used for future JDK releases and is >> tracked via JDK-8180946[1]. If the changes are adopted, I can >> look at retroactively adding labels for all feature JDK GA releases >> since JDK 7 to the JDK feature-release main-line repository. >> >> To accommodate the new tag format, some simple jcheck edits >> would be required. Test checks would also be added. >> >> Comments? >> >> regards, >> Sean. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > From jesper.wilhelmsson at oracle.com Tue Jan 15 21:18:43 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 15 Jan 2019 22:18:43 +0100 Subject: RFR - JDK-8217167: ProblemList security tests until JDK-8216597 is fixed Message-ID: <74A36FD9-8110-4D29-B58B-6496305817B1@oracle.com> Hi, Please review this patch to problemlist 44 tests that has been failing in tier 4 for a few days now. Patch below. Bug: https://bugs.openjdk.java.net/browse/JDK-8217167 Thanks, /Jesper diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -691,6 +691,51 @@ sun/security/pkcs11/tls/TestPremaster.java 8204203 windows-all sun/security/tools/keytool/NssTest.java 8204203 windows-all +sun/security/tools/keytool/NssTest.java 8216597 solaris-all +sun/security/pkcs11/tls/TestMasterSecret.java 8216597 solaris-all +sun/security/pkcs11/tls/TestPRF.java 8216597 solaris-all +sun/security/pkcs11/tls/TestPremaster.java 8216597 solaris-all +sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java 8216597 solaris-all +sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8216597 solaris-all +sun/security/pkcs11/Signature/TestRSAKeyLength.java 8216597 solaris-all +sun/security/pkcs11/Signature/ReinitSignature.java 8216597 solaris-all +sun/security/pkcs11/Signature/TestDSA.java 8216597 solaris-all +sun/security/pkcs11/Signature/ByteBuffers.java 8216597 solaris-all +sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8216597 solaris-all +sun/security/pkcs11/Secmod/GetPrivateKey.java 8216597 solaris-all +sun/security/pkcs11/Secmod/Crypto.java 8216597 solaris-all +sun/security/pkcs11/rsa/TestCACerts.java 8216597 solaris-all +sun/security/pkcs11/rsa/TestKeyFactory.java 8216597 solaris-all +sun/security/pkcs11/Secmod/AddPrivateKey.java 8216597 solaris-all +sun/security/pkcs11/rsa/TestSignatures.java 8216597 solaris-all +sun/security/pkcs11/rsa/KeyWrap.java 8216597 solaris-all +sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8216597 solaris-all +sun/security/pkcs11/Mac/ReinitMac.java 8216597 solaris-all +sun/security/pkcs11/Mac/MacSameTest.java 8216597 solaris-all +sun/security/pkcs11/Mac/MacKAT.java 8216597 solaris-all +sun/security/pkcs11/KeyStore/Basic.sh 8216597 solaris-all +sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8216597 solaris-all +sun/security/pkcs11/KeyAgreement/TestInterop.java 8216597 solaris-all +sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8216597 solaris-all +sun/security/pkcs11/KeyAgreement/TestShort.java 8216597 solaris-all +sun/security/pkcs11/ec/TestECDSA2.java 8216597 solaris-all +sun/security/pkcs11/KeyAgreement/TestDH.java 8216597 solaris-all +sun/security/pkcs11/KeyGenerator/DESParity.java 8216597 solaris-all +sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8216597 solaris-all +sun/security/pkcs11/ec/TestECGenSpec.java 8216597 solaris-all +sun/security/pkcs11/ec/TestECDSA.java 8216597 solaris-all +sun/security/pkcs11/ec/TestECDH2.java 8216597 solaris-all +sun/security/pkcs11/ec/ReadPKCS12.java 8216597 solaris-all +sun/security/pkcs11/ec/TestCurves.java 8216597 solaris-all +sun/security/pkcs11/ec/ReadCertificates.java 8216597 solaris-all +sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8216597 solaris-all +sun/security/pkcs11/Cipher/TestRawRSACipher.java 8216597 solaris-all +sun/security/pkcs11/Cipher/TestSymmCiphers.java 8216597 solaris-all +sun/security/pkcs11/Cipher/TestRSACipher.java 8216597 solaris-all +sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8216597 solaris-all +sun/security/pkcs11/Cipher/ReinitCipher.java 8216597 solaris-all +sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8216597 solaris-all + ############################################################################ # jdk_sound From gnu.andrew at redhat.com Tue Jan 15 21:23:28 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 15 Jan 2019 21:23:28 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: On Tue, 15 Jan 2019 at 18:57, Se?n Coffey wrote: > > Note that the JDK 8u201/8u202 sources were pushed today and included the > new jdk8uxxx-ga style mercurial tags for the first time. (Thanks Aleksei). > > This should be useful for frameworks in the future to help detect GA > availability etc. > > regards, > Sean. > That does make things easier in deciding what tag is the final one, especially when we tend to get ones after GA (e.g. jdk8u192-b25, jdk8u201-b79). Following this CPU, I do have a request for another new tag. There seems to be no tag in the updates tree for when it is branched for the next release. A jdk8uxxx-rdp2/jdk-xx.0.x-rdp2 would be most welcome. I noticed with 11 this time, that I ended up having to manually apply a bunch of non-security fixes that were in the jdk-updates tree, but there was no way to pull them in through a defined tag. Having *-rdp2 as a base for applying CPU patches ahead of time would be helpful and ensure our final version is closer to what Oracle eventually push upstream. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sean.mullan at oracle.com Tue Jan 15 21:28:17 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jan 2019 16:28:17 -0500 Subject: RFR - JDK-8217167: ProblemList security tests until JDK-8216597 is fixed In-Reply-To: <74A36FD9-8110-4D29-B58B-6496305817B1@oracle.com> References: <74A36FD9-8110-4D29-B58B-6496305817B1@oracle.com> Message-ID: <671239af-6073-1463-bcdb-599a2a99c141@oracle.com> Martin should have a fix in for JDK-8217167 that should be pushed soon. I am just running a mach5 tier4 job for him with his patch because he doesn't have access to machines that reproduce the failures. So it is up to you if you want to wait, but he should be able to push this later today or early tomorrow assuming all goes well. --Sean On 1/15/19 4:18 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review this patch to problemlist 44 tests that has been failing in tier 4 for a few days now. Patch below. > Bug: https://bugs.openjdk.java.net/browse/JDK-8217167 > > Thanks, > /Jesper > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -691,6 +691,51 @@ > sun/security/pkcs11/tls/TestPremaster.java 8204203 windows-all > sun/security/tools/keytool/NssTest.java 8204203 windows-all > > +sun/security/tools/keytool/NssTest.java 8216597 solaris-all > +sun/security/pkcs11/tls/TestMasterSecret.java 8216597 solaris-all > +sun/security/pkcs11/tls/TestPRF.java 8216597 solaris-all > +sun/security/pkcs11/tls/TestPremaster.java 8216597 solaris-all > +sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java 8216597 solaris-all > +sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8216597 solaris-all > +sun/security/pkcs11/Signature/TestRSAKeyLength.java 8216597 solaris-all > +sun/security/pkcs11/Signature/ReinitSignature.java 8216597 solaris-all > +sun/security/pkcs11/Signature/TestDSA.java 8216597 solaris-all > +sun/security/pkcs11/Signature/ByteBuffers.java 8216597 solaris-all > +sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8216597 solaris-all > +sun/security/pkcs11/Secmod/GetPrivateKey.java 8216597 solaris-all > +sun/security/pkcs11/Secmod/Crypto.java 8216597 solaris-all > +sun/security/pkcs11/rsa/TestCACerts.java 8216597 solaris-all > +sun/security/pkcs11/rsa/TestKeyFactory.java 8216597 solaris-all > +sun/security/pkcs11/Secmod/AddPrivateKey.java 8216597 solaris-all > +sun/security/pkcs11/rsa/TestSignatures.java 8216597 solaris-all > +sun/security/pkcs11/rsa/KeyWrap.java 8216597 solaris-all > +sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8216597 solaris-all > +sun/security/pkcs11/Mac/ReinitMac.java 8216597 solaris-all > +sun/security/pkcs11/Mac/MacSameTest.java 8216597 solaris-all > +sun/security/pkcs11/Mac/MacKAT.java 8216597 solaris-all > +sun/security/pkcs11/KeyStore/Basic.sh 8216597 solaris-all > +sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8216597 solaris-all > +sun/security/pkcs11/KeyAgreement/TestInterop.java 8216597 solaris-all > +sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8216597 solaris-all > +sun/security/pkcs11/KeyAgreement/TestShort.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestECDSA2.java 8216597 solaris-all > +sun/security/pkcs11/KeyAgreement/TestDH.java 8216597 solaris-all > +sun/security/pkcs11/KeyGenerator/DESParity.java 8216597 solaris-all > +sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestECGenSpec.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestECDSA.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestECDH2.java 8216597 solaris-all > +sun/security/pkcs11/ec/ReadPKCS12.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestCurves.java 8216597 solaris-all > +sun/security/pkcs11/ec/ReadCertificates.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestRawRSACipher.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestSymmCiphers.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestRSACipher.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/ReinitCipher.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8216597 solaris-all > + > ############################################################################ > > # jdk_sound > > From david.holmes at oracle.com Tue Jan 15 21:31:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Jan 2019 07:31:08 +1000 Subject: RFR - JDK-8217167: ProblemList security tests until JDK-8216597 is fixed In-Reply-To: <74A36FD9-8110-4D29-B58B-6496305817B1@oracle.com> References: <74A36FD9-8110-4D29-B58B-6496305817B1@oracle.com> Message-ID: Hi Jesper, The security-dev folk are currently reviewing a simple patch that disables the functionality that is causing the problem. It's undergoing testing now to ensure the problem is avoided. http://mail.openjdk.java.net/pipermail/security-dev/2019-January/019168.html I've no idea how long this may still take to push due to timezones. If you still want to ProblemList the tests then consider it Reviewed. Thanks, David On 16/01/2019 7:18 am, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review this patch to problemlist 44 tests that has been failing in tier 4 for a few days now. Patch below. > Bug: https://bugs.openjdk.java.net/browse/JDK-8217167 > > Thanks, > /Jesper > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -691,6 +691,51 @@ > sun/security/pkcs11/tls/TestPremaster.java 8204203 windows-all > sun/security/tools/keytool/NssTest.java 8204203 windows-all > > +sun/security/tools/keytool/NssTest.java 8216597 solaris-all > +sun/security/pkcs11/tls/TestMasterSecret.java 8216597 solaris-all > +sun/security/pkcs11/tls/TestPRF.java 8216597 solaris-all > +sun/security/pkcs11/tls/TestPremaster.java 8216597 solaris-all > +sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java 8216597 solaris-all > +sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8216597 solaris-all > +sun/security/pkcs11/Signature/TestRSAKeyLength.java 8216597 solaris-all > +sun/security/pkcs11/Signature/ReinitSignature.java 8216597 solaris-all > +sun/security/pkcs11/Signature/TestDSA.java 8216597 solaris-all > +sun/security/pkcs11/Signature/ByteBuffers.java 8216597 solaris-all > +sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8216597 solaris-all > +sun/security/pkcs11/Secmod/GetPrivateKey.java 8216597 solaris-all > +sun/security/pkcs11/Secmod/Crypto.java 8216597 solaris-all > +sun/security/pkcs11/rsa/TestCACerts.java 8216597 solaris-all > +sun/security/pkcs11/rsa/TestKeyFactory.java 8216597 solaris-all > +sun/security/pkcs11/Secmod/AddPrivateKey.java 8216597 solaris-all > +sun/security/pkcs11/rsa/TestSignatures.java 8216597 solaris-all > +sun/security/pkcs11/rsa/KeyWrap.java 8216597 solaris-all > +sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8216597 solaris-all > +sun/security/pkcs11/Mac/ReinitMac.java 8216597 solaris-all > +sun/security/pkcs11/Mac/MacSameTest.java 8216597 solaris-all > +sun/security/pkcs11/Mac/MacKAT.java 8216597 solaris-all > +sun/security/pkcs11/KeyStore/Basic.sh 8216597 solaris-all > +sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8216597 solaris-all > +sun/security/pkcs11/KeyAgreement/TestInterop.java 8216597 solaris-all > +sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8216597 solaris-all > +sun/security/pkcs11/KeyAgreement/TestShort.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestECDSA2.java 8216597 solaris-all > +sun/security/pkcs11/KeyAgreement/TestDH.java 8216597 solaris-all > +sun/security/pkcs11/KeyGenerator/DESParity.java 8216597 solaris-all > +sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestECGenSpec.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestECDSA.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestECDH2.java 8216597 solaris-all > +sun/security/pkcs11/ec/ReadPKCS12.java 8216597 solaris-all > +sun/security/pkcs11/ec/TestCurves.java 8216597 solaris-all > +sun/security/pkcs11/ec/ReadCertificates.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestRawRSACipher.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestSymmCiphers.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestRSACipher.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/ReinitCipher.java 8216597 solaris-all > +sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8216597 solaris-all > + > ############################################################################ > > # jdk_sound > > From jesper.wilhelmsson at oracle.com Tue Jan 15 21:50:59 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 15 Jan 2019 22:50:59 +0100 Subject: RFR - JDK-8217167: ProblemList security tests until JDK-8216597 is fixed In-Reply-To: References: <74A36FD9-8110-4D29-B58B-6496305817B1@oracle.com> Message-ID: Sean, David, Thanks for the review! I'll delay pushing this until tomorrow. Thanks, /Jesper > On 15 Jan 2019, at 22:28, Sean Mullan wrote: > > Martin should have a fix in for JDK-8217167 that should be pushed soon. I am just running a mach5 tier4 job for him with his patch because he doesn't have access to machines that reproduce the failures. So it is up to you if you want to wait, but he should be able to push this later today or early tomorrow assuming all goes well. > > --Sean > On 15 Jan 2019, at 22:31, David Holmes wrote: > > Hi Jesper, > > The security-dev folk are currently reviewing a simple patch that disables the functionality that is causing the problem. It's undergoing testing now to ensure the problem is avoided. > > http://mail.openjdk.java.net/pipermail/security-dev/2019-January/019168.html > > I've no idea how long this may still take to push due to timezones. > > If you still want to ProblemList the tests then consider it Reviewed. > > Thanks, > David > > On 16/01/2019 7:18 am, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> Please review this patch to problemlist 44 tests that has been failing in tier 4 for a few days now. Patch below. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217167 >> Thanks, >> /Jesper >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -691,6 +691,51 @@ >> sun/security/pkcs11/tls/TestPremaster.java 8204203 windows-all >> sun/security/tools/keytool/NssTest.java 8204203 windows-all >> +sun/security/tools/keytool/NssTest.java 8216597 solaris-all >> +sun/security/pkcs11/tls/TestMasterSecret.java 8216597 solaris-all >> +sun/security/pkcs11/tls/TestPRF.java 8216597 solaris-all >> +sun/security/pkcs11/tls/TestPremaster.java 8216597 solaris-all >> +sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java 8216597 solaris-all >> +sun/security/pkcs11/tls/TestLeadingZeroesP11.java 8216597 solaris-all >> +sun/security/pkcs11/Signature/TestRSAKeyLength.java 8216597 solaris-all >> +sun/security/pkcs11/Signature/ReinitSignature.java 8216597 solaris-all >> +sun/security/pkcs11/Signature/TestDSA.java 8216597 solaris-all >> +sun/security/pkcs11/Signature/ByteBuffers.java 8216597 solaris-all >> +sun/security/pkcs11/Secmod/TestNssDbSqlite.java 8216597 solaris-all >> +sun/security/pkcs11/Secmod/GetPrivateKey.java 8216597 solaris-all >> +sun/security/pkcs11/Secmod/Crypto.java 8216597 solaris-all >> +sun/security/pkcs11/rsa/TestCACerts.java 8216597 solaris-all >> +sun/security/pkcs11/rsa/TestKeyFactory.java 8216597 solaris-all >> +sun/security/pkcs11/Secmod/AddPrivateKey.java 8216597 solaris-all >> +sun/security/pkcs11/rsa/TestSignatures.java 8216597 solaris-all >> +sun/security/pkcs11/rsa/KeyWrap.java 8216597 solaris-all >> +sun/security/pkcs11/rsa/TestKeyPairGenerator.java 8216597 solaris-all >> +sun/security/pkcs11/Mac/ReinitMac.java 8216597 solaris-all >> +sun/security/pkcs11/Mac/MacSameTest.java 8216597 solaris-all >> +sun/security/pkcs11/Mac/MacKAT.java 8216597 solaris-all >> +sun/security/pkcs11/KeyStore/Basic.sh 8216597 solaris-all >> +sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java 8216597 solaris-all >> +sun/security/pkcs11/KeyAgreement/TestInterop.java 8216597 solaris-all >> +sun/security/pkcs11/KeyPairGenerator/TestDH2048.java 8216597 solaris-all >> +sun/security/pkcs11/KeyAgreement/TestShort.java 8216597 solaris-all >> +sun/security/pkcs11/ec/TestECDSA2.java 8216597 solaris-all >> +sun/security/pkcs11/KeyAgreement/TestDH.java 8216597 solaris-all >> +sun/security/pkcs11/KeyGenerator/DESParity.java 8216597 solaris-all >> +sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java 8216597 solaris-all >> +sun/security/pkcs11/ec/TestECGenSpec.java 8216597 solaris-all >> +sun/security/pkcs11/ec/TestECDSA.java 8216597 solaris-all >> +sun/security/pkcs11/ec/TestECDH2.java 8216597 solaris-all >> +sun/security/pkcs11/ec/ReadPKCS12.java 8216597 solaris-all >> +sun/security/pkcs11/ec/TestCurves.java 8216597 solaris-all >> +sun/security/pkcs11/ec/ReadCertificates.java 8216597 solaris-all >> +sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java 8216597 solaris-all >> +sun/security/pkcs11/Cipher/TestRawRSACipher.java 8216597 solaris-all >> +sun/security/pkcs11/Cipher/TestSymmCiphers.java 8216597 solaris-all >> +sun/security/pkcs11/Cipher/TestRSACipher.java 8216597 solaris-all >> +sun/security/pkcs11/Cipher/TestRSACipherWrap.java 8216597 solaris-all >> +sun/security/pkcs11/Cipher/ReinitCipher.java 8216597 solaris-all >> +sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java 8216597 solaris-all >> + >> ############################################################################ >> # jdk_sound From volker.simonis at gmail.com Wed Jan 16 08:05:41 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 16 Jan 2019 09:05:41 +0100 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: On Tue, Jan 15, 2019 at 10:23 PM Andrew Hughes wrote: > > On Tue, 15 Jan 2019 at 18:57, Se?n Coffey wrote: > > > > Note that the JDK 8u201/8u202 sources were pushed today and included the > > new jdk8uxxx-ga style mercurial tags for the first time. (Thanks Aleksei). > > > > This should be useful for frameworks in the future to help detect GA > > availability etc. > > > > regards, > > Sean. > > > > That does make things easier in deciding what tag is the final one, especially > when we tend to get ones after GA (e.g. jdk8u192-b25, jdk8u201-b79). > > Following this CPU, I do have a request for another new tag. There seems to be > no tag in the updates tree for when it is branched for the next release. A > jdk8uxxx-rdp2/jdk-xx.0.x-rdp2 would be most welcome. I noticed with 11 this > time, that I ended up having to manually apply a bunch of non-security fixes > that were in the jdk-updates tree, but there was no way to pull them in > through a defined tag. Having *-rdp2 as a base for applying CPU patches > ahead of time would be helpful and ensure our final version is closer to > what Oracle eventually push upstream. +1 > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From philip.m.jones at siemens.com Wed Jan 16 11:21:40 2019 From: philip.m.jones at siemens.com (Jones, Philip) Date: Wed, 16 Jan 2019 11:21:40 +0000 Subject: odd JAVA_VERSION_DATE for 11.0.2 Message-ID: <3C3FEEEFE127B940BB0F5FADB2806041284F024B@DEKOMMBX001.net.plm.eds.com> Hi Can someone explain why JAVA_VERSION_DATE for 11.0.2 is the exact same as it is for 11.0.1? It changed form 10.0.1 to 10.0.2. C:\root\OpenJDK\OpenJDK\Installs>jdk-10.0.1\bin\java --version openjdk 10.0.1 2018-04-17 OpenJDK Runtime Environment (build 10.0.1+10) OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode) C:\root\OpenJDK\OpenJDK\Installs>jdk-10.0.2\bin\java --version openjdk 10.0.2 2018-07-17 OpenJDK Runtime Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) C:\root\OpenJDK\OpenJDK\Installs>jdk-11.0.1\bin\java --version openjdk 11.0.1 2018-10-16 OpenJDK Runtime Environment 18.9 (build 11.0.1+13) OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode) C:\root\OpenJDK\OpenJDK\Installs>jdk-11.0.2\bin\java --version openjdk 11.0.2 2018-10-16 OpenJDK Runtime Environment 18.9 (build 11.0.2+7) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+7, mixed mode) ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. From sean.coffey at oracle.com Wed Jan 16 12:09:57 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 16 Jan 2019 12:09:57 +0000 Subject: odd JAVA_VERSION_DATE for 11.0.2 In-Reply-To: <3C3FEEEFE127B940BB0F5FADB2806041284F024B@DEKOMMBX001.net.plm.eds.com> References: <3C3FEEEFE127B940BB0F5FADB2806041284F024B@DEKOMMBX001.net.plm.eds.com> Message-ID: <78ae2e90-564a-7cc5-27c6-d1574bcaf435@oracle.com> Looks like a bug. Probably a discussion for the jdk-updates-dev mailing list in any case. Best to log a bug to record this at bugs.java.com Regards, Sean. On 16/01/19 11:21, Jones, Philip wrote: > Hi > > Can someone explain why JAVA_VERSION_DATE for 11.0.2 is the exact same as it is for 11.0.1? It changed form 10.0.1 to 10.0.2. > > > C:\root\OpenJDK\OpenJDK\Installs>jdk-10.0.1\bin\java --version > openjdk 10.0.1 2018-04-17 > OpenJDK Runtime Environment (build 10.0.1+10) > OpenJDK 64-Bit Server VM (build 10.0.1+10, mixed mode) > > C:\root\OpenJDK\OpenJDK\Installs>jdk-10.0.2\bin\java --version > openjdk 10.0.2 2018-07-17 > OpenJDK Runtime Environment 18.3 (build 10.0.2+13) > OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode) > > C:\root\OpenJDK\OpenJDK\Installs>jdk-11.0.1\bin\java --version > openjdk 11.0.1 2018-10-16 > OpenJDK Runtime Environment 18.9 (build 11.0.1+13) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode) > > C:\root\OpenJDK\OpenJDK\Installs>jdk-11.0.2\bin\java --version > openjdk 11.0.2 2018-10-16 > OpenJDK Runtime Environment 18.9 (build 11.0.2+7) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+7, mixed mode) > > ----------------- > Siemens Industry Software Limited is a limited company registered in England and Wales. > Registered number: 3476850. > Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. From martinrb at google.com Wed Jan 16 13:58:04 2019 From: martinrb at google.com (Martin Buchholz) Date: Wed, 16 Jan 2019 05:58:04 -0800 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: On Tue, Jan 15, 2019 at 10:57 AM Se?n Coffey wrote: > Note that the JDK 8u201/8u202 sources were pushed today and included the > new jdk8uxxx-ga style mercurial tags for the first time. (Thanks Aleksei). > > I like the -ga tags ... so much ... that I'd like to see them applied retroactively to all the repos/forests containing release source for the past 10 years. jdk binaries have contained mercurial changeset identifiers in the release file, so reconstructing the history should be straightforward (if tedious). > This should be useful for frameworks in the future to help detect GA > availability etc. > I'm thinking ... software paleo-entomologists From sean.coffey at oracle.com Wed Jan 16 14:42:00 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 16 Jan 2019 14:42:00 +0000 Subject: Tagging proposal for JDK GA releases (JDK-8217256) In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: Looks like a good suggestion. I've logged JDK-8217256 to track this. Regards, Sean. On 15/01/19 21:23, Andrew Hughes wrote: > On Tue, 15 Jan 2019 at 18:57, Se?n Coffey wrote: >> Note that the JDK 8u201/8u202 sources were pushed today and included the >> new jdk8uxxx-ga style mercurial tags for the first time. (Thanks Aleksei). >> >> This should be useful for frameworks in the future to help detect GA >> availability etc. >> >> regards, >> Sean. >> > That does make things easier in deciding what tag is the final one, especially > when we tend to get ones after GA (e.g. jdk8u192-b25, jdk8u201-b79). > > Following this CPU, I do have a request for another new tag. There seems to be > no tag in the updates tree for when it is branched for the next release. A > jdk8uxxx-rdp2/jdk-xx.0.x-rdp2 would be most welcome. I noticed with 11 this > time, that I ended up having to manually apply a bunch of non-security fixes > that were in the jdk-updates tree, but there was no way to pull them in > through a defined tag. Having *-rdp2 as a base for applying CPU patches > ahead of time would be helpful and ensure our final version is closer to > what Oracle eventually push upstream. > > Thanks, From sean.coffey at oracle.com Wed Jan 16 14:41:09 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 16 Jan 2019 14:41:09 +0000 Subject: Tagging proposal for JDK GA releases (JDK-8217255) In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: Something I've been meaning to look at. I've logged JDK-8217255 to track this. Regards, Sean. On 16/01/19 13:58, Martin Buchholz wrote: > > > On Tue, Jan 15, 2019 at 10:57 AM Se?n Coffey > wrote: > > Note that the JDK 8u201/8u202 sources were pushed today and > included the > new jdk8uxxx-ga style mercurial tags for the first time. (Thanks > Aleksei). > > > I like the -ga tags ... so much ... that I'd like to see them applied > retroactively to all the repos/forests containing release source for > the past 10 years. > jdk binaries have contained mercurial changeset identifiers in the > release file, so reconstructing the history should be straightforward > (if tedious). > > This should be useful for frameworks in the future to help detect GA > availability etc. > > > I'm thinking ... software paleo-entomologists From dennis at gesker.com Wed Jan 16 18:01:29 2019 From: dennis at gesker.com (Dennis Gesker) Date: Wed, 16 Jan 2019 11:01:29 -0700 Subject: JDK-8215102 Message-ID: Just curious if this item was actually fixed or just marked as fixed when a request for more information was made and the reported did not seem to submit the stack trace. I'm seeing the same behavior on JDK 11: openjdk version "11.0.1" 2018-10-16 OpenJDK Runtime Environment (build 11.0.1+13-Ubuntu-2ubuntu1) OpenJDK 64-Bit Server VM (build 11.0.1+13-Ubuntu-2ubuntu1, mixed mode, sharing) After having installed the MySqlDriver for use by a datasource in WildFly. Stacktrace below... 10:19:56,072 ERROR [stderr] (IdleRemover) Wed Jan 16 10:19:56 MST 2019 WARN: Caught while disconnecting... 10:19:56,072 ERROR [stderr] (IdleRemover) 10:19:56,072 ERROR [stderr] (IdleRemover) EXCEPTION STACK TRACE: 10:19:56,073 ERROR [stderr] (IdleRemover) 10:19:56,073 ERROR [stderr] (IdleRemover) 10:19:56,073 ERROR [stderr] (IdleRemover) 10:19:56,073 ERROR [stderr] (IdleRemover) ** BEGIN NESTED EXCEPTION ** 10:19:56,073 ERROR [stderr] (IdleRemover) 10:19:56,073 ERROR [stderr] (IdleRemover) javax.net.ssl.SSLException 10:19:56,074 ERROR [stderr] (IdleRemover) MESSAGE: closing inbound before receiving peer's close_notify 10:19:56,074 ERROR [stderr] (IdleRemover) 10:19:56,074 ERROR [stderr] (IdleRemover) STACKTRACE: 10:19:56,074 ERROR [stderr] (IdleRemover) 10:19:56,074 ERROR [stderr] (IdleRemover) javax.net.ssl.SSLException: closing inbound before receiving peer's close_notify 10:19:56,075 ERROR [stderr] (IdleRemover) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) 10:19:56,075 ERROR [stderr] (IdleRemover) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) 10:19:56,075 ERROR [stderr] (IdleRemover) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) 10:19:56,075 ERROR [stderr] (IdleRemover) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) 10:19:56,076 ERROR [stderr] (IdleRemover) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) 10:19:56,076 ERROR [stderr] (IdleRemover) at java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:645) 10:19:56,076 ERROR [stderr] (IdleRemover) at java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:624) 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 //com.mysql.cj.protocol.a.NativeProtocol.quit(NativeProtocol.java:1312) 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 //com.mysql.cj.NativeSession.quit(NativeSession.java:182) 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 //com.mysql.cj.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:1750) 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 //com.mysql.cj.jdbc.ConnectionImpl.close(ConnectionImpl.java:720) 10:19:56,076 ERROR [stderr] (IdleRemover) at org.jboss.ironjacamar.jdbcadapters at 1.4.11.Final //org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.destroy(BaseWrapperManagedConnection.java:491) 10:19:56,077 ERROR [stderr] (IdleRemover) at org.jboss.ironjacamar.impl at 1.4.11.Final //org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.destroy(AbstractConnectionListener.java:637) 10:19:56,078 ERROR [stderr] (IdleRemover) at org.jboss.ironjacamar.impl at 1.4.11.Final //org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1006) 10:19:56,078 ERROR [stderr] (IdleRemover) at org.jboss.ironjacamar.impl at 1.4.11.Final //org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275) 10:19:56,078 ERROR [stderr] (IdleRemover) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) 10:19:56,078 ERROR [stderr] (IdleRemover) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) 10:19:56,078 ERROR [stderr] (IdleRemover) at java.base/java.lang.Thread.run(Thread.java:834) 10:19:56,078 ERROR [stderr] (IdleRemover) 10:19:56,078 ERROR [stderr] (IdleRemover) 10:19:56,078 ERROR [stderr] (IdleRemover) ** END NESTED EXCEPTION ** From Alan.Bateman at oracle.com Wed Jan 16 18:07:24 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2019 18:07:24 +0000 Subject: JDK-8215102 In-Reply-To: References: Message-ID: Can you run with -Djavax.net.debug=all and bring the traces to security-dev for discussion? -Alan On 16/01/2019 18:01, Dennis Gesker wrote: > Just curious if this item was actually fixed or just marked as fixed when a > request for more information was made and the reported did not seem to > submit the stack trace. > > I'm seeing the same behavior on JDK 11: > > openjdk version "11.0.1" 2018-10-16 > OpenJDK Runtime Environment (build 11.0.1+13-Ubuntu-2ubuntu1) > OpenJDK 64-Bit Server VM (build 11.0.1+13-Ubuntu-2ubuntu1, mixed mode, > sharing) > > > After having installed the MySqlDriver for use by a datasource in WildFly. > > Stacktrace below... > > 10:19:56,072 ERROR [stderr] (IdleRemover) Wed Jan 16 10:19:56 MST 2019 > WARN: Caught while disconnecting... > 10:19:56,072 ERROR [stderr] (IdleRemover) > 10:19:56,072 ERROR [stderr] (IdleRemover) EXCEPTION STACK TRACE: > 10:19:56,073 ERROR [stderr] (IdleRemover) > 10:19:56,073 ERROR [stderr] (IdleRemover) > 10:19:56,073 ERROR [stderr] (IdleRemover) > 10:19:56,073 ERROR [stderr] (IdleRemover) ** BEGIN NESTED EXCEPTION ** > 10:19:56,073 ERROR [stderr] (IdleRemover) > 10:19:56,073 ERROR [stderr] (IdleRemover) javax.net.ssl.SSLException > 10:19:56,074 ERROR [stderr] (IdleRemover) MESSAGE: closing inbound before > receiving peer's close_notify > 10:19:56,074 ERROR [stderr] (IdleRemover) > 10:19:56,074 ERROR [stderr] (IdleRemover) STACKTRACE: > 10:19:56,074 ERROR [stderr] (IdleRemover) > 10:19:56,074 ERROR [stderr] (IdleRemover) javax.net.ssl.SSLException: > closing inbound before receiving peer's close_notify > 10:19:56,075 ERROR [stderr] (IdleRemover) at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > 10:19:56,075 ERROR [stderr] (IdleRemover) at > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > 10:19:56,075 ERROR [stderr] (IdleRemover) at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > 10:19:56,075 ERROR [stderr] (IdleRemover) at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > 10:19:56,076 ERROR [stderr] (IdleRemover) at > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) > 10:19:56,076 ERROR [stderr] (IdleRemover) at > java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:645) > 10:19:56,076 ERROR [stderr] (IdleRemover) at > java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:624) > 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 > //com.mysql.cj.protocol.a.NativeProtocol.quit(NativeProtocol.java:1312) > 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 > //com.mysql.cj.NativeSession.quit(NativeSession.java:182) > 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 > //com.mysql.cj.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:1750) > 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 > //com.mysql.cj.jdbc.ConnectionImpl.close(ConnectionImpl.java:720) > 10:19:56,076 ERROR [stderr] (IdleRemover) at > org.jboss.ironjacamar.jdbcadapters at 1.4.11.Final > //org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.destroy(BaseWrapperManagedConnection.java:491) > 10:19:56,077 ERROR [stderr] (IdleRemover) at > org.jboss.ironjacamar.impl at 1.4.11.Final > //org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.destroy(AbstractConnectionListener.java:637) > 10:19:56,078 ERROR [stderr] (IdleRemover) at > org.jboss.ironjacamar.impl at 1.4.11.Final > //org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1006) > 10:19:56,078 ERROR [stderr] (IdleRemover) at > org.jboss.ironjacamar.impl at 1.4.11.Final > //org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275) > 10:19:56,078 ERROR [stderr] (IdleRemover) at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > 10:19:56,078 ERROR [stderr] (IdleRemover) at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > 10:19:56,078 ERROR [stderr] (IdleRemover) at > java.base/java.lang.Thread.run(Thread.java:834) > 10:19:56,078 ERROR [stderr] (IdleRemover) > 10:19:56,078 ERROR [stderr] (IdleRemover) > 10:19:56,078 ERROR [stderr] (IdleRemover) ** END NESTED EXCEPTION ** From kevin.rushforth at oracle.com Wed Jan 16 18:20:04 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Jan 2019 10:20:04 -0800 Subject: JDK-8215102 In-Reply-To: References: Message-ID: <5bccaa41-3f71-91d4-fdd2-22585c5eadea@oracle.com> FWIW, it does look like the bug was mistakenly closed as "Fixed", when it should have been closed as "Incomplete" based on the comment. -- Kevin On 1/16/2019 10:07 AM, Alan Bateman wrote: > Can you run with -Djavax.net.debug=all and bring the traces to > security-dev for discussion? > > -Alan > > On 16/01/2019 18:01, Dennis Gesker wrote: >> Just curious if this item was actually fixed or just marked as fixed >> when a >> request for more information was made and the reported did not seem to >> submit the stack trace. >> >> I'm seeing the same behavior on JDK 11: >> >> openjdk version "11.0.1" 2018-10-16 >> OpenJDK Runtime Environment (build 11.0.1+13-Ubuntu-2ubuntu1) >> OpenJDK 64-Bit Server VM (build 11.0.1+13-Ubuntu-2ubuntu1, mixed mode, >> sharing) >> >> >> After having installed the MySqlDriver for use by a datasource in >> WildFly. >> >> Stacktrace below... >> >> 10:19:56,072 ERROR [stderr] (IdleRemover) Wed Jan 16 10:19:56 MST 2019 >> WARN: Caught while disconnecting... >> 10:19:56,072 ERROR [stderr] (IdleRemover) >> 10:19:56,072 ERROR [stderr] (IdleRemover) EXCEPTION STACK TRACE: >> 10:19:56,073 ERROR [stderr] (IdleRemover) >> 10:19:56,073 ERROR [stderr] (IdleRemover) >> 10:19:56,073 ERROR [stderr] (IdleRemover) >> 10:19:56,073 ERROR [stderr] (IdleRemover) ** BEGIN NESTED EXCEPTION ** >> 10:19:56,073 ERROR [stderr] (IdleRemover) >> 10:19:56,073 ERROR [stderr] (IdleRemover) javax.net.ssl.SSLException >> 10:19:56,074 ERROR [stderr] (IdleRemover) MESSAGE: closing inbound >> before >> receiving peer's close_notify >> 10:19:56,074 ERROR [stderr] (IdleRemover) >> 10:19:56,074 ERROR [stderr] (IdleRemover) STACKTRACE: >> 10:19:56,074 ERROR [stderr] (IdleRemover) >> 10:19:56,074 ERROR [stderr] (IdleRemover) javax.net.ssl.SSLException: >> closing inbound before receiving peer's close_notify >> 10:19:56,075 ERROR [stderr] (IdleRemover)?????? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) >> 10:19:56,075 ERROR [stderr] (IdleRemover)?????? at >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) >> 10:19:56,075 ERROR [stderr] (IdleRemover)?????? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) >> >> 10:19:56,075 ERROR [stderr] (IdleRemover)?????? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) >> >> 10:19:56,076 ERROR [stderr] (IdleRemover)?????? at >> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) >> >> 10:19:56,076 ERROR [stderr] (IdleRemover)?????? at >> java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:645) >> >> 10:19:56,076 ERROR [stderr] (IdleRemover)?????? at >> java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:624) >> >> 10:19:56,076 ERROR [stderr] (IdleRemover)?????? at com.mysql at 8.0.13 >> //com.mysql.cj.protocol.a.NativeProtocol.quit(NativeProtocol.java:1312) >> 10:19:56,076 ERROR [stderr] (IdleRemover)?????? at com.mysql at 8.0.13 >> //com.mysql.cj.NativeSession.quit(NativeSession.java:182) >> 10:19:56,076 ERROR [stderr] (IdleRemover)?????? at com.mysql at 8.0.13 >> //com.mysql.cj.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:1750) >> 10:19:56,076 ERROR [stderr] (IdleRemover)?????? at com.mysql at 8.0.13 >> //com.mysql.cj.jdbc.ConnectionImpl.close(ConnectionImpl.java:720) >> 10:19:56,076 ERROR [stderr] (IdleRemover)?????? at >> org.jboss.ironjacamar.jdbcadapters at 1.4.11.Final >> //org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.destroy(BaseWrapperManagedConnection.java:491) >> >> 10:19:56,077 ERROR [stderr] (IdleRemover)?????? at >> org.jboss.ironjacamar.impl at 1.4.11.Final >> //org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.destroy(AbstractConnectionListener.java:637) >> >> 10:19:56,078 ERROR [stderr] (IdleRemover)?????? at >> org.jboss.ironjacamar.impl at 1.4.11.Final >> //org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1006) >> >> 10:19:56,078 ERROR [stderr] (IdleRemover)?????? at >> org.jboss.ironjacamar.impl at 1.4.11.Final >> //org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275) >> >> 10:19:56,078 ERROR [stderr] (IdleRemover)?????? at >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> >> 10:19:56,078 ERROR [stderr] (IdleRemover)?????? at >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> >> 10:19:56,078 ERROR [stderr] (IdleRemover)?????? at >> java.base/java.lang.Thread.run(Thread.java:834) >> 10:19:56,078 ERROR [stderr] (IdleRemover) >> 10:19:56,078 ERROR [stderr] (IdleRemover) >> 10:19:56,078 ERROR [stderr] (IdleRemover) ** END NESTED EXCEPTION ** > From dennis at gesker.com Thu Jan 17 16:47:58 2019 From: dennis at gesker.com (Dennis Gesker) Date: Thu, 17 Jan 2019 09:47:58 -0700 Subject: JDK-8215102 In-Reply-To: References: Message-ID: Good morning, Alan. I have a trace for you. I will join the security-dev list and post it there. --drg On Wed, Jan 16, 2019 at 11:07 AM Alan Bateman wrote: > Can you run with -Djavax.net.debug=all and bring the traces to > security-dev for discussion? > > -Alan > > On 16/01/2019 18:01, Dennis Gesker wrote: > > Just curious if this item was actually fixed or just marked as fixed > when a > > request for more information was made and the reported did not seem to > > submit the stack trace. > > > > I'm seeing the same behavior on JDK 11: > > > > openjdk version "11.0.1" 2018-10-16 > > OpenJDK Runtime Environment (build 11.0.1+13-Ubuntu-2ubuntu1) > > OpenJDK 64-Bit Server VM (build 11.0.1+13-Ubuntu-2ubuntu1, mixed mode, > > sharing) > > > > > > After having installed the MySqlDriver for use by a datasource in > WildFly. > > > > Stacktrace below... > > > > 10:19:56,072 ERROR [stderr] (IdleRemover) Wed Jan 16 10:19:56 MST 2019 > > WARN: Caught while disconnecting... > > 10:19:56,072 ERROR [stderr] (IdleRemover) > > 10:19:56,072 ERROR [stderr] (IdleRemover) EXCEPTION STACK TRACE: > > 10:19:56,073 ERROR [stderr] (IdleRemover) > > 10:19:56,073 ERROR [stderr] (IdleRemover) > > 10:19:56,073 ERROR [stderr] (IdleRemover) > > 10:19:56,073 ERROR [stderr] (IdleRemover) ** BEGIN NESTED EXCEPTION ** > > 10:19:56,073 ERROR [stderr] (IdleRemover) > > 10:19:56,073 ERROR [stderr] (IdleRemover) javax.net.ssl.SSLException > > 10:19:56,074 ERROR [stderr] (IdleRemover) MESSAGE: closing inbound before > > receiving peer's close_notify > > 10:19:56,074 ERROR [stderr] (IdleRemover) > > 10:19:56,074 ERROR [stderr] (IdleRemover) STACKTRACE: > > 10:19:56,074 ERROR [stderr] (IdleRemover) > > 10:19:56,074 ERROR [stderr] (IdleRemover) javax.net.ssl.SSLException: > > closing inbound before receiving peer's close_notify > > 10:19:56,075 ERROR [stderr] (IdleRemover) at > > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:129) > > 10:19:56,075 ERROR [stderr] (IdleRemover) at > > java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) > > 10:19:56,075 ERROR [stderr] (IdleRemover) at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) > > 10:19:56,075 ERROR [stderr] (IdleRemover) at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264) > > 10:19:56,076 ERROR [stderr] (IdleRemover) at > > > java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255) > > 10:19:56,076 ERROR [stderr] (IdleRemover) at > > > java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:645) > > 10:19:56,076 ERROR [stderr] (IdleRemover) at > > > java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:624) > > 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 > > //com.mysql.cj.protocol.a.NativeProtocol.quit(NativeProtocol.java:1312) > > 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 > > //com.mysql.cj.NativeSession.quit(NativeSession.java:182) > > 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 > > //com.mysql.cj.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:1750) > > 10:19:56,076 ERROR [stderr] (IdleRemover) at com.mysql at 8.0.13 > > //com.mysql.cj.jdbc.ConnectionImpl.close(ConnectionImpl.java:720) > > 10:19:56,076 ERROR [stderr] (IdleRemover) at > > org.jboss.ironjacamar.jdbcadapters at 1.4.11.Final > > > //org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.destroy(BaseWrapperManagedConnection.java:491) > > 10:19:56,077 ERROR [stderr] (IdleRemover) at > > org.jboss.ironjacamar.impl at 1.4.11.Final > > > //org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.destroy(AbstractConnectionListener.java:637) > > 10:19:56,078 ERROR [stderr] (IdleRemover) at > > org.jboss.ironjacamar.impl at 1.4.11.Final > > > //org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1006) > > 10:19:56,078 ERROR [stderr] (IdleRemover) at > > org.jboss.ironjacamar.impl at 1.4.11.Final > > > //org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275) > > 10:19:56,078 ERROR [stderr] (IdleRemover) at > > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > > 10:19:56,078 ERROR [stderr] (IdleRemover) at > > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > > 10:19:56,078 ERROR [stderr] (IdleRemover) at > > java.base/java.lang.Thread.run(Thread.java:834) > > 10:19:56,078 ERROR [stderr] (IdleRemover) > > 10:19:56,078 ERROR [stderr] (IdleRemover) > > 10:19:56,078 ERROR [stderr] (IdleRemover) ** END NESTED EXCEPTION ** > > -- Dennis R. Gesker [image: LinkedIn] [image: WordPress] [image: Gesker] [image: GPG_PGP] [image: dennis at gesker.com] ?Be without fear in the face of your enemies. Be brave and upright that God may love thee. Speak the truth always, even if it leads to your death. Safeguard the helpless and do no wrong ? that is your oath.?* -The Knight?s Oath (Kingdom of Heaven)* From mark.reinhold at oracle.com Fri Jan 18 18:14:12 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 18 Jan 2019 10:14:12 -0800 (PST) Subject: JDK 12 is now in Rampdown Phase Two Message-ID: <20190118181412.B835C235F89@eggemoggin.niobe.net> Per the JDK 12 schedule [1], we are now in Rampdown Phase Two. The overall feature set is frozen. No further JEPs will be targeted to this release. Per the JDK Release Process [3] we now turn our focus to P1 and P2 bugs. Late enhancements are still possible with approval, but the bar is now extraordinarily high. If you?re responsible for any of the bugs on the RDP 2 candidate-bug list [3] then please see JEP 3 for guidance on how to handle them. - Mark [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://openjdk.java.net/jeps/3 [3] http://j.mp/jdk-rdp-2 From aph at redhat.com Mon Jan 21 10:36:42 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 21 Jan 2019 10:36:42 +0000 Subject: CFV: New JDK Committer: Ningsheng Jian Message-ID: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> I hereby nominate Ningsheng Jian (njian) to JDK Committer. Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. [1] - http://openjdk.java.net/census [2] - http://openjdk.java.net/projects/#committer-vote Thanks, ========== 8158361: AArch64: Address calculation missed optimizations 8169697: AArch64: Vectorized MLA instruction not generated for some test cases 8172881: AArch64: assertion failure: the int pressure is incorrect 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation 8179933: AArch64: Incorrect match rule for immL_255 8181633: Vectorization fails for some multiplication with constant cases 8182583: AArch64: FMA Vectorization on aarch64 8183533: AArch64: redundent registers saving in arraycopy stubs 8184049: AArch64: Matching rule for ubfiz 8185786: AArch64: disable some address reshapings. 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV 8187022: AArch64: UBFX instructions have wrong format string 8191954: AArch64: disable UseCISCSpill in C2 8191955: AArch64: incorrect prefetch distance causes an internal error 8195588: AArch64: Codegen fix after JDK-8194256 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Jan 21 12:02:34 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 21 Jan 2019 12:02:34 +0000 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes On 21/01/2019 10:36, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From neugens.limasoftware at gmail.com Mon Jan 21 12:04:50 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 21 Jan 2019 13:04:50 +0100 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: Yes, Cheers, Mario On Mon 21. Jan 2019 at 13:02, Andrew Dinn wrote: > Vote: yes > > On 21/01/2019 10:36, Andrew Haley wrote: > > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot > related. > > > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [2]. > > > > [1] - http://openjdk.java.net/census > > [2] - http://openjdk.java.net/projects/#committer-vote > > > > Thanks, > > > > ========== > > > > 8158361: AArch64: Address calculation missed optimizations > > 8169697: AArch64: Vectorized MLA instruction not generated for some test > cases > > 8172881: AArch64: assertion failure: the int pressure is incorrect > > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with > -XX:+TieredCompilation > > 8179933: AArch64: Incorrect match rule for immL_255 > > 8181633: Vectorization fails for some multiplication with constant cases > > 8182583: AArch64: FMA Vectorization on aarch64 > > 8183533: AArch64: redundent registers saving in arraycopy stubs > > 8184049: AArch64: Matching rule for ubfiz > > 8185786: AArch64: disable some address reshapings. > > 8186325: AArch64: jtreg test > hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > > 8187022: AArch64: UBFX instructions have wrong format string > > 8191954: AArch64: disable UseCISCSpill in C2 > > 8191955: AArch64: incorrect prefetch distance causes an internal error > > 8195588: AArch64: Codegen fix after JDK-8194256 > > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From sgehwolf at redhat.com Mon Jan 21 12:15:56 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 21 Jan 2019 13:15:56 +0100 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: <20e540e8b5ca19435fc613aa77e5d14edb263345.camel@redhat.com> Vote: yes. On Mon, 2019-01-21 at 10:36 +0000, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > From tobias.hartmann at oracle.com Mon Jan 21 14:36:29 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 21 Jan 2019 15:36:29 +0100 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: <37221534-fc07-e883-bd14-b1eaf9e0b647@oracle.com> Vote: yes Best regards, Tobias On 21.01.19 11:36, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > From dmitry.chuyko at bell-sw.com Mon Jan 21 14:47:11 2019 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Mon, 21 Jan 2019 17:47:11 +0300 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes On 1/21/19 1:36 PM, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > From thomas.stuefe at gmail.com Mon Jan 21 15:46:12 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 21 Jan 2019 16:46:12 +0100 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes On Mon, Jan 21, 2019 at 11:37 AM Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot > related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test > cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with > -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test > hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From vladimir.x.ivanov at oracle.com Mon Jan 21 21:46:42 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 21 Jan 2019 13:46:42 -0800 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: <74d6344e-c4ce-3467-8553-7393045c850a@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 21/01/2019 02:36, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. From serguei.spitsyn at oracle.com Tue Jan 22 04:19:11 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 21 Jan 2019 20:19:11 -0800 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes From felix.yang at huawei.com Tue Jan 22 04:36:42 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 22 Jan 2019 04:36:42 +0000 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes From volker.simonis at gmail.com Tue Jan 22 08:16:34 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Jan 2019 09:16:34 +0100 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes On Mon, Jan 21, 2019 at 11:37 AM Andrew Haley wrote: > > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Tue Jan 22 13:26:08 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 22 Jan 2019 08:26:08 -0500 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: <20a21184-9b15-434e-335c-ff296b584c37@redhat.com> Vote: yes. -Zhengyu On 1/21/19 5:36 AM, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > From dmitrij.pochepko at bell-sw.com Tue Jan 22 13:38:07 2019 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Tue, 22 Jan 2019 16:38:07 +0300 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: <8310e008-4c47-b969-797b-98de36913fe8@bell-sw.com> Vote: yes On 21/01/2019 1:36 PM, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > From adam.petcher at oracle.com Tue Jan 22 15:24:22 2019 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 22 Jan 2019 10:24:22 -0500 Subject: RFR 8217518: Crypto benchmarks not warming up in time Message-ID: <450d8096-cb78-407a-6bf3-10ffae68210d@oracle.com> Claes, Please review this very small change that adds the "+AlwaysPreTouch" option to the crypto benchmarks to allow them to warm up in time. This fix is in response to Eric's discovery (when reviewing the new benchmarks for KeyAgreement and Cipher) that the crypto benchmarks were not warming up very well. Sergey discovered that the cause is memory allocation overhead with large heaps and G1. Adding +AlwaysPreTouch does more of this memory allocation work up front so it doesn't interfere with the benchmark. Webrev: http://cr.openjdk.java.net/~apetcher/8217518/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8217518 From claes.redestad at oracle.com Tue Jan 22 15:35:23 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 16:35:23 +0100 Subject: RFR 8217518: Crypto benchmarks not warming up in time In-Reply-To: <450d8096-cb78-407a-6bf3-10ffae68210d@oracle.com> References: <450d8096-cb78-407a-6bf3-10ffae68210d@oracle.com> Message-ID: <762d44d6-1d79-9410-7f0a-2439a4dc3828@oracle.com> Hi, looks OK as a point fix for now, although we should consider if there might be more robust ways that avoids hard-coding in flags. E.g, could +AlwaysPreTouch have unfortunate side-effects on machines with extreme amounts of RAM if you don't also limit maximum heap size (-Xmx)? /Claes On 2019-01-22 16:24, Adam Petcher wrote: > Claes, > > Please review this very small change that adds the "+AlwaysPreTouch" > option to the crypto benchmarks to allow them to warm up in time. This > fix is in response to Eric's discovery (when reviewing the new > benchmarks for KeyAgreement and Cipher) that the crypto benchmarks were > not warming up very well. Sergey discovered that the cause is memory > allocation overhead with large heaps and G1. Adding +AlwaysPreTouch does > more of this memory allocation work up front so it doesn't interfere > with the benchmark. > > Webrev: http://cr.openjdk.java.net/~apetcher/8217518/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8217518 > From Roger.Riggs at oracle.com Tue Jan 22 15:54:50 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 22 Jan 2019 10:54:50 -0500 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes On 01/21/2019 05:36 AM, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. From derekw at marvell.com Tue Jan 22 20:38:08 2019 From: derekw at marvell.com (Derek White) Date: Tue, 22 Jan 2019 20:38:08 +0000 Subject: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: Yes! - Derek > -----Original Message----- > From: jdk-dev On Behalf Of Andrew > Haley > Sent: Monday, January 21, 2019 5:37 AM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Ningsheng Jian > > External Email > > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot > related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test > cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together > with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test > hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gromero at linux.vnet.ibm.com Tue Jan 22 22:48:18 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 22 Jan 2019 20:48:18 -0200 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes On 01/21/2019 08:36 AM, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > From dean.long at oracle.com Wed Jan 23 00:44:35 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 22 Jan 2019 16:44:35 -0800 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: <0c98dc03-018f-67a5-d45c-cdad0cd0bac1@oracle.com> |Vote: yes| On 1/21/19 2:36 AM, Andrew Haley wrote: > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > > Ningsheng has contributed 16 fixes to the JDK, mostly AArch64 HotSpot related. > > Votes are due before 17:00 PST (GMT-0800) on 2019-02-06. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > [1] - http://openjdk.java.net/census > [2] - http://openjdk.java.net/projects/#committer-vote > > Thanks, > > ========== > > 8158361: AArch64: Address calculation missed optimizations > 8169697: AArch64: Vectorized MLA instruction not generated for some test cases > 8172881: AArch64: assertion failure: the int pressure is incorrect > 8173100: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation > 8179933: AArch64: Incorrect match rule for immL_255 > 8181633: Vectorization fails for some multiplication with constant cases > 8182583: AArch64: FMA Vectorization on aarch64 > 8183533: AArch64: redundent registers saving in arraycopy stubs > 8184049: AArch64: Matching rule for ubfiz > 8185786: AArch64: disable some address reshapings. > 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV > 8187022: AArch64: UBFX instructions have wrong format string > 8191954: AArch64: disable UseCISCSpill in C2 > 8191955: AArch64: incorrect prefetch distance causes an internal error > 8195588: AArch64: Codegen fix after JDK-8194256 > 8202186: AArch64: Debug build VM crashes with PrintC1Statistics option > From yumin.qi at gmail.com Fri Jan 25 08:52:14 2019 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 25 Jan 2019 16:52:14 +0800 Subject: Anonymous class Message-ID: Hi, I have a question of anonymous class. We know the anonymous class with a host_klass, and the flag is set when the InstanceKlass is created after the class parsed. In case of a regular java class file, the flag will be set correctly but for the case it is not set: SystemDictionary::parse_stream or resolve_from_stream, which is called from JVM_DefineClassWithSource or jni_defineClass. The stack trace like: #1 0x00007f1127291ce7 in SystemDictionary::resolve_from_stream(class_name=0x7f0ee40243f0, class_loader=..., protection_domain=...,d__=0x7f0f04001000) at /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionaryShared.cpp:656 #1 0x00007f1127291ce7 in SystemDictionary::resolve_from_stream (class_name=0x7f0ee40243f0, class_loader=..., protection_doma in=..., st=0x7f0f0a5f3850, verify=true, __the_thread__=0x7f0f04001000) at /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/classfile/systemDictionary.cpp:1234 #2 0x00007f1126f3cadb in jvm_define_class_common (env=0x7f0f04001220, name=0x7f0f0a5f3e60 "com/google/common/collect/Iterato rs$3", loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 "\312\376\272\276", len=943, pd=0x7f0f0a5f3f48, source=0x7f0f0a5f3a60 "jar:file:/home/<...>/lib/guava-19.0.jar!/", verify=1 '\001', __the_thread__=0x7f0f04001000) at /home/yumin.qi/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prims/jvm.cpp:1082 #3 0x00007f1126f3d019 in JVM_DefineClassWithSource (env=0x7f0f04001220, name=0x7f0f0a5f3e60 "com/google/common/collect/Itera tors$3", loader=0x7f0f0a5f3f20, buf=0x7f0ee401e210 "\312\376\272\276", len=943, pd=0x7f0f0a5f3f48, source=0x7f0f0a5f3a60 "jar:file:/home/<...>/lib/guava-19.0.jar!/") at /home/ws/openjdk/8/jdk8u/hotspot/src/share/vm/prim/jvm.cpp:1102 #4 0x00007f112581214f in Java_java_lang_ClassLoader_defineClass1 () from /home/ws/openjdk/8/jdk8u/build/linux-x86_64-normal-server-slowdebug/images/j2sdk-image/jre/lib/amd64/libjava.so #5 0x00007f11118f5402 in ?? () #6 0x00007f0f0a5f3f48 in ?? () #7 0x00007f0f0a5f3f70 in ?? () #8 0x0000000755dbbc28 in ?? () The class name is com.google.common.collect.Iterators$3, and it is an anonymous class. This is an example using Guava. I also can reproduce with jdk13. The field after parsing: _nonstatic_oop_map_size = 1, _is_marked_dependent = false, _has_unloaded_dependent = false, _misc_flags = 38, ////// <------------ not set for anonymous _minor_version = 0, _major_version = 50, _init_thread = 0x0, _vtable_len = 8, _itable_len = 8, This path is from a custom loader defining a anonymous class, does not set anonymous correctly for the flag. Is this a bug? If in java land, supply a host as parameter, it can be set correctly in VM part. Should I file a bug for it? Thanks Yumin From zcauniverse at 163.com Mon Jan 28 07:40:39 2019 From: zcauniverse at 163.com (=?utf-8?B?emNhdW5pdmVyc2U=?=) Date: Mon, 28 Jan 2019 15:40:39 +0800 Subject: How to compile openJdk8 on macOs mojave Message-ID: Hi,guys I?m trying to compile openjdk8 on my Mac. when I execute ?make? command, I got some errors like following: In file included from /Users/xxx/Documents/opensource_projects/openjdk-learning/openjdk/hotspot/src/share/vm/adlc/archDesc.cpp:27: /Users/xxx/Documents/opensource_projects/openjdk-learning/openjdk/hotspot/src/share/vm/adlc/adlc.hpp:35:10: fatal error: 'iostream' file not found #include iostream ^~~~~~~~~~ In file included from /Users/xxx/Documents/opensource_projects/openjdk-learning/openjdk/hotspot/src/share/vm/adlc/adlparse.cpp:27: /Users/xxx/Documents/opensource_projects/openjdk-learning/openjdk/hotspot/src/share/vm/adlc/adlc.hpp:35:10: fatal error: 'iostream' file not found #include iostream ^~~~~~~~~~ 1 error generated. make[8]: *** [../generated/adfiles/archDesc.o] Error 1 make[8]: *** Waiting for unfinished jobs.... 1 error generated. I have tried both xcode9.4.1 and Xcode10, neither of one worked. I want to know if that is possible to compile openJdk8 on Mojave . If it is, what should I do to make it done. Thanks From bsrbnd at gmail.com Mon Jan 28 13:11:13 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 28 Jan 2019 14:11:13 +0100 Subject: CFV: New JDK Committer: Ningsheng Jian In-Reply-To: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> References: <0e4f80e1-358a-5e73-8736-c9556c049011@redhat.com> Message-ID: Vote: yes Regards, Bernard On Mon, 21 Jan 2019 at 11:37, Andrew Haley wrote: > > I hereby nominate Ningsheng Jian (njian) to JDK Committer. > [...] From obonilla66 at gmail.com Tue Jan 29 15:58:31 2019 From: obonilla66 at gmail.com (Ing. Oscar Bonilla, MBA) Date: Tue, 29 Jan 2019 09:58:31 -0600 Subject: Java OpenJDK GPL license with CLASSPATH EXCEPTION Message-ID: What have special the packages jdk.hotspot.agent, jdk.internal.vm.ci, jdk.internal.vm.compiler.management and jdk.internal.vm.compiler, which are the only source files that have GPL license but do not have the expressly "Classpath Exception" designator in the file's header (all of the source files have the GPL license)? It is legal to use some classes of this 5 packages in a non-GPL system? ------------------- I am new here. I am not know if this is the right mail list for this question, but I have to ask it. The JDK license said that the GPL license with classpath exception apply only where Oracle has expressly included in the particular source file's header the words "Oracle designates this particular file as subject to the Classpath exception..." I found a total of 17,873 source java files in openJDK 11.0.2, with this results: 11,683 files with GPL License with expressly "Classpath Exception" designation 1,643 files with AFS - Apache Software Fundation License 157 files with BSD License 1 file with MIT License 341 resource files without any kind of copyright or License (where 334 are resource files) 4,048 files with GPL License without expressly "Classpath Exception" designation in the source header. All in 5 specific directories: - \src\jdk.aot (107 files) - \src\jdk.hotspot.agent (998 files) - \src\jdk.internal.vm.ci (181 files) - \src\jdk.internal.vm.compiler.management (4 files) - \src\jdk.internal.vm.compiler (2758 files) But each of these 5 last directories has a "module-info.java" file on its corresponding root path: \src\jdk.aot\module-info.java \src\jdk.hotspot.agent\module-info.java \src\jdk.internal.vm.ci\module-info.java \src\jdk.internal.vm.compiler.management\module-info.java \src\jdk.internal.vm.compiler\module-info.java whose header contains the expressly the "Classpath Exception" designation, which makes it seem like the content of whole of each directory would be included in the Exception, but none of their file included it. Then my conclusion is 2 posibilities: 1. Oracle forgot to include the "Classpath Exception designation" in each source files 2. There are some special circumstances that caused Oracle to consciously exclude them from the "Classpath Exception" Regards. From andrewluotechnologies at outlook.com Tue Jan 29 20:57:28 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 29 Jan 2019 20:57:28 +0000 Subject: Java OpenJDK GPL license with CLASSPATH EXCEPTION In-Reply-To: References: Message-ID: Depends on if your system is GPL-compatible or not. The classpath exception allows you to build proprietary (or otherwise GPL-incompatible) software on top of the OpenJDK and use the Java Class Library in your software. However, some parts of the OpenJDK are not covered under the classpath exception - the legality of using those in GPL-incompatible application will depend on a number of factors and the specific use case (for example: does your work constitute a derivative work?). You probably want to consult with a qualified lawyer on those questions. Thanks, -Andrew -----Original Message----- From: jdk-dev On Behalf Of Ing. Oscar Bonilla, MBA Sent: Tuesday, January 29, 2019 7:59 AM To: jdk-dev at openjdk.java.net Subject: Java OpenJDK GPL license with CLASSPATH EXCEPTION What have special the packages jdk.hotspot.agent, jdk.internal.vm.ci, jdk.internal.vm.compiler.management and jdk.internal.vm.compiler, which are the only source files that have GPL license but do not have the expressly "Classpath Exception" designator in the file's header (all of the source files have the GPL license)? It is legal to use some classes of this 5 packages in a non-GPL system? ------------------- I am new here. I am not know if this is the right mail list for this question, but I have to ask it. The JDK license said that the GPL license with classpath exception apply only where Oracle has expressly included in the particular source file's header the words "Oracle designates this particular file as subject to the Classpath exception..." I found a total of 17,873 source java files in openJDK 11.0.2, with this results: 11,683 files with GPL License with expressly "Classpath Exception" designation 1,643 files with AFS - Apache Software Fundation License 157 files with BSD License 1 file with MIT License 341 resource files without any kind of copyright or License (where 334 are resource files) 4,048 files with GPL License without expressly "Classpath Exception" designation in the source header. All in 5 specific directories: - \src\jdk.aot (107 files) - \src\jdk.hotspot.agent (998 files) - \src\jdk.internal.vm.ci (181 files) - \src\jdk.internal.vm.compiler.management (4 files) - \src\jdk.internal.vm.compiler (2758 files) But each of these 5 last directories has a "module-info.java" file on its corresponding root path: \src\jdk.aot\module-info.java \src\jdk.hotspot.agent\module-info.java \src\jdk.internal.vm.ci\module-info.java \src\jdk.internal.vm.compiler.management\module-info.java \src\jdk.internal.vm.compiler\module-info.java whose header contains the expressly the "Classpath Exception" designation, which makes it seem like the content of whole of each directory would be included in the Exception, but none of their file included it. Then my conclusion is 2 posibilities: 1. Oracle forgot to include the "Classpath Exception designation" in each source files 2. There are some special circumstances that caused Oracle to consciously exclude them from the "Classpath Exception" Regards. From david.holmes at oracle.com Tue Jan 29 22:39:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Jan 2019 08:39:21 +1000 Subject: Java OpenJDK GPL license with CLASSPATH EXCEPTION In-Reply-To: References: Message-ID: <430ceebc-c9c2-77bb-613b-ef719cc806d7@oracle.com> On 30/01/2019 1:58 am, Ing. Oscar Bonilla, MBA wrote: > What have special the packages jdk.hotspot.agent, jdk.internal.vm.ci, > jdk.internal.vm.compiler.management and jdk.internal.vm.compiler, which are > the only source files that have GPL license but do not have the > expressly "Classpath Exception" designator in the file's header (all of the > source files have the GPL license)? I think it may be just an oversight. I'll see what I can find out. David ----- > It is legal to use some classes of this 5 packages in a non-GPL system? > ------------------- > I am new here. I am not know if this is the right mail list for this > question, but I have to ask it. > > The JDK license said that the GPL license with classpath exception apply > only where Oracle has expressly included in the particular source file's > header the words "Oracle designates this particular file as subject to the > Classpath exception..." > > I found a total of 17,873 source java files in openJDK 11.0.2, with this > results: > 11,683 files with GPL License with expressly "Classpath Exception" > designation > 1,643 files with AFS - Apache Software Fundation License > 157 files with BSD License > 1 file with MIT License > 341 resource files without any kind of copyright or License (where 334 > are resource files) > 4,048 files with GPL License without expressly "Classpath Exception" > designation in the source header. All in 5 specific directories: > - \src\jdk.aot (107 files) > - \src\jdk.hotspot.agent (998 files) > - \src\jdk.internal.vm.ci (181 files) > - \src\jdk.internal.vm.compiler.management (4 files) > - \src\jdk.internal.vm.compiler (2758 files) > > But each of these 5 last directories has a "module-info.java" file on its > corresponding root path: > \src\jdk.aot\module-info.java > \src\jdk.hotspot.agent\module-info.java > \src\jdk.internal.vm.ci\module-info.java > \src\jdk.internal.vm.compiler.management\module-info.java > \src\jdk.internal.vm.compiler\module-info.java > whose header contains the expressly the "Classpath Exception" designation, > which makes it seem like the content of whole of each directory would be > included in the Exception, but none of their file included it. > > Then my conclusion is 2 posibilities: > 1. Oracle forgot to include the "Classpath Exception designation" in each > source files > 2. There are some special circumstances that caused Oracle to consciously > exclude them from the "Classpath Exception" > > Regards. > From vladimir.kozlov at oracle.com Tue Jan 29 22:54:20 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 29 Jan 2019 14:54:20 -0800 Subject: Java OpenJDK GPL license with CLASSPATH EXCEPTION In-Reply-To: <430ceebc-c9c2-77bb-613b-ef719cc806d7@oracle.com> References: <430ceebc-c9c2-77bb-613b-ef719cc806d7@oracle.com> Message-ID: On 1/29/19 2:39 PM, David Holmes wrote: > On 30/01/2019 1:58 am, Ing. Oscar Bonilla, MBA wrote: >> What have special the packages? jdk.hotspot.agent, jdk.internal.vm.ci, >> jdk.internal.vm.compiler.management and jdk.internal.vm.compiler, which are >> the only source files that have GPL license but do not have the >> expressly "Classpath Exception" designator in the file's header (all of the >> source files have the GPL license)? > > I think it may be just an oversight. I'll see what I can find out. I agree with David. When these directories were created, module-info.java files were copied from places with "Classpath Exception". We should fix them. Note, files in these directories have the same license as src/hotspot because they are related. Vladimir > > David > ----- > >> It is legal to use some classes of this 5 packages in a non-GPL system? >> ------------------- >> I am new here.? I am not know if this is the right mail list for this >> question, but I have to ask it. >> >> The JDK license said that the GPL license with classpath exception apply >> only where Oracle has expressly included in the particular source file's >> header the words "Oracle designates this particular file as subject to the >> Classpath exception..." >> >> I found a total of 17,873 source java files in openJDK 11.0.2, with this >> results: >> 11,683 files with GPL License with expressly "Classpath Exception" >> designation >> 1,643 files with AFS - Apache Software Fundation License >> ??? 157 files with BSD License >> ????? 1 file with MIT License >> ??? 341 resource files without any kind of copyright or License (where 334 >> are resource files) >> 4,048 files with GPL License without expressly "Classpath Exception" >> designation in the source header. All in 5 specific directories: >> ??? - \src\jdk.aot (107 files) >> ??? - \src\jdk.hotspot.agent (998 files) >> ??? - \src\jdk.internal.vm.ci (181 files) >> ??? - \src\jdk.internal.vm.compiler.management (4 files) >> ??? - \src\jdk.internal.vm.compiler (2758 files) >> >> But each of these 5 last directories has a "module-info.java" file on its >> corresponding root path: >> \src\jdk.aot\module-info.java >> \src\jdk.hotspot.agent\module-info.java >> \src\jdk.internal.vm.ci\module-info.java >> \src\jdk.internal.vm.compiler.management\module-info.java >> \src\jdk.internal.vm.compiler\module-info.java >> whose header contains the expressly the "Classpath Exception" designation, >> which makes it seem like the content of whole of each directory would be >> included in the Exception, but none of their file included it. >> >> Then my conclusion is 2 posibilities: >> 1. Oracle forgot to include the "Classpath Exception designation" in each >> source files >> 2. There are some special circumstances that caused Oracle to consciously >> exclude them from the "Classpath Exception" >> >> Regards. >> From magnus.ihse.bursie at oracle.com Wed Jan 30 09:31:52 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Jan 2019 10:31:52 +0100 Subject: How to compile openJdk8 on macOs mojave In-Reply-To: References: Message-ID: <7701961f-782c-3a78-0ded-f94955e437eb@oracle.com> On 2019-01-28 08:40, zcauniverse wrote: > Hi,guys > > > I?m trying to compile openjdk8 on my Mac. when I execute ?make? command, I got some errors like following: > > > > > In file included from /Users/xxx/Documents/opensource_projects/openjdk-learning/openjdk/hotspot/src/share/vm/adlc/archDesc.cpp:27: > /Users/xxx/Documents/opensource_projects/openjdk-learning/openjdk/hotspot/src/share/vm/adlc/adlc.hpp:35:10: fatal error: 'iostream' file not found > #include iostream > ^~~~~~~~~~ > In file included from /Users/xxx/Documents/opensource_projects/openjdk-learning/openjdk/hotspot/src/share/vm/adlc/adlparse.cpp:27: > /Users/xxx/Documents/opensource_projects/openjdk-learning/openjdk/hotspot/src/share/vm/adlc/adlc.hpp:35:10: fatal error: 'iostream' file not found > #include iostream > ^~~~~~~~~~ > 1 error generated. > make[8]: *** [../generated/adfiles/archDesc.o] Error 1 > make[8]: *** Waiting for unfinished jobs.... > 1 error generated. > > > > > I have tried both xcode9.4.1 and Xcode10, neither of one worked. > > > I want to know if that is possible to compile openJdk8 on Mojave . If it is, what should I do to make it done. Thanks This looks like your system headers are not found. How did you run configure? What did it say? It might very well be that JDK 8 cannot be built on Mojave in the end anyway, but it should not fail like this -- that is the sign of an build environment error. /Magnus From gromero at linux.vnet.ibm.com Wed Jan 30 17:24:43 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 30 Jan 2019 18:24:43 +0100 Subject: CFV: New JDK Committer: Michihiro Horie Message-ID: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> I hereby nominate Michihiro Horie (mhorie) to JDK Committer. Michihiro works for the IBM Research team (Tokyo) focused on performance and has contributed 15 changes within the last two years and a half, mostly related to performance enhancements for the Hotspot and the GC components on Power, but also with benefits for other architectures. A full list of his contributions can be found below and at [3]. Votes are due by 17:25 UTC February 13, 2019. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you. Best regards, Gustavo [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or+desc(%22horie at jp.ibm.com%22))+and+not+merge() 8179527: Implement intrinsic code for reverseBytes with load/store 8166684: PPC64: implement intrinsic code with vector instructions for Unsafe.copyMemory() 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions 8215262: PPC64: FMA Vectorization on PPC64 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace 8214205: PPC64: Add instructions for counting trailing zeros 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad 8208171: PPC64: Enrich SLP support 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 8194861: PPC64 : Need support for VSR spills in ppc.ad 8188802: PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) 8188757: PPC64: Disable VSR52-63 in ppc.ad 8188139: PPC64: Superword Level Parallelization with VSX From sgehwolf at redhat.com Wed Jan 30 17:42:23 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Jan 2019 18:42:23 +0100 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote: yes. On Wed, 2019-01-30 at 18:24 +0100, Gustavo Romero wrote: > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX > From volker.simonis at gmail.com Wed Jan 30 17:56:12 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Jan 2019 18:56:12 +0100 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote: yes Regards, Volker On Wed, Jan 30, 2019 at 6:25 PM Gustavo Romero wrote: > > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX > From vladimir.kozlov at oracle.com Wed Jan 30 18:06:17 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Jan 2019 10:06:17 -0800 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote: yes On 1/30/19 9:24 AM, Gustavo Romero wrote: > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX > From serguei.spitsyn at oracle.com Wed Jan 30 18:57:13 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2019 10:57:13 -0800 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: <22739e9f-113b-22d2-7c23-740900cc757e@oracle.com> Vote: yes From bsrbnd at gmail.com Wed Jan 30 19:51:18 2019 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 30 Jan 2019 20:51:18 +0100 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote: yes Regards, Bernard On Wed, 30 Jan 2019 at 18:25, Gustavo Romero wrote: > > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > [...] From david.holmes at oracle.com Thu Jan 31 01:22:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 11:22:20 +1000 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote: yes David On 31/01/2019 3:24 am, Gustavo Romero wrote: > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for > Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX > instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in > G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on > assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX > From yasuenag at gmail.com Thu Jan 31 01:33:17 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 31 Jan 2019 10:33:17 +0900 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote: yes Yasumasa 2019?1?31?(?) 2:25?Gustavo Romero ???gromero at linux.vnet.ibm.com???????: > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for > Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX > instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in > ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in > G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on > assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX > > From vyom.tewari at oracle.com Thu Jan 31 03:01:39 2019 From: vyom.tewari at oracle.com (vyom tewari) Date: Thu, 31 Jan 2019 08:31:39 +0530 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote: yes On 30/01/19 10:54 PM, Gustavo Romero wrote: > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, > mostly > related to performance enhancements for the Hotspot and the GC components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for > Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using > VSX instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in > ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in > G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on > assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX > From vladimir.x.ivanov at oracle.com Thu Jan 31 03:10:53 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 30 Jan 2019 19:10:53 -0800 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: <2f4f88f2-02e5-cda4-acf5-3c9fc89eb7df@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 30/01/2019 09:24, Gustavo Romero wrote: > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. From derekw at marvell.com Thu Jan 31 05:17:13 2019 From: derekw at marvell.com (Derek White) Date: Thu, 31 Jan 2019 05:17:13 +0000 Subject: [EXT] CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote: Yes > -----Original Message----- > From: jdk-dev On Behalf Of Gustavo > Romero > Sent: Wednesday, January 30, 2019 12:25 PM > To: jdk-dev > Subject: [EXT] CFV: New JDK Committer: Michihiro Horie > Importance: High> > ---------------------------------------------------------------------- > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC > components on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+ > or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for > Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX > instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in > G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on > assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX From christoph.langer at sap.com Thu Jan 31 06:38:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 31 Jan 2019 06:38:57 +0000 Subject: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: Vote:yes > -----Original Message----- > From: jdk-dev On Behalf Of Gustavo > Romero > Sent: Mittwoch, 30. Januar 2019 18:25 > To: jdk-dev > Subject: CFV: New JDK Committer: Michihiro Horie > Importance: High > > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC > components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie) > +or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for > Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX > instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in > G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on > assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX From thomas.schatzl at oracle.com Thu Jan 31 08:18:15 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 31 Jan 2019 09:18:15 +0100 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: <45a3cdfd3f8f84615d2b6acf56896299c23eaf78.camel@oracle.com> Vote: yes From goetz.lindenmaier at sap.com Thu Jan 31 08:47:18 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 31 Jan 2019 08:47:18 +0000 Subject: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: <500ffde91636456cb5c45525281b2dbe@sap.com> vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Gustavo > Romero > Sent: Mittwoch, 30. Januar 2019 18:25 > To: jdk-dev > Subject: CFV: New JDK Committer: Michihiro Horie > Importance: High > > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or > +desc(%22horie at jp.ibm.com%22))+and+not+merge() > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for > Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX > instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in > G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on > assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX From adinn at redhat.com Thu Jan 31 10:15:34 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 31 Jan 2019 10:15:34 +0000 Subject: CFV: New JDK Committer: Michihiro Horie In-Reply-To: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> References: <7fae5d41-a3d4-fa16-00bb-866b9eab8993@linux.vnet.ibm.com> Message-ID: <47953d0d-f496-66e6-52c0-8eaa90012dac@redhat.com> Vote: yes On 30/01/2019 17:24, Gustavo Romero wrote: > I hereby nominate Michihiro Horie (mhorie) to JDK Committer. > > Michihiro works for the IBM Research team (Tokyo) focused on performance > and has contributed 15 changes within the last two years and a half, mostly > related to performance enhancements for the Hotspot and the GC components > on Power, but also with benefits for other architectures. > > A full list of his contributions can be found below and at [3]. > ? > Votes are due by 17:25 UTC February 13, 2019. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(mhorie)+or+desc(%22horie at jp.ibm.com%22))+and+not+merge() > > > 8179527: Implement intrinsic code for reverseBytes with load/store > 8166684: PPC64: implement intrinsic code with vector instructions for > Unsafe.copyMemory() > 8158232: PPC64: improve byte, int and long array copy stubs by using VSX > instructions > 8215262: PPC64: FMA Vectorization on PPC64 > 8213754: PPC64: Add Intrinsics for > isDigit/isLowerCase/isUpperCase/isWhitespace > 8214205: PPC64: Add instructions for counting trailing zeros > 8211908: PPC64: Enable SuperWordLoopUnrollAnalysis by default > 8210660: PPC64: Mapping floating point registers to vsx registers in ppc.ad > 8208171: PPC64: Enrich SLP support > 8204524: Unnecessary memory barriers in > G1ParScanThreadState::copy_to_survivor_space > 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 > 8194861: PPC64 : Need support for VSR spills in ppc.ad > 8188802: PPC64: Failure on > assert(lrgmask.is_aligned_sets(RegMask::SlotsPerVecX)) > 8188757: PPC64: Disable VSR52-63 in ppc.ad > 8188139: PPC64: Superword Level Parallelization with VSX > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander