jdk8u-dev Digest, Vol 80, Issue 25

Thu Jul 16 04:25:47 UTC 2020

Στις Πέμ, 16 Ιουλ 2020, 00:40 ο χρήστης <jdk8u-dev-request at openjdk.java.net>
έγραψε:

> Send jdk8u-dev mailing list submissions to
>         jdk8u-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.openjdk.java.net/mailman/listinfo/jdk8u-dev
> or, via email, send a message with subject or body 'help' to
>         jdk8u-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>         jdk8u-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of jdk8u-dev digest..."
>
>
> Today's Topics:
>
>    1. [8u] 8239385: KerberosTicket client name refers wrongly to
>       sAMAccountName in AD (Zhengyu Gu)
>    2. Re: [8u] 8239385: KerberosTicket client name refers wrongly
>       to sAMAccountName in AD (Martin Balao)
>    3. Re: [8u] 8239385: KerberosTicket client name refers wrongly
>       to sAMAccountName in AD (Andrew Hughes)
>    4. RE: [8u] RFR Backport 8057003: Large reference arrays cause
>       extremely long synchronization times (Hohensee, Paul)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Jul 2020 14:39:55 -0400
> From: Zhengyu Gu <zgu at redhat.com>
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] 8239385: KerberosTicket client name refers wrongly to
>         sAMAccountName in AD
> Message-ID: <86af138b-c678-bb1c-4eda-56f7aba47844 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I would like to backport this patch to 8u, for parity with Oracle 8u271.
>
> Original patch applies cleanly.
>
> However, it failed to build, cause it expects
> sun.security.krb5.Config.getBooleanObject(String... keys) to be public
> method, while 8u and only 8u, it declares as private. Apparently, the
> method was partially backported and made it private.
>
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8239385
> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/142d090cab77
>
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8239385-8u/webrev.00/
>
> Test:
>    jdk_security
>
> Thanks,
>
> -Zhengyu
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 15 Jul 2020 17:02:58 -0300
> From: Martin Balao <mbalao at redhat.com>
> To: jdk8u-dev at openjdk.java.net, Zhengyu Gu <zgu at redhat.com>
> Subject: Re: [8u] 8239385: KerberosTicket client name refers wrongly
>         to sAMAccountName in AD
> Message-ID: <dbc2da28-3604-123c-3ccd-5d6f8958d0dc at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> On 7/15/20 3:39 PM, Zhengyu Gu wrote:
> > I would like to backport this patch to 8u, for parity with Oracle 8u271.
> >
> > Original patch applies cleanly.
> >
> > However, it failed to build, cause it expects
> > sun.security.krb5.Config.getBooleanObject(String... keys) to be public
> > method, while 8u and only 8u, it declares as private. Apparently, the
> > method was partially backported and made it private.
> >
>
> Yes, indeed. They introduced getBooleanObject method with the backport
> of 8077102 and made it private for some reason. This class is an
> internal class so keeping it public wouldn't have affected the public
> API. getBooleanObject was originally introduced by 8029995 and was public.
>
> Your backport looks good to me.
>
> I believe we will need a CSR before having the approval.
>
> Thanks,
> Martin.-
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 15 Jul 2020 22:09:08 +0100
> From: Andrew Hughes <gnu.andrew at redhat.com>
> To: Martin Balao <mbalao at redhat.com>, jdk8u-dev at openjdk.java.net,
>         Zhengyu Gu <zgu at redhat.com>
> Subject: Re: [8u] 8239385: KerberosTicket client name refers wrongly
>         to sAMAccountName in AD
> Message-ID: <71658fc4-3fa6-7f98-1183-a8f1b00d582c at redhat.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 15/07/2020 21:02, Martin Balao wrote:
> > Hi,
> >
> > On 7/15/20 3:39 PM, Zhengyu Gu wrote:
> >> I would like to backport this patch to 8u, for parity with Oracle 8u271.
> >>
> >> Original patch applies cleanly.
> >>
> >> However, it failed to build, cause it expects
> >> sun.security.krb5.Config.getBooleanObject(String... keys) to be public
> >> method, while 8u and only 8u, it declares as private. Apparently, the
> >> method was partially backported and made it private.
> >>
> >
> > Yes, indeed. They introduced getBooleanObject method with the backport
> > of 8077102 and made it private for some reason. This class is an
> > internal class so keeping it public wouldn't have affected the public
> > API. getBooleanObject was originally introduced by 8029995 and was
> public.
> >
> > Your backport looks good to me.
>
> Yes, the backport of 8077102 to 8u is a mess. It brings in this method
> from 8029995 and alters its signature. Given that, I don't see any harm
> in fixing it here. The rest of the backport is clean.
>
> >
> > I believe we will need a CSR before having the approval.
>
> I agree.
>
> >
> > Thanks,
> > Martin.-
> >
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> OpenJDK Package Owner
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 15 Jul 2020 21:38:31 +0000
> From: "Hohensee, Paul" <hohensee at amazon.com>
> To: Liang Mao <maoliang.ml at alibaba-inc.com>, jdk8u-dev
>         <jdk8u-dev at openjdk.java.net>
> Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause
>         extremely long synchronization times
> Message-ID: <9B258C2F-0DBD-45EF-AAF4-E4BA6367D144 at amazon.com>
> Content-Type: text/plain; charset="utf-8"
>
> Lgtm, except, why you need to remove the assert from taskqueue.hpp?
> oops_do() doesn't seem to exist in 9, though I see an iterate() method that
> looks like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only
> when the serial collector is the only collector being compiled into
> Hotspot, so with your change the assert only gets compiled for that case.
> Is a taskqueue ever instantiated for that case?
>
> Thanks,
> Paul
>
> ?On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" <
> jdk8u-dev-retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com>
> wrote:
>
>     Hi,
>
>     Could someone please help?
>
>     Thanks,
>     Liang
>
>
>
>
>     ------------------------------------------------------------------
>     From:MAO, Liang <maoliang.ml at alibaba-inc.com>
>     Send Time:2020 Jul. 2 (Thu.) 10:30
>     To:jdk8u-dev <jdk8u-dev at openjdk.java.net>
>     Subject:[8u] RFR Backport 8057003: Large reference arrays cause
> extremely long synchronization times
>
>     Hi,
>
>     I'm requesting the backport of 8057003 into 8u. As the description in
> the bug,
>     it's a serious G1 issue which leads to 10X longer concurrent mark time
> and hang
>     the Java threads for seconds. We encounter the problem in several
> applications.
>     Since G1 is widely used in 8u, we need to fix it.
>
>     Original bug:
>      https://bugs.openjdk.java.net/browse/JDK-8057003
>      http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd
>
>     The JDK9 patch did not apply cleanly. Although it is not a small
> patch, I
>      didn't change much except some assertions. One assertion in
> taskqueue.hpp
>      is removed. It should be ok because it's no longer there as well
> since JDK9.
>
>     8u webrev:
>     http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/
>
>     Testing:
>     gc/g1, specjbb2015 with fastdebug
>
>     Could someone please have a look and sponsor?
>
>     Thanks,
>     Liang
>
>
>
>
> End of jdk8u-dev Digest, Vol 80, Issue 25
> *****************************************
>