From dmitry.markov at oracle.com Mon May 8 11:22:50 2017
From: dmitry.markov at oracle.com (dmitry markov)
Date: Mon, 08 May 2017 14:22:50 +0300
Subject: [8u-dev] Request for approval 8170913: Java "1.8.0_112" on Windows
10 displays different characters for EUDCs from ones created in eudcedit.exe.
Message-ID: <5910550A.7000501@oracle.com>
Hello,
Can I get an approval to port the fix for 8170913 to jdk8u-dev, please? The jdk9 patch applies cleanly.
JBS: https://bugs.openjdk.java.net/browse/JDK-8170913
Review thread: http://mail.openjdk.java.net/pipermail/2d-dev/2017-February/008206.html
jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2855498ee7c6
Thanks,
Dmitry
From david.buck at oracle.com Mon May 8 11:49:34 2017
From: david.buck at oracle.com (David Buck)
Date: Mon, 8 May 2017 20:49:34 +0900
Subject: [8u-dev] Request for approval 8170913: Java "1.8.0_112" on
Windows 10 displays different characters for EUDCs from ones created in
eudcedit.exe.
In-Reply-To: <5910550A.7000501@oracle.com>
References: <5910550A.7000501@oracle.com>
Message-ID: <1dd37969-0dd5-5cb6-38c6-e8529c17a7cb@oracle.com>
approved for push to 8u-dev
Cheers,
-Buck
On 2017/05/08 20:22, dmitry markov wrote:
> Hello,
>
> Can I get an approval to port the fix for 8170913 to jdk8u-dev, please?
> The jdk9 patch applies cleanly.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8170913
> Review thread:
> http://mail.openjdk.java.net/pipermail/2d-dev/2017-February/008206.html
> jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2855498ee7c6
>
> Thanks,
> Dmitry
>
From prem.balakrishnan at oracle.com Fri May 12 10:45:03 2017
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Fri, 12 May 2017 03:45:03 -0700 (PDT)
Subject: [8u Backport] Review Request: 8179014: JFileChooser with Windows look
and feel crashes on win 10
Message-ID: <902271b9-56c0-4761-9441-b90592f6d8de@default>
Hi,
Review request for JDK 8u-dev back-port of the fix done in JDK9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8179014
http://mail.openjdk.java.net/pipermail/awt-dev/2017-May/012841.html
JDK 9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/a7c8147f1891
The fix is same as JDK9, except location of file "ShellFolder2.cpp" is different in JDK8u-dev repo.
Webrev: http://cr.openjdk.java.net/~pkbalakr/8179014/8u-dev/webrev.00/
Regards,
Prem
From alexander.zvegintsev at oracle.com Fri May 12 12:23:16 2017
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 12 May 2017 15:23:16 +0300
Subject: [8u-dev] Request for Approval 8178996: [macos] JComboBox doesn't
display popup in mixed JavaFX Swing Application on 8u131 and Mac OS 10.12
Message-ID: <0370a8fe-a181-4897-5a76-25974aef6b92@oracle.com>
Hello,
Please approve the backport, applies cleanly.
https://bugs.openjdk.java.net/browse/JDK-8178996
http://mail.openjdk.java.net/pipermail/awt-dev/2017-May/012844.html
http://hg.openjdk.java.net/jdk9/client/jdk/rev/4a610c6d0b9c
--
Thanks,
Alexander.
From rob.mckenna at oracle.com Fri May 12 13:46:35 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 12 May 2017 14:46:35 +0100
Subject: [8u-dev] Request for Approval 8178996: [macos] JComboBox doesn't
display popup in mixed JavaFX Swing Application on 8u131 and Mac OS
10.12
In-Reply-To: <0370a8fe-a181-4897-5a76-25974aef6b92@oracle.com>
References: <0370a8fe-a181-4897-5a76-25974aef6b92@oracle.com>
Message-ID: <20170512134635.GA3320@vimes>
Approved. Please add an appropriate noreg label.
-Rob
On 12/05/17 03:23, Alexander Zvegintsev wrote:
> Hello,
>
> Please approve the backport, applies cleanly.
>
> https://bugs.openjdk.java.net/browse/JDK-8178996
>
> http://mail.openjdk.java.net/pipermail/awt-dev/2017-May/012844.html
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/4a610c6d0b9c
>
> --
> Thanks,
> Alexander.
>
From philip.race at oracle.com Fri May 12 14:23:15 2017
From: philip.race at oracle.com (Philip Race)
Date: Fri, 12 May 2017 07:23:15 -0700
Subject: [8u Backport] Review Request: 8179014: JFileChooser with Windows
look and feel crashes on win 10
In-Reply-To: <902271b9-56c0-4761-9441-b90592f6d8de@default>
References: <902271b9-56c0-4761-9441-b90592f6d8de@default>
Message-ID: <5915C553.2020304@oracle.com>
OK by me but needs an 8u maintainer's approval.
-phil.
On 5/12/17, 3:45 AM, Prem Balakrishnan wrote:
>
> Hi,
>
> Review request for JDK 8u-dev back-port of the fix done in JDK9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179014
>
> http://mail.openjdk.java.net/pipermail/awt-dev/2017-May/012841.html
>
> JDK 9 changeset:
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/a7c8147f1891
>
> The fix is same as JDK9, except location of file "ShellFolder2.cpp"
> is different in JDK8u-dev repo.**
>
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8179014/8u-dev/webrev.00/
>
>
> Regards,
>
> Prem
>
From rob.mckenna at oracle.com Mon May 15 11:01:25 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 15 May 2017 12:01:25 +0100
Subject: [8u-dev] Request for approval: 8179014: JFileChooser with
Windows look and feel crashes on win 10
In-Reply-To: <5919042D.5090409@oracle.com>
References: <902271b9-56c0-4761-9441-b90592f6d8de@default>
<5915C553.2020304@oracle.com> <20170513231445.GA4023@vimes>
<5919042D.5090409@oracle.com>
Message-ID: <20170515110125.GA26722@tecra>
Yep, to make it explicit: Approved.
-Rob
On 14/05/17 06:28, Philip Race wrote:
> Hi Rob,
>
> Was that an implicit approval ?
>
> -phil.
>
> On 5/13/17, 4:14 PM, Rob McKenna wrote:
> >Altered the subject line to reflect that this is a push approval
> >request.
> >
> >Please follow the template for future requests:
> >http://openjdk.java.net/projects/jdk8u/approval-template.html
> >
> > -Rob
> >
> >On 12/05/17 07:23, Philip Race wrote:
> >>OK by me but needs an 8u maintainer's approval.
> >>
> >>-phil.
> >>
> >>On 5/12/17, 3:45 AM, Prem Balakrishnan wrote:
> >>>Hi,
> >>>
> >>>Review request for JDK 8u-dev back-port of the fix done in JDK9.
> >>>
> >>>Bug: https://bugs.openjdk.java.net/browse/JDK-8179014
> >>>
> >>>http://mail.openjdk.java.net/pipermail/awt-dev/2017-May/012841.html
> >>>
> >>>JDK 9 changeset:
> >>>http://hg.openjdk.java.net/jdk9/client/jdk/rev/a7c8147f1891
> >>>
> >>>The fix is same as JDK9, except location of file "ShellFolder2.cpp" is
> >>>different in JDK8u-dev repo.**
> >>>
> >>>Webrev: http://cr.openjdk.java.net/~pkbalakr/8179014/8u-dev/webrev.00/
> >>>
> >>>
> >>>Regards,
> >>>
> >>>Prem
> >>>
From fairoz.matte at oracle.com Mon May 15 04:06:57 2017
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Sun, 14 May 2017 21:06:57 -0700 (PDT)
Subject: [8u] RFA: JDK-8173664 : Typo in
https://java.net/downloads/heap-snapshot/hprof-binary-format.html
Message-ID: <3589ee08-6dba-4554-9e14-1d520d1cffbb@default>
Hi,
Can I get approval to push JDK-8173664 fix to 8udev.
Bug - https://bugs.openjdk.java.net/browse/JDK-8173664
Webrev - http://cr.openjdk.java.net/~rpatil/8173664/webrev/
Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-May/021294.html
Thanks,
Fairoz
From philip.race at oracle.com Mon May 15 01:28:13 2017
From: philip.race at oracle.com (Philip Race)
Date: Sun, 14 May 2017 18:28:13 -0700
Subject: [8u-dev] Request for approval: 8179014: JFileChooser with Windows
look and feel crashes on win 10
In-Reply-To: <20170513231445.GA4023@vimes>
References: <902271b9-56c0-4761-9441-b90592f6d8de@default>
<5915C553.2020304@oracle.com> <20170513231445.GA4023@vimes>
Message-ID: <5919042D.5090409@oracle.com>
Hi Rob,
Was that an implicit approval ?
-phil.
On 5/13/17, 4:14 PM, Rob McKenna wrote:
> Altered the subject line to reflect that this is a push approval
> request.
>
> Please follow the template for future requests:
> http://openjdk.java.net/projects/jdk8u/approval-template.html
>
> -Rob
>
> On 12/05/17 07:23, Philip Race wrote:
>> OK by me but needs an 8u maintainer's approval.
>>
>> -phil.
>>
>> On 5/12/17, 3:45 AM, Prem Balakrishnan wrote:
>>> Hi,
>>>
>>> Review request for JDK 8u-dev back-port of the fix done in JDK9.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179014
>>>
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2017-May/012841.html
>>>
>>> JDK 9 changeset:
>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/a7c8147f1891
>>>
>>> The fix is same as JDK9, except location of file "ShellFolder2.cpp" is
>>> different in JDK8u-dev repo.**
>>>
>>> Webrev: http://cr.openjdk.java.net/~pkbalakr/8179014/8u-dev/webrev.00/
>>>
>>>
>>> Regards,
>>>
>>> Prem
>>>
From ivan.gerasimov at oracle.com Tue May 16 06:31:19 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 15 May 2017 23:31:19 -0700
Subject: [8u-dev] Request for approval to backport: 8037346: Need to terminate
server process if client runs into problems
Message-ID: <3e1e5f74-78cb-b76b-4803-b28496b8a16d@oracle.com>
Hello!
Would you please approve this backport of this test-only fix which
improves stability of three security tests?
The unshuffled patch applies cleanly.
Bug: https://bugs.openjdk.java.net/browse/JDK-8037346
Jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a94a8944bd2b
Jdk9 review:
http://mail.openjdk.java.net/pipermail/security-dev/2014-March/010320.html
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
From fairoz.matte at oracle.com Tue May 16 06:36:31 2017
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Mon, 15 May 2017 23:36:31 -0700 (PDT)
Subject: [8u] RFA: JDK-8173664 : Typo in
https://java.net/downloads/heap-snapshot/hprof-binary-format.html
In-Reply-To: <3589ee08-6dba-4554-9e14-1d520d1cffbb@default>
References: <3589ee08-6dba-4554-9e14-1d520d1cffbb@default>
Message-ID: <8821106d-1b48-4a2f-ba51-43962bfd1630@default>
Hi,
Sorry for sending the old webrev,
Updated webrev - http://cr.openjdk.java.net/~rpatil/8173664/webrev.01/
Thanks,
Fairoz
> -----Original Message-----
> From: Fairoz Matte
> Sent: Monday, May 15, 2017 9:37 AM
> To: jdk8u-dev at openjdk.java.net
> Subject: [8u] RFA: JDK-8173664 : Typo in https://java.net/downloads/heap-
> snapshot/hprof-binary-format.html
>
> Hi,
>
> Can I get approval to push JDK-8173664 fix to 8udev.
> Bug - https://bugs.openjdk.java.net/browse/JDK-8173664
> Webrev - http://cr.openjdk.java.net/~rpatil/8173664/webrev/
> Review thread - http://mail.openjdk.java.net/pipermail/serviceability-
> dev/2017-May/021294.html
>
> Thanks,
> Fairoz
From rahul.v.raghavan at oracle.com Tue May 16 06:50:48 2017
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Mon, 15 May 2017 23:50:48 -0700 (PDT)
Subject: [8u Backport] RFR: 8177429: possible null pointer dereference defects
Message-ID: <38de2381-67bc-44d0-b0a8-a14dcd914a0e@default>
Hi,
Request for approval -
- http://cr.openjdk.java.net/~rraghavan/8175345/webrev.01/
- '49 Null pointer dereference defect groups in 21 files' -
https://bugs.openjdk.java.net/browse/JDK-8177429
Backport of -
https://bugs.openjdk.java.net/browse/JDK-8175345
With 8175345, the changes done in jdk9 were reviewed in open and committed.
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025798.html
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/55e3f1f3d0a7
This backport fix is same as in jdk9.
Thanks,
Rahul
From alexey.ivanov at oracle.com Tue May 16 10:15:05 2017
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Tue, 16 May 2017 13:15:05 +0300
Subject: [8u-dev] Request for approval 8175915: NullPointerException from
JComboBox and JList when Accessibility enabled
Message-ID:
Hello,
Could you please approve the following backport to jdk8u-dev?
JBS: https://bugs.openjdk.java.net/browse/JDK-8175915
Webrev: http://cr.openjdk.java.net/~mcherkas/8175915/webrev/
Review:
http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007335.html
JDK 9 changeset:
http://hg.openjdk.java.net/jdk9/client/jdk/rev/828d3f3728a2
The patch applies cleanly to jdk8u-dev after paths unshuffling.
Thanks,
Alexey
From rob.mckenna at oracle.com Tue May 16 16:21:01 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 May 2017 17:21:01 +0100
Subject: [8u-dev] Request for approval to backport: 8037346: Need to
terminate server process if client runs into problems
In-Reply-To: <3e1e5f74-78cb-b76b-4803-b28496b8a16d@oracle.com>
References: <3e1e5f74-78cb-b76b-4803-b28496b8a16d@oracle.com>
Message-ID: <20170516162101.GA3102@vimes>
Approved
-Rob
On 15/05/17 11:31, Ivan Gerasimov wrote:
> Hello!
>
> Would you please approve this backport of this test-only fix which improves
> stability of three security tests?
> The unshuffled patch applies cleanly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8037346
> Jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a94a8944bd2b
> Jdk9 review:
> http://mail.openjdk.java.net/pipermail/security-dev/2014-March/010320.html
>
> Thanks in advance!
>
> --
> With kind regards,
> Ivan Gerasimov
>
From rob.mckenna at oracle.com Tue May 16 16:22:00 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 May 2017 17:22:00 +0100
Subject: [8u] RFA: JDK-8173664 : Typo in
https://java.net/downloads/heap-snapshot/hprof-binary-format.html
In-Reply-To: <8821106d-1b48-4a2f-ba51-43962bfd1630@default>
References: <3589ee08-6dba-4554-9e14-1d520d1cffbb@default>
<8821106d-1b48-4a2f-ba51-43962bfd1630@default>
Message-ID: <20170516162200.GB3102@vimes>
Approved
-Rob
On 15/05/17 11:36, Fairoz Matte wrote:
> Hi,
>
> Sorry for sending the old webrev,
> Updated webrev - http://cr.openjdk.java.net/~rpatil/8173664/webrev.01/
>
> Thanks,
> Fairoz
>
> > -----Original Message-----
> > From: Fairoz Matte
> > Sent: Monday, May 15, 2017 9:37 AM
> > To: jdk8u-dev at openjdk.java.net
> > Subject: [8u] RFA: JDK-8173664 : Typo in https://java.net/downloads/heap-
> > snapshot/hprof-binary-format.html
> >
> > Hi,
> >
> > Can I get approval to push JDK-8173664 fix to 8udev.
> > Bug - https://bugs.openjdk.java.net/browse/JDK-8173664
> > Webrev - http://cr.openjdk.java.net/~rpatil/8173664/webrev/
> > Review thread - http://mail.openjdk.java.net/pipermail/serviceability-
> > dev/2017-May/021294.html
> >
> > Thanks,
> > Fairoz
From rob.mckenna at oracle.com Tue May 16 16:24:42 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 May 2017 17:24:42 +0100
Subject: [8u Backport] RFR: 8175345: possible null pointer dereference
defects
In-Reply-To: <38de2381-67bc-44d0-b0a8-a14dcd914a0e@default>
References: <38de2381-67bc-44d0-b0a8-a14dcd914a0e@default>
Message-ID: <20170516162442.GC3102@vimes>
Updated subject line to reflect the correct bug id.
Rahul, for future requests, please only refer to the main bug id.
Approved
-Rob
On 15/05/17 11:50, Rahul Raghavan wrote:
> Hi,
>
> Request for approval -
> - http://cr.openjdk.java.net/~rraghavan/8175345/webrev.01/
>
> - '49 Null pointer dereference defect groups in 21 files' -
> https://bugs.openjdk.java.net/browse/JDK-8177429
> Backport of -
> https://bugs.openjdk.java.net/browse/JDK-8175345
>
> With 8175345, the changes done in jdk9 were reviewed in open and committed.
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025798.html
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/55e3f1f3d0a7
>
> This backport fix is same as in jdk9.
>
> Thanks,
> Rahul
From rob.mckenna at oracle.com Tue May 16 16:26:14 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 May 2017 17:26:14 +0100
Subject: [8u-dev] Request for approval 8175915: NullPointerException from
JComboBox and JList when Accessibility enabled
In-Reply-To:
References:
Message-ID: <20170516162614.GD3102@vimes>
Approved
-Rob
On 16/05/17 01:15, Alexey Ivanov wrote:
> Hello,
>
> Could you please approve the following backport to jdk8u-dev?
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8175915
> Webrev: http://cr.openjdk.java.net/~mcherkas/8175915/webrev/
> Review:
> http://mail.openjdk.java.net/pipermail/swing-dev/2017-May/007335.html
>
> JDK 9 changeset:
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/828d3f3728a2
>
>
> The patch applies cleanly to jdk8u-dev after paths unshuffling.
>
>
> Thanks,
> Alexey
From rob.mckenna at oracle.com Tue May 16 17:08:21 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 May 2017 18:08:21 +0100
Subject: [8u Backport] RFR: 8175345: possible null pointer dereference
defects
In-Reply-To: <20170516162442.GC3102@vimes>
References: <38de2381-67bc-44d0-b0a8-a14dcd914a0e@default>
<20170516162442.GC3102@vimes>
Message-ID: <20170516170821.GE3102@vimes>
..also please add a suitable noreg label to the main bug.
-Rob
On 16/05/17 05:24, Rob McKenna wrote:
> Updated subject line to reflect the correct bug id.
>
> Rahul, for future requests, please only refer to the main bug id.
>
> Approved
>
> -Rob
>
> On 15/05/17 11:50, Rahul Raghavan wrote:
> > Hi,
> >
> > Request for approval -
> > - http://cr.openjdk.java.net/~rraghavan/8175345/webrev.01/
> >
> > - '49 Null pointer dereference defect groups in 21 files' -
> > https://bugs.openjdk.java.net/browse/JDK-8177429
> > Backport of -
> > https://bugs.openjdk.java.net/browse/JDK-8175345
> >
> > With 8175345, the changes done in jdk9 were reviewed in open and committed.
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025798.html
> > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/55e3f1f3d0a7
> >
> > This backport fix is same as in jdk9.
> >
> > Thanks,
> > Rahul
From david.holmes at oracle.com Wed May 17 00:57:40 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 May 2017 10:57:40 +1000
Subject: [8u] RFA: 8179515: Class java.util.concurrent.ThreadLocalRandom fails
to Initialize when using SecurityManager
Message-ID: <486c581c-4848-9d87-b4af-6a8ac7a2b9d1@oracle.com>
Please approve this simple backport for 8u. As there was a difference
between the original 8u and 9 code I had it re-reviewed:
webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev.8u/
Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb4cdc198dc0
9 review thread:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047615.html
8u review:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047661.html
Thanks,
David
From rahul.v.raghavan at oracle.com Wed May 17 04:38:40 2017
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Tue, 16 May 2017 21:38:40 -0700 (PDT)
Subject: [8u Backport] RFR: 8175345: possible null pointer dereference
defects
In-Reply-To: <20170516162442.GC3102@vimes>
References: <38de2381-67bc-44d0-b0a8-a14dcd914a0e@default>
<20170516162442.GC3102@vimes>
Message-ID: <5e1af426-fc1c-474c-889f-2cc84f430a01@default>
> -----Original Message-----
> From: Rob McKenna > Sent: Tuesday, May 16, 2017 9:55 PM
>
> Updated subject line to reflect the correct bug id.
>
> Rahul, for future requests, please only refer to the main bug id.
Okay, thank you Rob.
-Rahul
>
> Approved
>
> -Rob
>
> On 15/05/17 11:50, Rahul Raghavan wrote:
> > Hi,
> >
> > Request for approval -
> > - http://cr.openjdk.java.net/~rraghavan/8175345/webrev.01/
> >
> > - '49 Null pointer dereference defect groups in 21 files' -
> > https://bugs.openjdk.java.net/browse/JDK-8177429
> > Backport of -
> > https://bugs.openjdk.java.net/browse/JDK-8175345
> >
> > With 8175345, the changes done in jdk9 were reviewed in open and committed.
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025798.html
> > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/55e3f1f3d0a7
> >
> > This backport fix is same as in jdk9.
> >
> > Thanks,
> > Rahul
From rahul.v.raghavan at oracle.com Wed May 17 04:44:05 2017
From: rahul.v.raghavan at oracle.com (Rahul Raghavan)
Date: Tue, 16 May 2017 21:44:05 -0700 (PDT)
Subject: [8u Backport] RFR: 8175345: possible null pointer dereference
defects
In-Reply-To: <20170516170821.GE3102@vimes>
References: <38de2381-67bc-44d0-b0a8-a14dcd914a0e@default>
<20170516162442.GC3102@vimes> <20170516170821.GE3102@vimes>
Message-ID:
> -----Original Message-----
> From: Rob McKenna > Sent: Tuesday, May 16, 2017 10:38 PM
>
> ...also please add a suitable noreg label to the main bug.
Done, thank you.
-Rahul
>
> -Rob
>
> On 16/05/17 05:24, Rob McKenna wrote:
> > Updated subject line to reflect the correct bug id.
> >
> > Rahul, for future requests, please only refer to the main bug id.
> >
> > Approved
> >
> > -Rob
> >
> > On 15/05/17 11:50, Rahul Raghavan wrote:
> > > Hi,
> > >
> > > Request for approval -
> > > - http://cr.openjdk.java.net/~rraghavan/8175345/webrev.01/
> > >
> > > - '49 Null pointer dereference defect groups in 21 files' -
> > > https://bugs.openjdk.java.net/browse/JDK-8177429
> > > Backport of -
> > > https://bugs.openjdk.java.net/browse/JDK-8175345
> > >
> > > With 8175345, the changes done in jdk9 were reviewed in open and committed.
> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-March/025798.html
> > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/55e3f1f3d0a7
> > >
> > > This backport fix is same as in jdk9.
> > >
> > > Thanks,
> > > Rahul
From rob.mckenna at oracle.com Wed May 17 13:07:21 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 17 May 2017 14:07:21 +0100
Subject: [8u] RFA: 8179515: Class java.util.concurrent.ThreadLocalRandom
fails to Initialize when using SecurityManager
In-Reply-To: <486c581c-4848-9d87-b4af-6a8ac7a2b9d1@oracle.com>
References: <486c581c-4848-9d87-b4af-6a8ac7a2b9d1@oracle.com>
Message-ID: <20170517130721.GA5160@vimes>
Approved
-Rob
On 17/05/17 10:57, David Holmes wrote:
> Please approve this simple backport for 8u. As there was a difference
> between the original 8u and 9 code I had it re-reviewed:
>
> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev.8u/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
> 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb4cdc198dc0
> 9 review thread:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047615.html
> 8u review:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047661.html
>
> Thanks,
> David
From david.holmes at oracle.com Wed May 17 13:16:09 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 May 2017 23:16:09 +1000
Subject: [8u] RFA: 8179515: Class java.util.concurrent.ThreadLocalRandom
fails to Initialize when using SecurityManager
In-Reply-To: <20170517130721.GA5160@vimes>
References: <486c581c-4848-9d87-b4af-6a8ac7a2b9d1@oracle.com>
<20170517130721.GA5160@vimes>
Message-ID:
Thanks Rob!
David
On 17/05/2017 11:07 PM, Rob McKenna wrote:
> Approved
>
> -Rob
>
> On 17/05/17 10:57, David Holmes wrote:
>> Please approve this simple backport for 8u. As there was a difference
>> between the original 8u and 9 code I had it re-reviewed:
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev.8u/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
>> 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb4cdc198dc0
>> 9 review thread:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047615.html
>> 8u review:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047661.html
>>
>> Thanks,
>> David
From gromero at linux.vnet.ibm.com Wed May 17 22:36:13 2017
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 17 May 2017 19:36:13 -0300
Subject: RFR (S) 8175813: PPC64: "mbind: Invalid argument" when -XX:+UseNUMA
is used
Message-ID: <591CD05D.3050909@linux.vnet.ibm.com>
Hi,
Could the following webrev be reviewed, please?
webrev : http://cr.openjdk.java.net/~gromero/8175813/backport/
bug : https://bugs.openjdk.java.net/browse/JDK-8175813
review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026788.html
It's a backport of 8175813, which fixes JVM numa detection on PPC64.
Currently there is no Linux distros that package only libnuma v1, so libnuma api
v2 (used in that change) is always available.
I understand that it's correct to proceed to request an approval to backport it
to 8u once reviewed and already in 10 before getting it into 9 [1].
Thank you and best regards,
Gustavo
[1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-March/006512.html
From david.holmes at oracle.com Wed May 17 22:42:34 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 08:42:34 +1000
Subject: RFR (S) 8175813: PPC64: "mbind: Invalid argument" when
-XX:+UseNUMA is used
In-Reply-To: <591CD05D.3050909@linux.vnet.ibm.com>
References: <591CD05D.3050909@linux.vnet.ibm.com>
Message-ID:
Hi Gustavo,
If this is a request for review because the backport didn't apply
cleanly then it should be reviewed on the hotspot mailing lists. A link
to that review thread should be included in the RFA.
If this is intended to be a request for approval then it is in the wrong
format.
Thanks,
David
On 18/05/2017 8:36 AM, Gustavo Romero wrote:
> Hi,
>
> Could the following webrev be reviewed, please?
>
> webrev : http://cr.openjdk.java.net/~gromero/8175813/backport/
> bug : https://bugs.openjdk.java.net/browse/JDK-8175813
> review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026788.html
>
> It's a backport of 8175813, which fixes JVM numa detection on PPC64.
>
> Currently there is no Linux distros that package only libnuma v1, so libnuma api
> v2 (used in that change) is always available.
>
> I understand that it's correct to proceed to request an approval to backport it
> to 8u once reviewed and already in 10 before getting it into 9 [1].
>
> Thank you and best regards,
> Gustavo
>
> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-March/006512.html
>
From leo.yang159 at gmail.com Thu May 18 07:35:02 2017
From: leo.yang159 at gmail.com (leo yang)
Date: Thu, 18 May 2017 15:35:02 +0800
Subject: deploy.jar
Message-ID:
I can find "lib/deploy.jar" in Oracle JDK. But I build openjdk for
8u132-b00 and I don't found this jar. Do I need to add any parameters when
building openjdk?
From sean.coffey at oracle.com Thu May 18 08:51:16 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 18 May 2017 09:51:16 +0100
Subject: deploy.jar
In-Reply-To:
References:
Message-ID: <4eb8fdff-f4e5-af4f-4492-ef4c1a68292c@oracle.com>
The deploy stack is not part of the OpenJDK Project.
regards,
Sean.
On 18/05/2017 08:35, leo yang wrote:
> I can find "lib/deploy.jar" in Oracle JDK. But I build openjdk for
> 8u132-b00 and I don't found this jar. Do I need to add any parameters when
> building openjdk?
From thomas.schatzl at oracle.com Thu May 18 17:35:12 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 18 May 2017 19:35:12 +0200
Subject: [8u] Request for Approval for backport of 8180048: Interned string
and symbol table leak memory during parallel unlinking
Message-ID: <1495128912.2701.7.camel@oracle.com>
Hi all,
? could you please approve the backport of JDK-8180048 to 8u-dev?
This fixes a serious memory leak in G1.
Bug:?https://bugs.openjdk.java.net/browse/JDK-8180048
Webrev:?http://cr.openjdk.java.net/~tschatzl/8180048-8u/webrev/
Review thread (8u):?http://mail.openjdk.java.net/pipermail/hotspot-gc-d
ev/2017-May/019872.html
Original webrev (9):?http://cr.openjdk.java.net/~tschatzl/8180048/webre
v.2/
Review thread (9):?http://mail.openjdk.java.net/pipermail/hotspot-gc-de
v/2017-May/019855.html
Patch from 9 does not apply cleanly because of cleanup done in the
meantime (split of symbolTable.?pp into symbolTable/stringTable.?pp,
and removal of some code in 9).
Thanks,
? Thomas
From rob.mckenna at oracle.com Thu May 18 18:39:07 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 18 May 2017 19:39:07 +0100
Subject: [8u] Request for Approval for backport of 8180048: Interned
string and symbol table leak memory during parallel unlinking
In-Reply-To: <1495128912.2701.7.camel@oracle.com>
References: <1495128912.2701.7.camel@oracle.com>
Message-ID: <20170518183907.GA3106@vimes>
If the patch requires changes it will need a separate review on 8.
-Rob
On 18/05/17 07:35, Thomas Schatzl wrote:
> Hi all,
>
> ? could you please approve the backport of JDK-8180048 to 8u-dev?
>
> This fixes a serious memory leak in G1.
>
> Bug:?https://bugs.openjdk.java.net/browse/JDK-8180048
> Webrev:?http://cr.openjdk.java.net/~tschatzl/8180048-8u/webrev/
> Review thread (8u):?http://mail.openjdk.java.net/pipermail/hotspot-gc-d
> ev/2017-May/019872.html
> Original webrev (9):?http://cr.openjdk.java.net/~tschatzl/8180048/webre
> v.2/
> Review thread (9):?http://mail.openjdk.java.net/pipermail/hotspot-gc-de
> v/2017-May/019855.html
>
> Patch from 9 does not apply cleanly because of cleanup done in the
> meantime (split of symbolTable.?pp into symbolTable/stringTable.?pp,
> and removal of some code in 9).
>
> Thanks,
> ? Thomas
>
From thomas.schatzl at oracle.com Thu May 18 19:16:08 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 18 May 2017 21:16:08 +0200
Subject: [8u] Request for Approval for backport of 8180048: Interned
string and symbol table leak memory during parallel unlinking
In-Reply-To: <20170518183907.GA3106@vimes>
References: <1495128912.2701.7.camel@oracle.com> <20170518183907.GA3106@vimes>
Message-ID: <1495134968.2701.12.camel@oracle.com>
Hi,
On Thu, 2017-05-18 at 19:39 +0100, Rob McKenna wrote:
> If the patch requires changes it will need a separate review on 8.
>
? the email contained the webrev and review threads with the necessary
Reviewer approvals for both 8u and 9 already.
See below.
If you need more, please tell me.
Thanks,
? Thomas
> ????-Rob
>
> On 18/05/17 07:35, Thomas Schatzl wrote:
> >
> > Hi all,
> >
> > ? could you please approve the backport of JDK-8180048 to 8u-dev?
> >
> > This fixes a serious memory leak in G1.
> >
> > Bug:?https://bugs.openjdk.java.net/browse/JDK-8180048
> > Webrev:?http://cr.openjdk.java.net/~tschatzl/8180048-8u/webrev/
> > Review thread (8u):?http://mail.openjdk.java.net/pipermail/hotspot-
> > gc-dev/2017-May/019872.html
^^^^ here
> > Original webrev
> > (9):?http://cr.openjdk.java.net/~tschatzl/8180048/webrev.2/
> > Review thread (9):?http://mail.openjdk.java.net/pipermail/hotspot-
> > gc-dev/2017-May/019855.html
> >
> > Patch from 9 does not apply cleanly because of cleanup done in the
> > meantime (split of symbolTable.?pp into
> > symbolTable/stringTable.?pp, and removal of some code in 9).
> >
> > Thanks,
> > ? Thomas
> >
From rob.mckenna at oracle.com Thu May 18 19:51:16 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 18 May 2017 20:51:16 +0100
Subject: [8u] Request for Approval for backport of 8180048: Interned
string and symbol table leak memory during parallel unlinking
In-Reply-To: <1495134968.2701.12.camel@oracle.com>
References: <1495128912.2701.7.camel@oracle.com> <20170518183907.GA3106@vimes>
<1495134968.2701.12.camel@oracle.com>
Message-ID: <20170518195116.GB3106@vimes>
Apologies, I had overlooked that.
Approved
-Rob
On 18/05/17 09:16, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2017-05-18 at 19:39 +0100, Rob McKenna wrote:
> > If the patch requires changes it will need a separate review on 8.
> >
>
> ? the email contained the webrev and review threads with the necessary
> Reviewer approvals for both 8u and 9 already.
>
> See below.
>
> If you need more, please tell me.
>
> Thanks,
> ? Thomas
>
> > ????-Rob
> >
> > On 18/05/17 07:35, Thomas Schatzl wrote:
> > >
> > > Hi all,
> > >
> > > ? could you please approve the backport of JDK-8180048 to 8u-dev?
> > >
> > > This fixes a serious memory leak in G1.
> > >
> > > Bug:?https://bugs.openjdk.java.net/browse/JDK-8180048
> > > Webrev:?http://cr.openjdk.java.net/~tschatzl/8180048-8u/webrev/
> > > Review thread (8u):?http://mail.openjdk.java.net/pipermail/hotspot-
> > > gc-dev/2017-May/019872.html
>
> ^^^^ here
>
> > > Original webrev
> > > (9):?http://cr.openjdk.java.net/~tschatzl/8180048/webrev.2/
> > > Review thread (9):?http://mail.openjdk.java.net/pipermail/hotspot-
> > > gc-dev/2017-May/019855.html
> > >
> > > Patch from 9 does not apply cleanly because of cleanup done in the
> > > meantime (split of symbolTable.?pp into
> > > symbolTable/stringTable.?pp, and removal of some code in 9).
> > >
> > > Thanks,
> > > ? Thomas
> > >
From szeryf12pietra at gmail.com Thu May 18 21:16:34 2017
From: szeryf12pietra at gmail.com (Maciej Kozlowski)
Date: Thu, 18 May 2017 23:16:34 +0200
Subject: What is current OpenJDK 8 stable release?
Message-ID:
Hello,
We use OpenJDK 8 on Windows (we compile it) in our project. We want to
update it regularly and we want to use stable version. Up to 8u112 version,
every 3 months new 8uXXX version was reaching GA (according to
http://openjdk.java.net/projects/jdk8u/, it was consistent and predictable.
Currently we are confused, because:
- on http://openjdk.java.net/projects/jdk8u/ last relased version is 8u112
(released 7 months ago) and next is to be 8u152 with "TBD" GA date
- webpage for 8u122 exist -
http://openjdk.java.net/projects/jdk8u/releases/8u122.html
- http://hg.openjdk.java.net/jdk8u/jdk8u/tags contain tags for 8u131 and
Oracle Java 8u131 is available.
So which version of OpenJDK 8 is latest stable: 8u112, 8u122 or 8u131?
Thanks,
Jan
From ivan.gerasimov at oracle.com Fri May 19 16:25:56 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 19 May 2017 09:25:56 -0700
Subject: [jdk8u-dev] Review Request and Approval to Backport: 8140436: Support
the FFDHE TLS extension
Message-ID: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com>
Hello!
The backport didn't apply cleanly, but was mostly straight-forward.
Could you please help review it and, once reviewed, approve for
integrating into jdk8u-dev codebase?
Bug: https://bugs.openjdk.java.net/browse/JDK-8140436
Jdk10 change: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/87290d66b649
Jdk10 review:
http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015790.html
Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8140436/00/webrev/
Thanks in advance!
--
With kind regards,
Ivan Gerasimov
From sean.coffey at oracle.com Mon May 22 08:30:03 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 22 May 2017 09:30:03 +0100
Subject: [jdk8u-dev] Review Request and Approval to Backport: 8140436:
Support the FFDHE TLS extension
In-Reply-To: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com>
References: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com>
Message-ID:
Ivan,
this is an enhancement backport request for jdk8u. As a result, it's
subject to extra steps before push approval can be considered. See Rule 3 :
http://openjdk.java.net/projects/jdk8u/groundrules.html
regards,
Sean.
On 19/05/2017 17:25, Ivan Gerasimov wrote:
> Hello!
>
> The backport didn't apply cleanly, but was mostly straight-forward.
>
> Could you please help review it and, once reviewed, approve for
> integrating into jdk8u-dev codebase?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8140436
> Jdk10 change: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/87290d66b649
> Jdk10 review:
> http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015790.html
>
> Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8140436/00/webrev/
>
> Thanks in advance!
>
From thomas.schatzl at oracle.com Mon May 22 08:30:41 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 22 May 2017 10:30:41 +0200
Subject: [8u] Request for Approval for backport of 8180048: Interned
string and symbol table leak memory during parallel unlinking
In-Reply-To: <20170518195116.GB3106@vimes>
References: <1495128912.2701.7.camel@oracle.com>
<20170518183907.GA3106@vimes> <1495134968.2701.12.camel@oracle.com>
<20170518195116.GB3106@vimes>
Message-ID: <1495441841.2573.27.camel@oracle.com>
Hi Rob,
On Thu, 2017-05-18 at 20:51 +0100, Rob McKenna wrote:
> Apologies, I had overlooked that.
>
> Approved
>
> ????-Rob
? thanks.
Thomas
From ivan.gerasimov at oracle.com Tue May 23 04:12:08 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 22 May 2017 21:12:08 -0700
Subject: [8u-dev] Request for enhancement backport approval for CR 8140436 :
Support the FFDHE TLS extension
In-Reply-To:
References: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com>
Message-ID:
Re-sending with the correctly formatted Subject.
Justification for the enhancement backport: This enhancement will allow
to define the required strength of DHE key exchange in all releases of JDK.
With kind regards,
Ivan
On 5/22/17 1:30 AM, Se?n Coffey wrote:
> Ivan,
>
> this is an enhancement backport request for jdk8u. As a result, it's
> subject to extra steps before push approval can be considered. See
> Rule 3 :
>
> http://openjdk.java.net/projects/jdk8u/groundrules.html
>
> regards,
> Sean.
>
> On 19/05/2017 17:25, Ivan Gerasimov wrote:
>> Hello!
>>
>> The backport didn't apply cleanly, but was mostly straight-forward.
>>
>> Could you please help review it and, once reviewed, approve for
>> integrating into jdk8u-dev codebase?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140436
>> Jdk10 change:
>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/87290d66b649
>> Jdk10 review:
>> http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015790.html
>>
>> Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8140436/00/webrev/
>>
>> Thanks in advance!
>>
>
>
--
With kind regards,
Ivan Gerasimov
From martijnverburg at gmail.com Tue May 23 14:19:37 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 23 May 2017 15:19:37 +0100
Subject: Version strings and update build numbers (determining when an update
release goes GA)
Message-ID:
Hi all,
The Adopt OpenJDK community has created an OpenJDK Build farm
for as many platforms as possible in order
to assist with early testing of things like backported patches in jdk8u.
We have a question on update and build numbers currently used in tags.
At the moment we are picking up the version string from the tag
1.8.0u152-b04, but we're a bit hesitant at making an binary release of that
particular tag as 1.8.0u152 isn't 'officially' released yet.
Is there a way to automatically tell when the update version is 'done'?
For example update 131 was released as jdk8u131-b11....
Cheers,
Martijn
From xuelei.fan at oracle.com Tue May 23 17:52:48 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 23 May 2017 10:52:48 -0700
Subject: [8u-dev] Request for enhancement backport approval for CR 8140436
: Support the FFDHE TLS extension
In-Reply-To:
References: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com>
Message-ID:
The update looks nice to me.
Thanks,
Xuelei
On 5/22/2017 9:12 PM, Ivan Gerasimov wrote:
> Re-sending with the correctly formatted Subject.
>
> Justification for the enhancement backport: This enhancement will allow
> to define the required strength of DHE key exchange in all releases of JDK.
>
> With kind regards,
> Ivan
>
> On 5/22/17 1:30 AM, Se?n Coffey wrote:
>> Ivan,
>>
>> this is an enhancement backport request for jdk8u. As a result, it's
>> subject to extra steps before push approval can be considered. See
>> Rule 3 :
>>
>> http://openjdk.java.net/projects/jdk8u/groundrules.html
>>
>> regards,
>> Sean.
>>
>> On 19/05/2017 17:25, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> The backport didn't apply cleanly, but was mostly straight-forward.
>>>
>>> Could you please help review it and, once reviewed, approve for
>>> integrating into jdk8u-dev codebase?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140436
>>> Jdk10 change:
>>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/87290d66b649
>>> Jdk10 review:
>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015790.html
>>>
>>>
>>> Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8140436/00/webrev/
>>>
>>> Thanks in advance!
>>>
>>
>>
>
From xuelei.fan at oracle.com Tue May 23 17:58:04 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 23 May 2017 10:58:04 -0700
Subject: [8u-dev] Request for enhancement backport approval for CR 8140436
: Support the FFDHE TLS extension
In-Reply-To:
References: <6e0b055c-d4d2-5e43-4585-aed1ab66976b@oracle.com>
Message-ID: <209d7862-b3af-1395-5efb-dc97c279ff95@oracle.com>
Please get the enhancement backport approval too.
On 5/23/2017 10:52 AM, Xuelei Fan wrote:
> The update looks nice to me.
>
> Thanks,
> Xuelei
>
> On 5/22/2017 9:12 PM, Ivan Gerasimov wrote:
>> Re-sending with the correctly formatted Subject.
>>
>> Justification for the enhancement backport: This enhancement will
>> allow to define the required strength of DHE key exchange in all
>> releases of JDK.
>>
>> With kind regards,
>> Ivan
>>
>> On 5/22/17 1:30 AM, Se?n Coffey wrote:
>>> Ivan,
>>>
>>> this is an enhancement backport request for jdk8u. As a result, it's
>>> subject to extra steps before push approval can be considered. See
>>> Rule 3 :
>>>
>>> http://openjdk.java.net/projects/jdk8u/groundrules.html
>>>
>>> regards,
>>> Sean.
>>>
>>> On 19/05/2017 17:25, Ivan Gerasimov wrote:
>>>> Hello!
>>>>
>>>> The backport didn't apply cleanly, but was mostly straight-forward.
>>>>
>>>> Could you please help review it and, once reviewed, approve for
>>>> integrating into jdk8u-dev codebase?
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140436
>>>> Jdk10 change:
>>>> http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/87290d66b649
>>>> Jdk10 review:
>>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-April/015790.html
>>>>
>>>>
>>>> Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8140436/00/webrev/
>>>>
>>>> Thanks in advance!
>>>>
>>>
>>>
>>
From tobias.hartmann at oracle.com Wed May 24 10:47:17 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 24 May 2017 12:47:17 +0200
Subject: [8u-dev] 8066250:
compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java
fails product
Message-ID: <3b5a71cd-1fbe-f6b5-53d1-b474f5a03650@oracle.com>
Hi,
please approve the backport of this old test fix:
https://bugs.openjdk.java.net/browse/JDK-8066250
http://cr.openjdk.java.net/~ppunegov/tpivovarova/webrev.00/
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3c858304c7e1
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016464.html
The patch applies cleanly.
Thanks,
Tobias
From david.buck at oracle.com Wed May 24 10:54:58 2017
From: david.buck at oracle.com (David Buck)
Date: Wed, 24 May 2017 19:54:58 +0900
Subject: [8u-dev] 8066250:
compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java
fails product
In-Reply-To: <3b5a71cd-1fbe-f6b5-53d1-b474f5a03650@oracle.com>
References: <3b5a71cd-1fbe-f6b5-53d1-b474f5a03650@oracle.com>
Message-ID: <1e8dca95-632c-b1a1-f1e5-f76650bed404@oracle.com>
Hi Tobias!
Please add an appropriate noreg label to the bug report.
[ noreg bug labels ]
http://openjdk.java.net/guide/changePlanning.html#noreg
Once the noreg label is added, please consider this change approved for
push to 8u-dev.
Cheers,
-Buck
On 2017/05/24 19:47, Tobias Hartmann wrote:
> Hi,
>
> please approve the backport of this old test fix:
> https://bugs.openjdk.java.net/browse/JDK-8066250
> http://cr.openjdk.java.net/~ppunegov/tpivovarova/webrev.00/
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3c858304c7e1
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016464.html
>
> The patch applies cleanly.
>
> Thanks,
> Tobias
>
From tobias.hartmann at oracle.com Wed May 24 10:56:47 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 24 May 2017 12:56:47 +0200
Subject: [8u-dev] 8066250:
compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java
fails product
In-Reply-To: <1e8dca95-632c-b1a1-f1e5-f76650bed404@oracle.com>
References: <3b5a71cd-1fbe-f6b5-53d1-b474f5a03650@oracle.com>
<1e8dca95-632c-b1a1-f1e5-f76650bed404@oracle.com>
Message-ID: <7ee06a58-55f9-736d-3fa7-f2428c62bf04@oracle.com>
Hi,
On 24.05.2017 12:54, David Buck wrote:
> Please add an appropriate noreg label to the bug report.
Sure, done.
> Once the noreg label is added, please consider this change approved for push to 8u-dev.
Thank you!
Best regards,
Tobias
> On 2017/05/24 19:47, Tobias Hartmann wrote:
>> Hi,
>>
>> please approve the backport of this old test fix:
>> https://bugs.openjdk.java.net/browse/JDK-8066250
>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/webrev.00/
>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3c858304c7e1
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016464.html
>>
>> The patch applies cleanly.
>>
>> Thanks,
>> Tobias
>>
From gromero at linux.vnet.ibm.com Wed May 24 13:26:06 2017
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Wed, 24 May 2017 10:26:06 -0300
Subject: RFR (S) 8175813: PPC64: "mbind: Invalid argument" when
-XX:+UseNUMA is used
In-Reply-To:
References: <591CD05D.3050909@linux.vnet.ibm.com>
Message-ID: <592589EE.30506@linux.vnet.ibm.com>
Hi David
On 17-05-2017 19:42, David Holmes wrote:
> Hi Gustavo,
>
> If this is a request for review because the backport didn't apply cleanly then it should be reviewed on the hotspot mailing lists. A link to that review thread should be included in the RFA.
Yes, that's the case here. I'm re-posting it to the hotspot ML.
> If this is intended to be a request for approval then it is in the wrong format.
>
> Thanks,
> David
Thanks!
Gustavo
>
> On 18/05/2017 8:36 AM, Gustavo Romero wrote:
>> Hi,
>>
>> Could the following webrev be reviewed, please?
>>
>> webrev : http://cr.openjdk.java.net/~gromero/8175813/backport/
>> bug : https://bugs.openjdk.java.net/browse/JDK-8175813
>> review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026788.html
>>
>> It's a backport of 8175813, which fixes JVM numa detection on PPC64.
>>
>> Currently there is no Linux distros that package only libnuma v1, so libnuma api
>> v2 (used in that change) is always available.
>>
>> I understand that it's correct to proceed to request an approval to backport it
>> to 8u once reviewed and already in 10 before getting it into 9 [1].
>>
>> Thank you and best regards,
>> Gustavo
>>
>> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-March/006512.html
>>
>
From sean.coffey at oracle.com Wed May 24 14:35:58 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 24 May 2017 15:35:58 +0100
Subject: Version strings and update build numbers (determining when an
update release goes GA)
In-Reply-To:
References:
Message-ID: <320ce161-8489-c585-78f8-58ca33dd025f@oracle.com>
Martijn,
You raise a good point around how one can easily identify releases that
have shipped. From an Oracle JDK perspective, the release notes should
always state the final build number of the 'shipped' release. For now,
that's probably the safest way to match a repo tag to a shipped JDK version.
Perhaps a JBS enhancement request can be logged to track improvements in
this area. Would it make sense to add a new label to identify the final
'shipped' release ? e.g. jdk8u131-b11-GA
Regards,
Sean.
On 23/05/17 15:19, Martijn Verburg wrote:
> Hi all,
>
> The Adopt OpenJDK community has created an OpenJDK Build farm
> for as many platforms as possible in order
> to assist with early testing of things like backported patches in jdk8u.
>
> We have a question on update and build numbers currently used in tags.
>
> At the moment we are picking up the version string from the tag
> 1.8.0u152-b04, but we're a bit hesitant at making an binary release of that
> particular tag as 1.8.0u152 isn't 'officially' released yet.
>
> Is there a way to automatically tell when the update version is 'done'?
> For example update 131 was released as jdk8u131-b11....
>
> Cheers,
> Martijn
From sean.coffey at oracle.com Wed May 24 14:37:32 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 24 May 2017 15:37:32 +0100
Subject: What is current OpenJDK 8 stable release?
In-Reply-To:
References:
Message-ID:
Hi Jan,
The OpenJDK 8 Updates forest collects all patches from the Oracle
Critical Patch Update releases [1] once they become available. You
should consider such releases as stable. In general, the latest JDK
releases offered for download [2] can be considered stable. As of today,
that's 8u131.
Regards,
Sean.
[1] https://www.oracle.com/technetwork/topics/security/alerts-086861.html
[2]
http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html
On 18/05/17 22:16, Maciej Kozlowski wrote:
> Hello,
>
> We use OpenJDK 8 on Windows (we compile it) in our project. We want to
> update it regularly and we want to use stable version. Up to 8u112 version,
> every 3 months new 8uXXX version was reaching GA (according to
> http://openjdk.java.net/projects/jdk8u/, it was consistent and predictable.
>
> Currently we are confused, because:
> - on http://openjdk.java.net/projects/jdk8u/ last relased version is 8u112
> (released 7 months ago) and next is to be 8u152 with "TBD" GA date
> - webpage for 8u122 exist -
> http://openjdk.java.net/projects/jdk8u/releases/8u122.html
> - http://hg.openjdk.java.net/jdk8u/jdk8u/tags contain tags for 8u131 and
> Oracle Java 8u131 is available.
>
> So which version of OpenJDK 8 is latest stable: 8u112, 8u122 or 8u131?
>
> Thanks,
> Jan
From dalibor.topic at oracle.com Wed May 24 14:56:48 2017
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Wed, 24 May 2017 07:56:48 -0700
Subject: Version strings and update build numbers (determining when an
update release goes GA)
In-Reply-To:
References:
Message-ID: <00BB8CA9-D54E-4A0D-A02A-A1979B78B830@oracle.com>
We provide that information in the communication announcing a specific release. See http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005740.html for an example.
We don't provide separate communication announcing CPU releases on this mailing list, though, as they are not specifically produced by this Project.
Cheers,
Dalibor Topic
--
Dalibor Topic | Principal Product Manager
Phone: +494089091214 | Mobile: +491737185961
ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
Oracle is committed to developing
practices and products that help protect the environment
> On 23. May 2017, at 07:19, Martijn Verburg wrote:
>
> Hi all,
>
> The Adopt OpenJDK community has created an OpenJDK Build farm
> for as many platforms as possible in order
> to assist with early testing of things like backported patches in jdk8u.
>
> We have a question on update and build numbers currently used in tags.
>
> At the moment we are picking up the version string from the tag
> 1.8.0u152-b04, but we're a bit hesitant at making an binary release of that
> particular tag as 1.8.0u152 isn't 'officially' released yet.
>
> Is there a way to automatically tell when the update version is 'done'?
> For example update 131 was released as jdk8u131-b11....
>
> Cheers,
> Martijn
From martijnverburg at gmail.com Wed May 24 15:04:07 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 24 May 2017 16:04:07 +0100
Subject: What is current OpenJDK 8 stable release?
In-Reply-To:
References:
Message-ID:
Ah, I hadn't seen this thread earlier, but it ties into a question we had
as well.
"Is there anyway of automatically telling from Mercurial that a particular
update release is the one that's available for GA?"
For example jdk1.8.0_131-b01 (an earlier cut) vs jdk1.8.0_131-b11 (GA)
Cheers,
Martijn
On 24 May 2017 at 15:37, Se?n Coffey wrote:
> Hi Jan,
>
> The OpenJDK 8 Updates forest collects all patches from the Oracle Critical
> Patch Update releases [1] once they become available. You should consider
> such releases as stable. In general, the latest JDK releases offered for
> download [2] can be considered stable. As of today, that's 8u131.
>
> Regards,
> Sean.
>
> [1] https://www.oracle.com/technetwork/topics/security/alerts-086861.html
> [2] http://www.oracle.com/technetwork/java/javase/downloads/
> index-jsp-138363.html
>
> On 18/05/17 22:16, Maciej Kozlowski wrote:
>
>> Hello,
>>
>> We use OpenJDK 8 on Windows (we compile it) in our project. We want to
>> update it regularly and we want to use stable version. Up to 8u112
>> version,
>> every 3 months new 8uXXX version was reaching GA (according to
>> http://openjdk.java.net/projects/jdk8u/, it was consistent and
>> predictable.
>>
>> Currently we are confused, because:
>> - on http://openjdk.java.net/projects/jdk8u/ last relased version is
>> 8u112
>> (released 7 months ago) and next is to be 8u152 with "TBD" GA date
>> - webpage for 8u122 exist -
>> http://openjdk.java.net/projects/jdk8u/releases/8u122.html
>> - http://hg.openjdk.java.net/jdk8u/jdk8u/tags contain tags for 8u131 and
>> Oracle Java 8u131 is available.
>>
>> So which version of OpenJDK 8 is latest stable: 8u112, 8u122 or 8u131?
>>
>> Thanks,
>> Jan
>>
>
>
From martijnverburg at gmail.com Wed May 24 15:04:44 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 24 May 2017 16:04:44 +0100
Subject: What is current OpenJDK 8 stable release?
In-Reply-To:
References:
Message-ID:
Ah heck, saw the other thread got updated, apologies all.
Cheers,
Martijn
On 24 May 2017 at 16:04, Martijn Verburg wrote:
> Ah, I hadn't seen this thread earlier, but it ties into a question we had
> as well.
>
> "Is there anyway of automatically telling from Mercurial that a particular
> update release is the one that's available for GA?"
>
> For example jdk1.8.0_131-b01 (an earlier cut) vs jdk1.8.0_131-b11 (GA)
>
> Cheers,
> Martijn
>
> On 24 May 2017 at 15:37, Se?n Coffey wrote:
>
>> Hi Jan,
>>
>> The OpenJDK 8 Updates forest collects all patches from the Oracle
>> Critical Patch Update releases [1] once they become available. You should
>> consider such releases as stable. In general, the latest JDK releases
>> offered for download [2] can be considered stable. As of today, that's
>> 8u131.
>>
>> Regards,
>> Sean.
>>
>> [1] https://www.oracle.com/technetwork/topics/security/alerts-086861.html
>> [2] http://www.oracle.com/technetwork/java/javase/downloads/inde
>> x-jsp-138363.html
>>
>> On 18/05/17 22:16, Maciej Kozlowski wrote:
>>
>>> Hello,
>>>
>>> We use OpenJDK 8 on Windows (we compile it) in our project. We want to
>>> update it regularly and we want to use stable version. Up to 8u112
>>> version,
>>> every 3 months new 8uXXX version was reaching GA (according to
>>> http://openjdk.java.net/projects/jdk8u/, it was consistent and
>>> predictable.
>>>
>>> Currently we are confused, because:
>>> - on http://openjdk.java.net/projects/jdk8u/ last relased version is
>>> 8u112
>>> (released 7 months ago) and next is to be 8u152 with "TBD" GA date
>>> - webpage for 8u122 exist -
>>> http://openjdk.java.net/projects/jdk8u/releases/8u122.html
>>> - http://hg.openjdk.java.net/jdk8u/jdk8u/tags contain tags for 8u131 and
>>> Oracle Java 8u131 is available.
>>>
>>> So which version of OpenJDK 8 is latest stable: 8u112, 8u122 or 8u131?
>>>
>>> Thanks,
>>> Jan
>>>
>>
>>
>
From dalibor.topic at oracle.com Wed May 24 15:05:56 2017
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Wed, 24 May 2017 08:05:56 -0700
Subject: What is current OpenJDK 8 stable release?
In-Reply-To:
References:
Message-ID: <6E5087B2-3FAA-4DDB-8F2E-7C4CB8FBA16E@oracle.com>
To add to what Sean said, 8u112 was the last release produced completely within this Project.
While this Project consumes changes from CPUs and SAs as they are made available to it, there's no dedicated release corresponding to a CPU release, as due to their sensitive nature, such releases can not be completely produced within this Project.
Cheers,
Dalibor Topic
--
Dalibor Topic | Principal Product Manager
Phone: +494089091214 | Mobile: +491737185961
ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
Oracle is committed to developing
practices and products that help protect the environment
> On 24. May 2017, at 07:37, Se?n Coffey wrote:
>
> Hi Jan,
>
> The OpenJDK 8 Updates forest collects all patches from the Oracle Critical Patch Update releases [1] once they become available. You should consider such releases as stable. In general, the latest JDK releases offered for download [2] can be considered stable. As of today, that's 8u131.
>
> Regards,
> Sean.
>
> [1] https://www.oracle.com/technetwork/topics/security/alerts-086861.html
> [2] http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html
>
>> On 18/05/17 22:16, Maciej Kozlowski wrote:
>> Hello,
>>
>> We use OpenJDK 8 on Windows (we compile it) in our project. We want to
>> update it regularly and we want to use stable version. Up to 8u112 version,
>> every 3 months new 8uXXX version was reaching GA (according to
>> http://openjdk.java.net/projects/jdk8u/, it was consistent and predictable.
>>
>> Currently we are confused, because:
>> - on http://openjdk.java.net/projects/jdk8u/ last relased version is 8u112
>> (released 7 months ago) and next is to be 8u152 with "TBD" GA date
>> - webpage for 8u122 exist -
>> http://openjdk.java.net/projects/jdk8u/releases/8u122.html
>> - http://hg.openjdk.java.net/jdk8u/jdk8u/tags contain tags for 8u131 and
>> Oracle Java 8u131 is available.
>>
>> So which version of OpenJDK 8 is latest stable: 8u112, 8u122 or 8u131?
>>
>> Thanks,
>> Jan
>
From martijnverburg at gmail.com Wed May 24 15:06:12 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 24 May 2017 16:06:12 +0100
Subject: Version strings and update build numbers (determining when an
update release goes GA)
In-Reply-To: <320ce161-8489-c585-78f8-58ca33dd025f@oracle.com>
References:
<320ce161-8489-c585-78f8-58ca33dd025f@oracle.com>
Message-ID:
Hi Sean,
An enhancement which adds GA tags for build systems like ours to pick up
would be welcome. I'm not an author so I'm not sure I can raise this issue
in the OpenJDK JIRA?
Cheers,
Martijn
On 24 May 2017 at 15:35, Se?n Coffey wrote:
> Martijn,
>
> You raise a good point around how one can easily identify releases that
> have shipped. From an Oracle JDK perspective, the release notes should
> always state the final build number of the 'shipped' release. For now,
> that's probably the safest way to match a repo tag to a shipped JDK version.
>
> Perhaps a JBS enhancement request can be logged to track improvements in
> this area. Would it make sense to add a new label to identify the final
> 'shipped' release ? e.g. jdk8u131-b11-GA
>
> Regards,
> Sean.
>
> On 23/05/17 15:19, Martijn Verburg wrote:
>
>> Hi all,
>>
>> The Adopt OpenJDK community has created an OpenJDK Build farm
>> for as many platforms as possible in order
>> to assist with early testing of things like backported patches in jdk8u.
>>
>> We have a question on update and build numbers currently used in tags.
>>
>> At the moment we are picking up the version string from the tag
>> 1.8.0u152-b04, but we're a bit hesitant at making an binary release of
>> that
>> particular tag as 1.8.0u152 isn't 'officially' released yet.
>>
>> Is there a way to automatically tell when the update version is 'done'?
>> For example update 131 was released as jdk8u131-b11....
>>
>> Cheers,
>> Martijn
>>
>
>
From gnu.andrew at redhat.com Wed May 24 15:11:32 2017
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 24 May 2017 16:11:32 +0100
Subject: What is current OpenJDK 8 stable release?
In-Reply-To:
References:
Message-ID:
On 24 May 2017 at 15:37, Se?n Coffey wrote:
> Hi Jan,
>
> The OpenJDK 8 Updates forest collects all patches from the Oracle Critical
> Patch Update releases [1] once they become available. You should consider
> such releases as stable. In general, the latest JDK releases offered for
> download [2] can be considered stable. As of today, that's 8u131.
>
It's also worth making clear that the binaries available at [2] are not OpenJDK
binaries and, as such, are subject to different licensing restrictions.
> Regards,
> Sean.
>
> [1] https://www.oracle.com/technetwork/topics/security/alerts-086861.html
> [2]
> http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html
>
> On 18/05/17 22:16, Maciej Kozlowski wrote:
>>
>> Hello,
>>
>> We use OpenJDK 8 on Windows (we compile it) in our project. We want to
>> update it regularly and we want to use stable version. Up to 8u112
>> version,
>> every 3 months new 8uXXX version was reaching GA (according to
>> http://openjdk.java.net/projects/jdk8u/, it was consistent and
>> predictable.
>>
>> Currently we are confused, because:
>> - on http://openjdk.java.net/projects/jdk8u/ last relased version is 8u112
>> (released 7 months ago) and next is to be 8u152 with "TBD" GA date
>> - webpage for 8u122 exist -
>> http://openjdk.java.net/projects/jdk8u/releases/8u122.html
>> - http://hg.openjdk.java.net/jdk8u/jdk8u/tags contain tags for 8u131 and
>> Oracle Java 8u131 is available.
>>
>> So which version of OpenJDK 8 is latest stable: 8u112, 8u122 or 8u131?
>>
8u131 as Sean says. 8u122 was cancelled and became 8u152.
If you do a clone of the tag jdk8u131-b11 from the jdk8u
repositories (http://hg.openjdk.java.net/jdk8u/jdk8u/ and friends),
you will have
the OpenJDK version of that release. Unfortunately, there's no source code
releases and I'm currently not aware of any hosting to provide them.
I'd prefer to see a new feature release (the even numbered releases) sooner
rather than later, as there hasn't been one since October (8u112) and
currently there
are a number of fixes that have been backported to the 8u trees months ago
but not released.
>> Thanks,
>> Jan
>
>
--
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.coffey at oracle.com Wed May 24 15:42:25 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 24 May 2017 16:42:25 +0100
Subject: (JDK-8180946) Re: Version strings and update build numbers
(determining when an update release goes GA)
In-Reply-To:
References:
<320ce161-8489-c585-78f8-58ca33dd025f@oracle.com>
Message-ID:
On 24/05/17 16:06, Martijn Verburg wrote:
> Hi Sean,
>
> An enhancement which adds GA tags for build systems like ours to pick
> up would be welcome. I'm not an author so I'm not sure I can raise
> this issue in the OpenJDK JIRA?
No problem Martijn. I've created
https://bugs.openjdk.java.net/browse/JDK-8180946 to track this.
regards,
Sean.
>
> Cheers,
> Martijn
>
> On 24 May 2017 at 15:35, Se?n Coffey > wrote:
>
> Martijn,
>
> You raise a good point around how one can easily identify releases
> that have shipped. From an Oracle JDK perspective, the release
> notes should always state the final build number of the 'shipped'
> release. For now, that's probably the safest way to match a repo
> tag to a shipped JDK version.
>
> Perhaps a JBS enhancement request can be logged to track
> improvements in this area. Would it make sense to add a new label
> to identify the final 'shipped' release ? e.g. jdk8u131-b11-GA
>
> Regards,
> Sean.
>
> On 23/05/17 15:19, Martijn Verburg wrote:
>
> Hi all,
>
> The Adopt OpenJDK community has created an OpenJDK Build farm
> for as many platforms as
> possible in order
> to assist with early testing of things like backported patches
> in jdk8u.
>
> We have a question on update and build numbers currently used
> in tags.
>
> At the moment we are picking up the version string from the tag
> 1.8.0u152-b04, but we're a bit hesitant at making an binary
> release of that
> particular tag as 1.8.0u152 isn't 'officially' released yet.
>
> Is there a way to automatically tell when the update version
> is 'done'?
> For example update 131 was released as jdk8u131-b11....
>
> Cheers,
> Martijn
>
>
>
From martijnverburg at gmail.com Wed May 24 15:52:40 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 24 May 2017 16:52:40 +0100
Subject: (JDK-8180946) Re: Version strings and update build numbers
(determining when an update release goes GA)
In-Reply-To:
References:
<320ce161-8489-c585-78f8-58ca33dd025f@oracle.com>
Message-ID:
Hi Sean,
Thank you. In the mean time we'll use a manual workflow to work around
this.
Cheers,
Martijn
On 24 May 2017 at 16:42, Se?n Coffey wrote:
>
> On 24/05/17 16:06, Martijn Verburg wrote:
>
> Hi Sean,
>
> An enhancement which adds GA tags for build systems like ours to pick up
> would be welcome. I'm not an author so I'm not sure I can raise this issue
> in the OpenJDK JIRA?
>
> No problem Martijn. I've created https://bugs.openjdk.java.net/
> browse/JDK-8180946 to track this.
>
> regards,
> Sean.
>
>
> Cheers,
> Martijn
>
> On 24 May 2017 at 15:35, Se?n Coffey wrote:
>
>> Martijn,
>>
>> You raise a good point around how one can easily identify releases that
>> have shipped. From an Oracle JDK perspective, the release notes should
>> always state the final build number of the 'shipped' release. For now,
>> that's probably the safest way to match a repo tag to a shipped JDK version.
>>
>> Perhaps a JBS enhancement request can be logged to track improvements in
>> this area. Would it make sense to add a new label to identify the final
>> 'shipped' release ? e.g. jdk8u131-b11-GA
>>
>> Regards,
>> Sean.
>>
>> On 23/05/17 15:19, Martijn Verburg wrote:
>>
>>> Hi all,
>>>
>>> The Adopt OpenJDK community has created an OpenJDK Build farm
>>> for as many platforms as possible in
>>> order
>>> to assist with early testing of things like backported patches in jdk8u.
>>>
>>> We have a question on update and build numbers currently used in tags.
>>>
>>> At the moment we are picking up the version string from the tag
>>> 1.8.0u152-b04, but we're a bit hesitant at making an binary release of
>>> that
>>> particular tag as 1.8.0u152 isn't 'officially' released yet.
>>>
>>> Is there a way to automatically tell when the update version is 'done'?
>>> For example update 131 was released as jdk8u131-b11....
>>>
>>> Cheers,
>>> Martijn
>>>
>>
>>
>
>
From prasadarao.koppula at oracle.com Thu May 25 07:19:42 2017
From: prasadarao.koppula at oracle.com (Prasadrao Koppula)
Date: Thu, 25 May 2017 00:19:42 -0700 (PDT)
Subject: [8u] Request for Approval for backport of 8165751: NPE hit with
java.security.debug=provider
Message-ID:
Hi all,
Could you please approve the backport of JDK-8165751 to 8u-dev?
Bug: https://bugs.openjdk.java.net/browse/JDK-8165751
JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a9fe693da587
JDK 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2016-December/015265.html
Patch from 9 apply cleanly.
Thanks,
Prasad.K
From david.buck at oracle.com Thu May 25 07:48:35 2017
From: david.buck at oracle.com (David Buck)
Date: Thu, 25 May 2017 16:48:35 +0900
Subject: [8u] Request for Approval for backport of 8165751: NPE hit with
java.security.debug=provider
In-Reply-To:
References:
Message-ID: <0d8e963e-0aa5-6195-06df-ace8148ad682@oracle.com>
approved for push to 8u-dev
Cheers,
-Buck
On 2017/05/25 16:19, Prasadrao Koppula wrote:
> Hi all,
>
>
>
> Could you please approve the backport of JDK-8165751 to 8u-dev?
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165751
>
> JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a9fe693da587
>
> JDK 9 review: http://mail.openjdk.java.net/pipermail/security-dev/2016-December/015265.html
>
>
>
> Patch from 9 apply cleanly.
>
>
>
> Thanks,
>
> Prasad.K
>
From martinrb at google.com Thu May 25 18:55:58 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 25 May 2017 11:55:58 -0700
Subject: Fwd: RFR: 8181085: Race condition in method resolution may
produce spurious NullPointerException
In-Reply-To: <7b268254-e17b-482f-071a-cb4a3e4b19f5@redhat.com>
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
<7b268254-e17b-482f-071a-cb4a3e4b19f5@redhat.com>
Message-ID:
[+jdk8u-dev]
We've been hunting the elusive spurious NPEs as well; the following seems
to be working for us (but we don't have any small repro recipe); something
like this should be put into jdk8:
--- hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp 2016-11-22
15:30:39.000000000 -0800
+++ hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp 2017-04-27
18:12:33.000000000 -0700
@@ -32,6 +32,11 @@
// Implementation of class OrderAccess.
+// A compiler barrier, forcing the C++ compiler to invalidate all memory
assumptions
+static inline void compiler_barrier() {
+ __asm__ volatile ("" : : : "memory");
+}
+
inline void OrderAccess::loadload() { acquire(); }
inline void OrderAccess::storestore() { release(); }
inline void OrderAccess::loadstore() { acquire(); }
@@ -47,9 +52,7 @@
}
inline void OrderAccess::release() {
- // Avoid hitting the same cache-line from
- // different threads.
- volatile jint local_dummy = 0;
+ compiler_barrier();
}
inline void OrderAccess::fence() {
@@ -63,34 +66,34 @@
}
}
-inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return
*p; }
-inline jshort OrderAccess::load_acquire(volatile jshort* p) { return
*p; }
-inline jint OrderAccess::load_acquire(volatile jint* p) { return
*p; }
-inline jlong OrderAccess::load_acquire(volatile jlong* p) { return
Atomic::load(p); }
-inline jubyte OrderAccess::load_acquire(volatile jubyte* p) { return
*p; }
-inline jushort OrderAccess::load_acquire(volatile jushort* p) { return
*p; }
-inline juint OrderAccess::load_acquire(volatile juint* p) { return
*p; }
-inline julong OrderAccess::load_acquire(volatile julong* p) { return
Atomic::load((volatile jlong*)p); }
-inline jfloat OrderAccess::load_acquire(volatile jfloat* p) { return
*p; }
-inline jdouble OrderAccess::load_acquire(volatile jdouble* p) { return
jdouble_cast(Atomic::load((volatile jlong*)p)); }
-
-inline intptr_t OrderAccess::load_ptr_acquire(volatile intptr_t* p) {
return *p; }
-inline void* OrderAccess::load_ptr_acquire(volatile void* p) {
return *(void* volatile *)p; }
-inline void* OrderAccess::load_ptr_acquire(const volatile void* p) {
return *(void* const volatile *)p; }
-
-inline void OrderAccess::release_store(volatile jbyte* p, jbyte v)
{ *p = v; }
-inline void OrderAccess::release_store(volatile jshort* p, jshort v)
{ *p = v; }
-inline void OrderAccess::release_store(volatile jint* p, jint v)
{ *p = v; }
-inline void OrderAccess::release_store(volatile jlong* p, jlong v)
{ Atomic::store(v, p); }
-inline void OrderAccess::release_store(volatile jubyte* p, jubyte v)
{ *p = v; }
-inline void OrderAccess::release_store(volatile jushort* p, jushort v)
{ *p = v; }
-inline void OrderAccess::release_store(volatile juint* p, juint v)
{ *p = v; }
-inline void OrderAccess::release_store(volatile julong* p, julong v)
{ Atomic::store((jlong)v, (volatile jlong*)p); }
-inline void OrderAccess::release_store(volatile jfloat* p, jfloat v)
{ *p = v; }
+inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { jbyte v
= *p; compiler_barrier(); return v; }
+inline jshort OrderAccess::load_acquire(volatile jshort* p) { jshort v
= *p; compiler_barrier(); return v; }
+inline jint OrderAccess::load_acquire(volatile jint* p) { jint v
= *p; compiler_barrier(); return v; }
+inline jlong OrderAccess::load_acquire(volatile jlong* p) { jlong v
= Atomic::load(p); compiler_barrier(); return v; }
+inline jubyte OrderAccess::load_acquire(volatile jubyte* p) { jubyte v
= *p; compiler_barrier(); return v; }
+inline jushort OrderAccess::load_acquire(volatile jushort* p) { jushort v
= *p; compiler_barrier(); return v; }
+inline juint OrderAccess::load_acquire(volatile juint* p) { juint v
= *p; compiler_barrier(); return v; }
+inline julong OrderAccess::load_acquire(volatile julong* p) { julong v
= Atomic::load((volatile jlong*)p); compiler_barrier(); return v; }
+inline jfloat OrderAccess::load_acquire(volatile jfloat* p) { jfloat v
= *p; compiler_barrier(); return v; }
+inline jdouble OrderAccess::load_acquire(volatile jdouble* p) { jdouble v
= jdouble_cast(Atomic::load((volatile jlong*)p)); compiler_barrier();
return v; }
+
+inline intptr_t OrderAccess::load_ptr_acquire(volatile intptr_t* p) {
intptr_t v = *p; compiler_barrier(); return v; }
+inline void* OrderAccess::load_ptr_acquire(volatile void* p) {
void* v = *(void* volatile *)p; compiler_barrier(); return v; }
+inline void* OrderAccess::load_ptr_acquire(const volatile void* p) {
void* v = *(void* const volatile *)p; compiler_barrier(); return v; }
+
+inline void OrderAccess::release_store(volatile jbyte* p, jbyte v)
{ compiler_barrier(); *p = v; }
+inline void OrderAccess::release_store(volatile jshort* p, jshort v)
{ compiler_barrier(); *p = v; }
+inline void OrderAccess::release_store(volatile jint* p, jint v)
{ compiler_barrier(); *p = v; }
+inline void OrderAccess::release_store(volatile jlong* p, jlong v)
{ compiler_barrier(); Atomic::store(v, p); }
+inline void OrderAccess::release_store(volatile jubyte* p, jubyte v)
{ compiler_barrier(); *p = v; }
+inline void OrderAccess::release_store(volatile jushort* p, jushort v)
{ compiler_barrier(); *p = v; }
+inline void OrderAccess::release_store(volatile juint* p, juint v)
{ compiler_barrier(); *p = v; }
+inline void OrderAccess::release_store(volatile julong* p, julong v)
{ compiler_barrier(); Atomic::store((jlong)v, (volatile jlong*)p); }
+inline void OrderAccess::release_store(volatile jfloat* p, jfloat v)
{ compiler_barrier(); *p = v; }
inline void OrderAccess::release_store(volatile jdouble* p, jdouble v)
{ release_store((volatile jlong *)p, jlong_cast(v)); }
-inline void OrderAccess::release_store_ptr(volatile intptr_t* p,
intptr_t v) { *p = v; }
-inline void OrderAccess::release_store_ptr(volatile void* p, void*
v) { *(void* volatile *)p = v; }
+inline void OrderAccess::release_store_ptr(volatile intptr_t* p,
intptr_t v) { compiler_barrier(); *p = v; }
+inline void OrderAccess::release_store_ptr(volatile void* p, void*
v) { compiler_barrier(); *(void* volatile *)p = v; }
inline void OrderAccess::store_fence(jbyte* p, jbyte v) {
__asm__ volatile ( "xchgb (%2),%0"
On Thu, May 25, 2017 at 9:25 AM, Andrew Dinn wrote:
> Apologies but this RFR is retracted -- the problem only applies to jdk8.
>
> I will be posting a revised RFR to jdk8u.
>
> 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
>
> On 25/05/17 14:16, Andrew Dinn wrote:
> > Forwarding this to hotpsot-dev which is probably the more appropriate
> > destination.
> >
> >
> > -------- Forwarded Message --------
> > Subject: RFR: 8181085: Race condition in method resolution may produce
> > spurious NullPointerException
> > Date: Thu, 25 May 2017 14:12:53 +0100
> > From: Andrew Dinn
> > To: jdk10-dev
> >
> > The following webrev fixes a race condition that is present in jdk10 and
> > also jdk9 and jdk8. It is caused by a misplaced volatile keyword that
> > faild to ensure correct ordering of writes by the compiler. Reviews
> welcome.
> >
> > http://cr.openjdk.java.net/~adinn/8181085/webrev.00/
> >
> > Backporting:
> > This same fix is required in jdk9 and jdk8.
> >
> > Testing:
> > The reproducer posted with the original issue manifests the NPE reliably
> > on jdk8. It does not manifest on jdk9/10 but that is only thanks to
> > changes introduced into the resolution process in jdk9 which change the
> > timing of execution. However, without this fix the out-of-order write
> > problem is still present in jdk9/10, as can be seen by eyeballing the
> > compiled code for ConstantPoolCacheEntry::set_direct_or_vtable_call.
> >
> > The patch has been validated on jdk8 by running the reproducer. It stops
> > any resulting NPEs.
> >
> > The code for ConstantPoolCacheEntry::set_direct_or_vtable_call on
> > jdk8-10 has been eyeballed to ensure that post-patch the assignments now
> > occur in the correct order.
> >
> > 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 david.holmes at oracle.com Fri May 26 01:04:56 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 May 2017 11:04:56 +1000
Subject: Fwd: RFR: 8181085: Race condition in method resolution may
produce spurious NullPointerException
In-Reply-To:
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
<7b268254-e17b-482f-071a-cb4a3e4b19f5@redhat.com>
Message-ID:
On 26/05/2017 4:55 AM, Martin Buchholz wrote:
> [+jdk8u-dev]
>
> We've been hunting the elusive spurious NPEs as well; the following seems
> to be working for us (but we don't have any small repro recipe); something
> like this should be put into jdk8:
In other words you want a backport of: 8061964: Insufficient compiler
barriers for GCC in OrderAccess functions ?
https://bugs.openjdk.java.net/browse/JDK-8061964
IIRC what stopped this from being an 'automatic' backport candidate was
the potential problem of older gcc's needing to be validated.
Cheers,
David
-----
> --- hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp 2016-11-22
> 15:30:39.000000000 -0800
> +++ hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp 2017-04-27
> 18:12:33.000000000 -0700
> @@ -32,6 +32,11 @@
>
> // Implementation of class OrderAccess.
>
> +// A compiler barrier, forcing the C++ compiler to invalidate all memory
> assumptions
> +static inline void compiler_barrier() {
> + __asm__ volatile ("" : : : "memory");
> +}
> +
> inline void OrderAccess::loadload() { acquire(); }
> inline void OrderAccess::storestore() { release(); }
> inline void OrderAccess::loadstore() { acquire(); }
> @@ -47,9 +52,7 @@
> }
>
> inline void OrderAccess::release() {
> - // Avoid hitting the same cache-line from
> - // different threads.
> - volatile jint local_dummy = 0;
> + compiler_barrier();
> }
>
> inline void OrderAccess::fence() {
> @@ -63,34 +66,34 @@
> }
> }
>
> -inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return
> *p; }
> -inline jshort OrderAccess::load_acquire(volatile jshort* p) { return
> *p; }
> -inline jint OrderAccess::load_acquire(volatile jint* p) { return
> *p; }
> -inline jlong OrderAccess::load_acquire(volatile jlong* p) { return
> Atomic::load(p); }
> -inline jubyte OrderAccess::load_acquire(volatile jubyte* p) { return
> *p; }
> -inline jushort OrderAccess::load_acquire(volatile jushort* p) { return
> *p; }
> -inline juint OrderAccess::load_acquire(volatile juint* p) { return
> *p; }
> -inline julong OrderAccess::load_acquire(volatile julong* p) { return
> Atomic::load((volatile jlong*)p); }
> -inline jfloat OrderAccess::load_acquire(volatile jfloat* p) { return
> *p; }
> -inline jdouble OrderAccess::load_acquire(volatile jdouble* p) { return
> jdouble_cast(Atomic::load((volatile jlong*)p)); }
> -
> -inline intptr_t OrderAccess::load_ptr_acquire(volatile intptr_t* p) {
> return *p; }
> -inline void* OrderAccess::load_ptr_acquire(volatile void* p) {
> return *(void* volatile *)p; }
> -inline void* OrderAccess::load_ptr_acquire(const volatile void* p) {
> return *(void* const volatile *)p; }
> -
> -inline void OrderAccess::release_store(volatile jbyte* p, jbyte v)
> { *p = v; }
> -inline void OrderAccess::release_store(volatile jshort* p, jshort v)
> { *p = v; }
> -inline void OrderAccess::release_store(volatile jint* p, jint v)
> { *p = v; }
> -inline void OrderAccess::release_store(volatile jlong* p, jlong v)
> { Atomic::store(v, p); }
> -inline void OrderAccess::release_store(volatile jubyte* p, jubyte v)
> { *p = v; }
> -inline void OrderAccess::release_store(volatile jushort* p, jushort v)
> { *p = v; }
> -inline void OrderAccess::release_store(volatile juint* p, juint v)
> { *p = v; }
> -inline void OrderAccess::release_store(volatile julong* p, julong v)
> { Atomic::store((jlong)v, (volatile jlong*)p); }
> -inline void OrderAccess::release_store(volatile jfloat* p, jfloat v)
> { *p = v; }
> +inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { jbyte v
> = *p; compiler_barrier(); return v; }
> +inline jshort OrderAccess::load_acquire(volatile jshort* p) { jshort v
> = *p; compiler_barrier(); return v; }
> +inline jint OrderAccess::load_acquire(volatile jint* p) { jint v
> = *p; compiler_barrier(); return v; }
> +inline jlong OrderAccess::load_acquire(volatile jlong* p) { jlong v
> = Atomic::load(p); compiler_barrier(); return v; }
> +inline jubyte OrderAccess::load_acquire(volatile jubyte* p) { jubyte v
> = *p; compiler_barrier(); return v; }
> +inline jushort OrderAccess::load_acquire(volatile jushort* p) { jushort v
> = *p; compiler_barrier(); return v; }
> +inline juint OrderAccess::load_acquire(volatile juint* p) { juint v
> = *p; compiler_barrier(); return v; }
> +inline julong OrderAccess::load_acquire(volatile julong* p) { julong v
> = Atomic::load((volatile jlong*)p); compiler_barrier(); return v; }
> +inline jfloat OrderAccess::load_acquire(volatile jfloat* p) { jfloat v
> = *p; compiler_barrier(); return v; }
> +inline jdouble OrderAccess::load_acquire(volatile jdouble* p) { jdouble v
> = jdouble_cast(Atomic::load((volatile jlong*)p)); compiler_barrier();
> return v; }
> +
> +inline intptr_t OrderAccess::load_ptr_acquire(volatile intptr_t* p) {
> intptr_t v = *p; compiler_barrier(); return v; }
> +inline void* OrderAccess::load_ptr_acquire(volatile void* p) {
> void* v = *(void* volatile *)p; compiler_barrier(); return v; }
> +inline void* OrderAccess::load_ptr_acquire(const volatile void* p) {
> void* v = *(void* const volatile *)p; compiler_barrier(); return v; }
> +
> +inline void OrderAccess::release_store(volatile jbyte* p, jbyte v)
> { compiler_barrier(); *p = v; }
> +inline void OrderAccess::release_store(volatile jshort* p, jshort v)
> { compiler_barrier(); *p = v; }
> +inline void OrderAccess::release_store(volatile jint* p, jint v)
> { compiler_barrier(); *p = v; }
> +inline void OrderAccess::release_store(volatile jlong* p, jlong v)
> { compiler_barrier(); Atomic::store(v, p); }
> +inline void OrderAccess::release_store(volatile jubyte* p, jubyte v)
> { compiler_barrier(); *p = v; }
> +inline void OrderAccess::release_store(volatile jushort* p, jushort v)
> { compiler_barrier(); *p = v; }
> +inline void OrderAccess::release_store(volatile juint* p, juint v)
> { compiler_barrier(); *p = v; }
> +inline void OrderAccess::release_store(volatile julong* p, julong v)
> { compiler_barrier(); Atomic::store((jlong)v, (volatile jlong*)p); }
> +inline void OrderAccess::release_store(volatile jfloat* p, jfloat v)
> { compiler_barrier(); *p = v; }
> inline void OrderAccess::release_store(volatile jdouble* p, jdouble v)
> { release_store((volatile jlong *)p, jlong_cast(v)); }
>
> -inline void OrderAccess::release_store_ptr(volatile intptr_t* p,
> intptr_t v) { *p = v; }
> -inline void OrderAccess::release_store_ptr(volatile void* p, void*
> v) { *(void* volatile *)p = v; }
> +inline void OrderAccess::release_store_ptr(volatile intptr_t* p,
> intptr_t v) { compiler_barrier(); *p = v; }
> +inline void OrderAccess::release_store_ptr(volatile void* p, void*
> v) { compiler_barrier(); *(void* volatile *)p = v; }
>
> inline void OrderAccess::store_fence(jbyte* p, jbyte v) {
> __asm__ volatile ( "xchgb (%2),%0"
>
>
> On Thu, May 25, 2017 at 9:25 AM, Andrew Dinn wrote:
>
>> Apologies but this RFR is retracted -- the problem only applies to jdk8.
>>
>> I will be posting a revised RFR to jdk8u.
>>
>> 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
>>
>> On 25/05/17 14:16, Andrew Dinn wrote:
>>> Forwarding this to hotpsot-dev which is probably the more appropriate
>>> destination.
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: RFR: 8181085: Race condition in method resolution may produce
>>> spurious NullPointerException
>>> Date: Thu, 25 May 2017 14:12:53 +0100
>>> From: Andrew Dinn
>>> To: jdk10-dev
>>>
>>> The following webrev fixes a race condition that is present in jdk10 and
>>> also jdk9 and jdk8. It is caused by a misplaced volatile keyword that
>>> faild to ensure correct ordering of writes by the compiler. Reviews
>> welcome.
>>>
>>> http://cr.openjdk.java.net/~adinn/8181085/webrev.00/
>>>
>>> Backporting:
>>> This same fix is required in jdk9 and jdk8.
>>>
>>> Testing:
>>> The reproducer posted with the original issue manifests the NPE reliably
>>> on jdk8. It does not manifest on jdk9/10 but that is only thanks to
>>> changes introduced into the resolution process in jdk9 which change the
>>> timing of execution. However, without this fix the out-of-order write
>>> problem is still present in jdk9/10, as can be seen by eyeballing the
>>> compiled code for ConstantPoolCacheEntry::set_direct_or_vtable_call.
>>>
>>> The patch has been validated on jdk8 by running the reproducer. It stops
>>> any resulting NPEs.
>>>
>>> The code for ConstantPoolCacheEntry::set_direct_or_vtable_call on
>>> jdk8-10 has been eyeballed to ensure that post-patch the assignments now
>>> occur in the correct order.
>>>
>>> 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 martinrb at google.com Fri May 26 01:22:44 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 25 May 2017 18:22:44 -0700
Subject: Fwd: RFR: 8181085: Race condition in method resolution may
produce spurious NullPointerException
In-Reply-To:
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
<7b268254-e17b-482f-071a-cb4a3e4b19f5@redhat.com>
Message-ID:
On Thu, May 25, 2017 at 6:04 PM, David Holmes
wrote:
> On 26/05/2017 4:55 AM, Martin Buchholz wrote:
>
>> [+jdk8u-dev]
>>
>> We've been hunting the elusive spurious NPEs as well; the following seems
>> to be working for us (but we don't have any small repro recipe); something
>> like this should be put into jdk8:
>>
>
> In other words you want a backport of: 8061964: Insufficient compiler
> barriers for GCC in OrderAccess functions ?
>
> https://bugs.openjdk.java.net/browse/JDK-8061964
>
> IIRC what stopped this from being an 'automatic' backport candidate was
> the potential problem of older gcc's needing to be validated.
>
Sure, __asm__ is non-portable, and it's easy to break other peoples'
toolchains. But "it works for us" ...
From adinn at redhat.com Fri May 26 08:29:32 2017
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 26 May 2017 09:29:32 +0100
Subject: Fwd: RFR: 8181085: Race condition in method resolution may
produce spurious NullPointerException
In-Reply-To:
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
<7b268254-e17b-482f-071a-cb4a3e4b19f5@redhat.com>
Message-ID:
On 26/05/17 02:04, David Holmes wrote:
> On 26/05/2017 4:55 AM, Martin Buchholz wrote:
>> [+jdk8u-dev]
>>
>> We've been hunting the elusive spurious NPEs as well; the following seems
>> to be working for us (but we don't have any small repro recipe);
>> something
>> like this should be put into jdk8:
>
> In other words you want a backport of: 8061964: Insufficient compiler
> barriers for GCC in OrderAccess functions ?
>
> https://bugs.openjdk.java.net/browse/JDK-8061964
Well, yes, that sounds like the 'correct' solution but ...
> IIRC what stopped this from being an 'automatic' backport candidate was
> the potential problem of older gcc's needing to be validated.
If the 'correct' fix fails because of legacy compilers then I think my
proposed change to the volatile declaration for _f1 will be sufficient
to sort that out on x86 (I am assuming none of the legacy compilers will
re-order volatile stores :-).
Of course, that's not enough in itself on AArch64 jdk8 (which Red Hat
maintain downstream) nor on ppc jdk8 but it does no harm. This may not
matter though. These two platforms *must* employ a compiler that is able
to implement OrderAccess::release_store with the correct memory
semantics because they don't provide TCO. So, I guess the legacy issue
only applies to x86 in which case maybe my patch will be good enough.
What does everyone think?
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 aph at redhat.com Fri May 26 08:33:42 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 26 May 2017 09:33:42 +0100
Subject: Fwd: RFR: 8181085: Race condition in method resolution may
produce spurious NullPointerException
In-Reply-To:
References: <092b320b-3230-cb69-99d3-1d7777723578@redhat.com>
<7b268254-e17b-482f-071a-cb4a3e4b19f5@redhat.com>
Message-ID:
On 26/05/17 09:29, Andrew Dinn wrote:
> On 26/05/17 02:04, David Holmes wrote:
>> On 26/05/2017 4:55 AM, Martin Buchholz wrote:
>>> [+jdk8u-dev]
>>>
>>> We've been hunting the elusive spurious NPEs as well; the following seems
>>> to be working for us (but we don't have any small repro recipe);
>>> something
>>> like this should be put into jdk8:
>>
>> In other words you want a backport of: 8061964: Insufficient compiler
>> barriers for GCC in OrderAccess functions ?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8061964
>
> Well, yes, that sounds like the 'correct' solution but ...
>
>> IIRC what stopped this from being an 'automatic' backport candidate was
>> the potential problem of older gcc's needing to be validated.
>
> If the 'correct' fix fails because of legacy compilers
It won't. All of the Linux kernel and all of glibc requires this mechanism
to work, and it has always worked.
Andrew.
From zoltan.majo at oracle.com Fri May 26 14:17:21 2017
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Fri, 26 May 2017 16:17:21 +0200
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
Message-ID:
Hi,
when backporting 8160551, I also backported a test that is relevant only
for class files with version >= 53. As JDK 8 supports only class files
with version < 53, having the test in the JDK 8u test base does not make
sense. This changeset proposes to remove the test.
https://bugs.openjdk.java.net/browse/JDK-8180934
http://cr.openjdk.java.net/~zmajo/8180934/webrev.00/
I executed all hotspot/runtime tests with the changeset (using JDK
8u122), no problems have shown up. JPRT testing is in progress.
Please note that this fix is a JDK 8u-specific fix (not a backport of
some existing fix in JDK 9).
Thank you!
Best regards,
Zoltan
From sean.coffey at oracle.com Fri May 26 14:38:42 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 26 May 2017 15:38:42 +0100
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
In-Reply-To:
References:
Message-ID: <5f215f01-27b1-bc39-9540-6d03d6adf9a9@oracle.com>
looks good. Please add the 9-na and noreg-self labels to the bug report.
Approved for jdk8u-dev.
Regards,
Sean.
On 26/05/17 15:17, Zolt?n Maj? wrote:
> Hi,
>
>
> when backporting 8160551, I also backported a test that is relevant
> only for class files with version >= 53. As JDK 8 supports only class
> files with version < 53, having the test in the JDK 8u test base does
> not make sense. This changeset proposes to remove the test.
>
> https://bugs.openjdk.java.net/browse/JDK-8180934
> http://cr.openjdk.java.net/~zmajo/8180934/webrev.00/
>
> I executed all hotspot/runtime tests with the changeset (using JDK
> 8u122), no problems have shown up. JPRT testing is in progress.
>
> Please note that this fix is a JDK 8u-specific fix (not a backport of
> some existing fix in JDK 9).
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>
From harold.seigel at oracle.com Fri May 26 14:44:31 2017
From: harold.seigel at oracle.com (harold seigel)
Date: Fri, 26 May 2017 10:44:31 -0400
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
In-Reply-To:
References:
Message-ID: <96127e2a-0059-8ef1-0ed8-2f152fe0e415@oracle.com>
Hi Zoltan,
Instead of deleting the test, can the class file version of Bad.jasm be
changed to 52 for JDK-8u?
Thanks, Harold
On 5/26/2017 10:17 AM, Zolt?n Maj? wrote:
> Hi,
>
>
> when backporting 8160551, I also backported a test that is relevant
> only for class files with version >= 53. As JDK 8 supports only class
> files with version < 53, having the test in the JDK 8u test base does
> not make sense. This changeset proposes to remove the test.
>
> https://bugs.openjdk.java.net/browse/JDK-8180934
> http://cr.openjdk.java.net/~zmajo/8180934/webrev.00/
>
> I executed all hotspot/runtime tests with the changeset (using JDK
> 8u122), no problems have shown up. JPRT testing is in progress.
>
> Please note that this fix is a JDK 8u-specific fix (not a backport of
> some existing fix in JDK 9).
>
> Thank you!
>
> Best regards,
>
>
> Zoltan
>
From david.holmes at oracle.com Mon May 29 01:51:27 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 May 2017 11:51:27 +1000
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
In-Reply-To: <96127e2a-0059-8ef1-0ed8-2f152fe0e415@oracle.com>
References:
<96127e2a-0059-8ef1-0ed8-2f152fe0e415@oracle.com>
Message-ID:
On 27/05/2017 12:44 AM, harold seigel wrote:
> Hi Zoltan,
>
> Instead of deleting the test, can the class file version of Bad.jasm be
> changed to 52 for JDK-8u?
I concur. As I just wrote in the bug report I don't see how the changes
can be backported to 8u but the test is somehow invalid for 8u!
Also as a point of order: a RFR and a RFA are distinct and should be
posted separately: the RFR on hotspot-xxx-dev (as appropriate) and the
RFA on jdk8u-dev.
Thanks,
David
> Thanks, Harold
>
>
> On 5/26/2017 10:17 AM, Zolt?n Maj? wrote:
>> Hi,
>>
>>
>> when backporting 8160551, I also backported a test that is relevant
>> only for class files with version >= 53. As JDK 8 supports only class
>> files with version < 53, having the test in the JDK 8u test base does
>> not make sense. This changeset proposes to remove the test.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8180934
>> http://cr.openjdk.java.net/~zmajo/8180934/webrev.00/
>>
>> I executed all hotspot/runtime tests with the changeset (using JDK
>> 8u122), no problems have shown up. JPRT testing is in progress.
>>
>> Please note that this fix is a JDK 8u-specific fix (not a backport of
>> some existing fix in JDK 9).
>>
>> Thank you!
>>
>> Best regards,
>>
>>
>> Zoltan
>>
>
From zoltan.majo at oracle.com Mon May 29 09:08:43 2017
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 29 May 2017 11:08:43 +0200
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
In-Reply-To:
References:
<96127e2a-0059-8ef1-0ed8-2f152fe0e415@oracle.com>
Message-ID:
Hi,
On 05/29/2017 03:51 AM, David Holmes wrote:
> On 27/05/2017 12:44 AM, harold seigel wrote:
>> Hi Zoltan,
>>
>> Instead of deleting the test, can the class file version of Bad.jasm
>> be changed to 52 for JDK-8u?
>
> I concur. As I just wrote in the bug report I don't see how the
> changes can be backported to 8u but the test is somehow invalid for 8u!
I agree -- thank you, Harold and David, for pointing that out. I
mis-read the test and thought to be related to the final field updates
handled differently in 8 and 9 (functionality added by JDK-8157181 and
JDK-8161987, respectively).
Here is the updated webrev:
http://cr.openjdk.java.net/~zmajo/8180934/webrev.01/
>
> Also as a point of order: a RFR and a RFA are distinct and should be
> posted separately: the RFR on hotspot-xxx-dev (as appropriate) and the
> RFA on jdk8u-dev.
Thanks, I noted that. Should I re-send the RFA and RFR for this issue,
or does it suffice if I do it the next time (and onwards)?
Best regards,
Zoltan
>
> Thanks,
> David
>
>> Thanks, Harold
>>
>>
>> On 5/26/2017 10:17 AM, Zolt?n Maj? wrote:
>>> Hi,
>>>
>>>
>>> when backporting 8160551, I also backported a test that is relevant
>>> only for class files with version >= 53. As JDK 8 supports only
>>> class files with version < 53, having the test in the JDK 8u test
>>> base does not make sense. This changeset proposes to remove the test.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8180934
>>> http://cr.openjdk.java.net/~zmajo/8180934/webrev.00/
>>>
>>> I executed all hotspot/runtime tests with the changeset (using JDK
>>> 8u122), no problems have shown up. JPRT testing is in progress.
>>>
>>> Please note that this fix is a JDK 8u-specific fix (not a backport
>>> of some existing fix in JDK 9).
>>>
>>> Thank you!
>>>
>>> Best regards,
>>>
>>>
>>> Zoltan
>>>
>>
From david.holmes at oracle.com Mon May 29 11:23:24 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 29 May 2017 21:23:24 +1000
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
In-Reply-To:
References:
<96127e2a-0059-8ef1-0ed8-2f152fe0e415@oracle.com>
Message-ID: <9f2e08c0-e0f5-3653-c772-d35ed1aa477b@oracle.com>
On 29/05/2017 7:08 PM, Zolt?n Maj? wrote:
> Hi,
>
>
> On 05/29/2017 03:51 AM, David Holmes wrote:
>> On 27/05/2017 12:44 AM, harold seigel wrote:
>>> Hi Zoltan,
>>>
>>> Instead of deleting the test, can the class file version of Bad.jasm
>>> be changed to 52 for JDK-8u?
>>
>> I concur. As I just wrote in the bug report I don't see how the
>> changes can be backported to 8u but the test is somehow invalid for 8u!
>
> I agree -- thank you, Harold and David, for pointing that out. I
> mis-read the test and thought to be related to the final field updates
> handled differently in 8 and 9 (functionality added by JDK-8157181 and
> JDK-8161987, respectively).
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~zmajo/8180934/webrev.01/
Looks good.
>>
>> Also as a point of order: a RFR and a RFA are distinct and should be
>> posted separately: the RFR on hotspot-xxx-dev (as appropriate) and the
>> RFA on jdk8u-dev.
>
> Thanks, I noted that. Should I re-send the RFA and RFR for this issue,
> or does it suffice if I do it the next time (and onwards)?
That's up to Sean :)
Thanks,
David
> Best regards,
>
>
> Zoltan
>
>
>>
>> Thanks,
>> David
>>
>>> Thanks, Harold
>>>
>>>
>>> On 5/26/2017 10:17 AM, Zolt?n Maj? wrote:
>>>> Hi,
>>>>
>>>>
>>>> when backporting 8160551, I also backported a test that is relevant
>>>> only for class files with version >= 53. As JDK 8 supports only
>>>> class files with version < 53, having the test in the JDK 8u test
>>>> base does not make sense. This changeset proposes to remove the test.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8180934
>>>> http://cr.openjdk.java.net/~zmajo/8180934/webrev.00/
>>>>
>>>> I executed all hotspot/runtime tests with the changeset (using JDK
>>>> 8u122), no problems have shown up. JPRT testing is in progress.
>>>>
>>>> Please note that this fix is a JDK 8u-specific fix (not a backport
>>>> of some existing fix in JDK 9).
>>>>
>>>> Thank you!
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Zoltan
>>>>
>>>
>
From sean.coffey at oracle.com Mon May 29 11:32:17 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 29 May 2017 12:32:17 +0100
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
In-Reply-To: <9f2e08c0-e0f5-3653-c772-d35ed1aa477b@oracle.com>
References:
<96127e2a-0059-8ef1-0ed8-2f152fe0e415@oracle.com>
<9f2e08c0-e0f5-3653-c772-d35ed1aa477b@oracle.com>
Message-ID: <8895d5e0-ab6c-6cf6-5a18-cc9611103b37@oracle.com>
This still looks fine for jdk8u-dev! Approved.
Regards,
Sean.
On 29/05/17 12:23, David Holmes wrote:
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~zmajo/8180934/webrev.01/
>
> Looks good.
>
>>>
>>> Also as a point of order: a RFR and a RFA are distinct and should be
>>> posted separately: the RFR on hotspot-xxx-dev (as appropriate) and
>>> the RFA on jdk8u-dev.
>>
>> Thanks, I noted that. Should I re-send the RFA and RFR for this
>> issue, or does it suffice if I do it the next time (and onwards)?
>
> That's up to Sean :)
From zoltan.majo at oracle.com Mon May 29 13:29:30 2017
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 29 May 2017 15:29:30 +0200
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
In-Reply-To: <8895d5e0-ab6c-6cf6-5a18-cc9611103b37@oracle.com>
References:
<96127e2a-0059-8ef1-0ed8-2f152fe0e415@oracle.com>
<9f2e08c0-e0f5-3653-c772-d35ed1aa477b@oracle.com>
<8895d5e0-ab6c-6cf6-5a18-cc9611103b37@oracle.com>
Message-ID:
Thank you, Se?n!
Best regards,
Zolt?n
On 05/29/2017 01:32 PM, Se?n Coffey wrote:
>
> This still looks fine for jdk8u-dev! Approved.
>
> Regards,
> Sean.
> On 29/05/17 12:23, David Holmes wrote:
>>> Here is the updated webrev:
>>> http://cr.openjdk.java.net/~zmajo/8180934/webrev.01/
>>
>> Looks good.
>>
>>>>
>>>> Also as a point of order: a RFR and a RFA are distinct and should
>>>> be posted separately: the RFR on hotspot-xxx-dev (as appropriate)
>>>> and the RFA on jdk8u-dev.
>>>
>>> Thanks, I noted that. Should I re-send the RFA and RFR for this
>>> issue, or does it suffice if I do it the next time (and onwards)?
>>
>> That's up to Sean :)
>
From tobias.hartmann at oracle.com Mon May 29 15:59:49 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 29 May 2017 17:59:49 +0200
Subject: [8u-dev] Request for Approval: Bulk backport of 8180565, 8180617,
8180511, 8180576, 8180575 and 8180813
Message-ID: <99cdc16b-16bd-0dc0-aaea-6d065a41b601@oracle.com>
Hi,
please approve the backports of the following fixes to JDK 8u:
8180565: Null pointer dereferences of ConstMethod::method()
http://cr.openjdk.java.net/~thartmann/8180565/webrev.00/
http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8f941bab493f
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026261.html
8180617: Null pointer dereference in InitializeNode::complete_stores
http://cr.openjdk.java.net/~thartmann/8180617/webrev.00/
http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0b218e675429
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026275.html
8180511: Null pointer dereference in Matcher::ReduceInst()
http://cr.openjdk.java.net/~thartmann/8180511/webrev.00/
http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1f917785fbe7
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026258.html
8180576: Null pointer dereference in Matcher::xform()
http://cr.openjdk.java.net/~thartmann/8180576/webrev.00/
http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/286c8e80795b
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026259.html
8180575: Null pointer dereference in LoadNode::Identity()
http://cr.openjdk.java.net/~thartmann/8180575/webrev.00/
http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/31c842513336
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026260.html
8180813: Null pointer dereference of CodeCache::find_blob() result
http://cr.openjdk.java.net/~thartmann/8180813/webrev.00/
http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/63ac6d565c21
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026307.html
The backport of 8180813 does not apply cleanly because "is_compiled" is called "is_nmethod" and "as_compiled_method_or_null" is called "as_nmethod_or_null" in JDK 8u.
Here's the new webrev for 8180813:
http://cr.openjdk.java.net/~thartmann/8180813_8u/webrev.00/
The review is in progress:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026371.html
All other backports apply cleanly. Tested with JPRT.
Thanks,
Tobias
From tobias.hartmann at oracle.com Tue May 30 05:04:44 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 30 May 2017 07:04:44 +0200
Subject: [8u-dev] Request for Approval: Bulk backport of 8180565, 8180617,
8180511, 8180576, 8180575 and 8180813
In-Reply-To: <99cdc16b-16bd-0dc0-aaea-6d065a41b601@oracle.com>
References: <99cdc16b-16bd-0dc0-aaea-6d065a41b601@oracle.com>
Message-ID: <8b03b3cc-c3bd-b963-682a-3f830b13f55d@oracle.com>
Hi,
On 29.05.2017 17:59, Tobias Hartmann wrote:
> The review is in progress:
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026371.html
Update: The new webrev was reviewed.
Best regards,
Tobias
From david.buck at oracle.com Tue May 30 06:32:12 2017
From: david.buck at oracle.com (David Buck)
Date: Tue, 30 May 2017 15:32:12 +0900
Subject: [8u-dev] Request for Approval: Bulk backport of 8180565, 8180617,
8180511, 8180576, 8180575 and 8180813
In-Reply-To: <99cdc16b-16bd-0dc0-aaea-6d065a41b601@oracle.com>
References: <99cdc16b-16bd-0dc0-aaea-6d065a41b601@oracle.com>
Message-ID:
Hi Tobias!
> > The review is in progress:
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017->
May/026371.html
>
> Update: The new webrev was reviewed.
approved for push to 8u-dev
In the future, please be sure to include links to the bug reports when
you request approval, as required by the push request template [0].
Here are the links for this request:
https://bugs.openjdk.java.net/browse/JDK-8180565
https://bugs.openjdk.java.net/browse/JDK-8180617
https://bugs.openjdk.java.net/browse/JDK-8180511
https://bugs.openjdk.java.net/browse/JDK-8180576
https://bugs.openjdk.java.net/browse/JDK-8180575
https://bugs.openjdk.java.net/browse/JDK-8180813
Cheers,
-Buck
[0] http://openjdk.java.net/projects/jdk8u/approval-template.html
On 2017/05/30 0:59, Tobias Hartmann wrote:
> Hi,
>
> please approve the backports of the following fixes to JDK 8u:
>
> 8180565: Null pointer dereferences of ConstMethod::method()
> http://cr.openjdk.java.net/~thartmann/8180565/webrev.00/
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8f941bab493f
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026261.html
>
> 8180617: Null pointer dereference in InitializeNode::complete_stores
> http://cr.openjdk.java.net/~thartmann/8180617/webrev.00/
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/0b218e675429
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026275.html
>
> 8180511: Null pointer dereference in Matcher::ReduceInst()
> http://cr.openjdk.java.net/~thartmann/8180511/webrev.00/
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/1f917785fbe7
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026258.html
>
> 8180576: Null pointer dereference in Matcher::xform()
> http://cr.openjdk.java.net/~thartmann/8180576/webrev.00/
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/286c8e80795b
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026259.html
>
> 8180575: Null pointer dereference in LoadNode::Identity()
> http://cr.openjdk.java.net/~thartmann/8180575/webrev.00/
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/31c842513336
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026260.html
>
> 8180813: Null pointer dereference of CodeCache::find_blob() result
> http://cr.openjdk.java.net/~thartmann/8180813/webrev.00/
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/63ac6d565c21
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026307.html
>
> The backport of 8180813 does not apply cleanly because "is_compiled" is called "is_nmethod" and "as_compiled_method_or_null" is called "as_nmethod_or_null" in JDK 8u.
>
> Here's the new webrev for 8180813:
> http://cr.openjdk.java.net/~thartmann/8180813_8u/webrev.00/
> The review is in progress:
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026371.html
>
> All other backports apply cleanly. Tested with JPRT.
>
> Thanks,
> Tobias
>
From tobias.hartmann at oracle.com Tue May 30 06:41:35 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 30 May 2017 08:41:35 +0200
Subject: [8u-dev] Request for Approval: Bulk backport of 8180565, 8180617,
8180511, 8180576, 8180575 and 8180813
In-Reply-To:
References: <99cdc16b-16bd-0dc0-aaea-6d065a41b601@oracle.com>
Message-ID: <5e721798-ec5e-89a5-92be-e6422a272d28@oracle.com>
Hi David,
thank you!
On 30.05.2017 08:32, David Buck wrote:
> In the future, please be sure to include links to the bug reports when you request approval, as required by the push request template [0].
Right, sorry for that.
Best regards,
Tobias
From zoltan.majo at oracle.com Tue May 30 07:07:23 2017
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Tue, 30 May 2017 09:07:23 +0200
Subject: [8u] Request for approval and review: 8180934 (XS): PutfieldError
failed with UnsupportedClassVersionError
In-Reply-To: <9f2e08c0-e0f5-3653-c772-d35ed1aa477b@oracle.com>
References:
<96127e2a-0059-8ef1-0ed8-2f152fe0e415@oracle.com>
<9f2e08c0-e0f5-3653-c772-d35ed1aa477b@oracle.com>
Message-ID: <5769e8c2-2b2c-1c90-50ac-304b8cab3f1c@oracle.com>
Hi David,
On 05/29/2017 01:23 PM, David Holmes wrote:
> On 29/05/2017 7:08 PM, Zolt?n Maj? wrote:
>> [...]
>>
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~zmajo/8180934/webrev.01/
>
> Looks good.
Thank you for the review!
>
>>>
>>> Also as a point of order: a RFR and a RFA are distinct and should be
>>> posted separately: the RFR on hotspot-xxx-dev (as appropriate) and
>>> the RFA on jdk8u-dev.
>>
>> Thanks, I noted that. Should I re-send the RFA and RFR for this
>> issue, or does it suffice if I do it the next time (and onwards)?
>
> That's up to Sean :)
OK, thank you.
Best regards,
Zoltan
>
> Thanks,
> David
>
>> Best regards,
>>
>>
>> Zoltan
>>
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks, Harold
>>>>
>>>>
>>>> On 5/26/2017 10:17 AM, Zolt?n Maj? wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> when backporting 8160551, I also backported a test that is
>>>>> relevant only for class files with version >= 53. As JDK 8
>>>>> supports only class files with version < 53, having the test in
>>>>> the JDK 8u test base does not make sense. This changeset proposes
>>>>> to remove the test.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8180934
>>>>> http://cr.openjdk.java.net/~zmajo/8180934/webrev.00/
>>>>>
>>>>> I executed all hotspot/runtime tests with the changeset (using JDK
>>>>> 8u122), no problems have shown up. JPRT testing is in progress.
>>>>>
>>>>> Please note that this fix is a JDK 8u-specific fix (not a backport
>>>>> of some existing fix in JDK 9).
>>>>>
>>>>> Thank you!
>>>>>
>>>>> Best regards,
>>>>>
>>>>>
>>>>> Zoltan
>>>>>
>>>>
>>
From rob.mckenna at oracle.com Tue May 30 14:51:09 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 30 May 2017 15:51:09 +0100
Subject: [8u-dev] Request for approval: 8175131 & 8180949
Message-ID: <20170530145109.GA3209@vimes>
Looking for approval for the following clean backports:
8175131: sun.rmi.transport.tcp.TCPChannel.createConnection close connection on timeout
https://bugs.openjdk.java.net/browse/JDK-8175131
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0d971960744
8180949: Correctly handle exception in TCPChannel.createConnection
https://bugs.openjdk.java.net/browse/JDK-8180949
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3f350fe1bec8
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047807.html
-Rob
From sean.coffey at oracle.com Tue May 30 15:04:54 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 30 May 2017 16:04:54 +0100
Subject: [8u-dev] Request for approval: 8175131 & 8180949
In-Reply-To: <20170530145109.GA3209@vimes>
References: <20170530145109.GA3209@vimes>
Message-ID: <202d4de2-a32a-4edf-0765-74e41d1a9226@oracle.com>
Approved.
regards,
Sean.
On 30/05/2017 15:51, Rob McKenna wrote:
> Looking for approval for the following clean backports:
>
> 8175131: sun.rmi.transport.tcp.TCPChannel.createConnection close connection on timeout
> https://bugs.openjdk.java.net/browse/JDK-8175131
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d0d971960744
>
> 8180949: Correctly handle exception in TCPChannel.createConnection
> https://bugs.openjdk.java.net/browse/JDK-8180949
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3f350fe1bec8
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047807.html
>
> -Rob
>
From stuart.monteith at linaro.org Tue May 30 15:19:52 2017
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Tue, 30 May 2017 16:19:52 +0100
Subject: Backport of 8077608
Message-ID:
Hello,
The fix in 8077608 was never backported to jdk8u. There are a
number of testcases that spawn their own java processes that then fail
to run as they do not have the correct classpath when run under JTReg
with "-agentvm".
The patch for jdk9 applies almost cleanly to jdk8u:
]http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017937.html
https://bugs.openjdk.java.net/browse/JDK-8077608
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af2a1e9f08f3
Is there any reason why this wasn't backported? If need be, I can
produce test and make a patch available.
BR,
Stuart
From sean.coffey at oracle.com Tue May 30 15:35:11 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 30 May 2017 16:35:11 +0100
Subject: Backport of 8077608
In-Reply-To:
References:
Message-ID:
Hi Stuart,
it certainly makes sense to backport such testing gains. Hopefully,
someone from the Oracle hotspot team can test and sponsor your patch on
JPRT (internal test/build system) before it's approved for pushing to
jdk8u-dev forest.
regards,
Sean.
On 30/05/2017 16:19, Stuart Monteith wrote:
> Hello,
> The fix in 8077608 was never backported to jdk8u. There are a
> number of testcases that spawn their own java processes that then fail
> to run as they do not have the correct classpath when run under JTReg
> with "-agentvm".
>
> The patch for jdk9 applies almost cleanly to jdk8u:
>
> ]http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017937.html
> https://bugs.openjdk.java.net/browse/JDK-8077608
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af2a1e9f08f3
>
> Is there any reason why this wasn't backported? If need be, I can
> produce test and make a patch available.
>
> BR,
> Stuart
From david.holmes at oracle.com Tue May 30 21:24:15 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 31 May 2017 07:24:15 +1000
Subject: Backport of 8077608
In-Reply-To:
References:
Message-ID: <176a8153-ec50-37d5-299f-be259326bed7@oracle.com>
Stuart,
Please produce the patch and send to hotspot-dev at openjdk.java.net for
review, then it can go through the 8u approval process.
Thanks,
David
On 31/05/2017 1:35 AM, Se?n Coffey wrote:
> Hi Stuart,
>
> it certainly makes sense to backport such testing gains. Hopefully,
> someone from the Oracle hotspot team can test and sponsor your patch on
> JPRT (internal test/build system) before it's approved for pushing to
> jdk8u-dev forest.
>
> regards,
> Sean.
>
>
> On 30/05/2017 16:19, Stuart Monteith wrote:
>> Hello,
>> The fix in 8077608 was never backported to jdk8u. There are a
>> number of testcases that spawn their own java processes that then fail
>> to run as they do not have the correct classpath when run under JTReg
>> with "-agentvm".
>>
>> The patch for jdk9 applies almost cleanly to jdk8u:
>>
>> ]http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017937.html
>>
>> https://bugs.openjdk.java.net/browse/JDK-8077608
>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af2a1e9f08f3
>>
>> Is there any reason why this wasn't backported? If need be, I can
>> produce test and make a patch available.
>>
>> BR,
>> Stuart
>
From martinrb at google.com Wed May 31 19:20:02 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 31 May 2017 12:20:02 -0700
Subject: [8u] Request for Approval for backport of 8166507:
ConcurrentSkipListSet.clear() can leave the Set in an invalid state
Message-ID:
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/ConcurrentSkipListMap-clear/
https://bugs.openjdk.java.net/browse/JDK-8166507
Patch from 9 applies cleanly.